Bugzilla – Bug 5108
Track artist roles become artist roles when COMPILATION=0
Last modified: 2014-07-22 12:40:35 UTC
Artists without full albums appear when browing Artists. This occurs on albums with guest artists that have been explicitly marked as non-compilations with COMPILATION=0. They also have ALBUMARIST tags, but I'm not sure if that's a factor. Take an album tagged as follows: ALBUM=abcdef TRACKNUMBER=1 TITLE=foo ARTIST=a ALBUMARTIST=a COMPILATION=0 ALBUM=abcdef TRACKNUMBER=2 TITLE=bar ARTIST=a ARTIST=b ALBUMARTIST=a COMPILATION=0 If artist 'b' has no complete albums in the library he still appears in the artist list. With compilation albums this doesn't happen - these 'track-only' artists do NOT appear in the artist list. Do the compilation behavior settings apply to these non-compilations? Logically, you would think so, but then again, they're not compilation albums, so...
This also happens where you have several artists in the Artist tag rather than several Artist tags: This is the same as the previous example apart from the line marked with an asterisk where you will see two artists in a single tag. In this case Slimserver has been instructed to use "/" as a tag delimeter. ALBUM=abcdef TRACKNUMBER=1 TITLE=foo ARTIST=a ALBUMARTIST=a COMPILATION=0 ALBUM=abcdef TRACKNUMBER=2 TITLE=bar *ARTIST=a/b ALBUMARTIST=a COMPILATION=0
I would also like an option for artists from compilations to appear when Browsing Artists, while continuing to show compilations as 'Various Artists' when browsing Albums (i.e. when 'group compilations together' is selected)
IMO, the bug is only valid specifically because the ALBUMARTIST tag is set. Using MP3 files with nightlies verified up until at least some time in February, specifying ALBUMARTIST on a group of tracks from the same ALBUM would cause that album to be listed under ONLY the ALBUMARTIST and would not list individual track artists when browsing by artist or album. The nature of the bug here would then be that when specifying ALBUMARTIST the tracks should be listed by that ALBUMARTIST and not by individual track artists. If ALBUMARTIST *and* COMPILATION are not set, then it would be valid to list the track artists.
So are we proposing that we change the existing option to something like 'Ignore artists that are different from the album artist'?
(In reply to comment #4) > So are we proposing that we change the existing option to something like > 'Ignore artists that are different from the album artist'? Yes, that's the behaviour I'm expecting - and as far as I'm concenred this should be the case regardless of whether a compilation tag exists or if it does, what value it has.
(In reply to comment #4) > So are we proposing that we change the existing option to something like > 'Ignore artists that are different from the album artist'? Yes, that's the behavior that I think makes the most sense. I realize that when this preference was first designed the concept of having multiple artists on a non-compilation probably didn't exist. But SlimServer has evolved to permit this, so the preferences should evolve as well. I think many people already expect that these 'track only' artists, from both compilations and non-compilations, can be suppressed from the artist list. The preference would need to be moved from under the 'COMPILATIONS' header on the Server Settings > Behavior page, and the text would need rewording. I'd suggest something like: When browing artists you can choose to see only those who have complete albums, or also include artists who appear only on some tracks. > List only album artists > List both album and track artists As for implementation - I'd have to think it makes things much simpler, since you no longer have to worry about any of the artists' album's COMPILATION status.
Steven to investigate this and try to synthesize a solution.
I would like to add that missing compilation tags should be assumed to have a value of 0. Thenks.
> I would like to add that missing compilation tags should be assumed to have a > value of 0. Thenks. Yes! Time to make proper use of the database and stop using NULL values as having meaning, particularly in what should be boolean columns. A boolean should never be YES/NO/MAYBE (or is it YES/NO/DON'T-KNOW?).
Maybe I've been involved with computers too long (1982) but a bool has only ever had two meanings. True or False. 0 = False = NULL. Same same. As far as my experience with this issue in SlimServer, an unset Compilation tag has always been the same as compilation = 0 (False). This feature group has plagued many people because of the verbiage, but it's worked in a fashion capable of accomplishing what I've wanted from it without fail since at least November 2006 So feel free to make things clearer, move check boxes around and even offer some additional control, but my first comment on this issue still stands. This bug is only valid with one specific expectation. One could go so far as to say that the current implementation makes a certain assumptions and that may cause confusion for some customers. I'm just glad it's one that seems to do what I'd expect it to.
ping steven. Is this related to any of the other tagging bugs you've been looking at?
Ping steven...
Steven: PLEASE COMMENT.
First I want to apologize for not making a comment sooner and thanks to Dean for bringing it to my attention in person :) In response to comment #8 through #14 about NULL compilation values in the database I believe has been addressed in bug 5985. I have not yet investigated if we no longer store NULL compilation values for all the file types that we support but plan to do so. The proposals in comment #2 through #6 as a solution to this bug are all valid and should be considered. However just like KDF mentions in bug 5985, perhaps a new all encompassing compilation and various artist behavior and logic bug should be opened moving forward. Is this a suitable course of action? Assigning to unassigned for review.
Can we get a resolution to this issue, perhaps in the form of a new feature? Version 7.0 final and nightlies of 7.01 have broken what has always worked in 6.5 in at least some instances. The verbiage in the COMPILATIONS section of the settings in 7.0 is far too confusing for the novice user. I can't even say it makes any sense to me the way it's written honestly. Here's a suggestion for breaking the results down into three options that are more clearly defined as bools (yes/no) and further divided into a true compilation category and non-compilation (albums with guest artists for instance). HEADING: Compilations (Various Artists): (tracks must be tagged with COMPILATION TAG =1) -------------------------------- BOOL: Show individual track artists in artists list / Do not show individual track artists in artist list (*default) BOOL: Include a "Various Artists" listing in Artist and Album browse lists (*default) / Do not include a "Various Artists" listing (if option 1 is set to do not show individual, then this option is forced to include "various artists" and can't be changed) TEXT BOX: Customize the name of the "Various Artists" label [___________] --------------------------------- HEADING: Band-based (Non-Compilation) Albums with tracks by differing artists (guest artists) (tracks must NOT be tagged with COMPILATION TAG =1, must be either blank or 0) -------------------------------------------------------------------------- BOOL: List album only under the title band (ALBUM ARTIST) (*default) / List individual track artists in artists list
Jim, has the new TPE2 option in 7.1 remedied this for you?
I cna't imagine how. What does it have to do with anything discussed here?
I perhaps incorrectly assumed you were talking about MP3 files as you didn't mention it. Since MP3 files don't actually have the "ALBUM ARTIST" tag, some people have reported in the forum that they were getting the results you described by only setting the TPE2/Band tag. The intention of the new feature to treat TPE2/Band as ALBUM ARTIST would remedy this if the cause were the different treatment of the tags. Since version 6.5 I have been able to achieve the functionality you ask for in this bug by using only the TPE2 tag and making sure there are no conflicting tags present in any of the album's tracks. Compilation had always been set to "NO" with iTunes which I believe just omits that tag completely - Slim Server (at the time) always assumed a missing compilation tag meant the tracks did not belong to a compilation. Everything appeared where and how it was supposed to. If it's the setting of the compilation tag to an express "0" value that caused this problem, then that's something else entirely and I'm not certain anyone else has picked up on that - this specific bug ID hasn't had much traction and currently sits unassigned. Version 7.x has caused the behavior I described in bug 7698, which is not the same as what you're reporting here. It continues however, to honor the behavior you're after for the majority of my albums (again, see other bug for specifics).
i think its important that the people working on the new schema see this thread: http://forums.slimdevices.com/showthread.php?t=53615 whats important is the idea that not having a comp tag, and having comps = 0, is NOT always the same thing... this guy really breaks it down, altho i haven't confirmed his results. also, i was in a thread where someone else was saying similar things, maybe with slimkid, but i'm not sure. it would help to find that thread as well.
The problem is all to do with the COMPILATION=0 tag. COMPILATION=0 means that you get artist contributor roles, rather than track artist contributor roles, and therefore you get the artists listed when you Browse Artists. The presence of an ALBUMARTIST tag means you get track artist contributor roles for any ARTIST tags. When there are both COMPILATION and ALBUMARTIST tags, the compilation tag wins, so you get artist contributor roles. If there is an ALBUMARTIST tag, there is no need for a COMPILATION tag, as an album artist by default means that the album is not a compilation. If there is a need to specify ALBUMARTIST and COMPILATION=0 tags, then a solution would perhaps to be to make this store track artist contributors instead of artist contributors. i.e. if there is an album artist tag present, this should take precedence over the compilation tag, and any artist tags should result in track artist contributors.
one of the problems with SC is its never clear as to what makes the most sense... should comp tags ALWAYS trump albumartist tags? should albumartist tags always trump comp tags? and what ramifications and effects should these tags have on how SC operates? clear as mud.
(In reply to comment #22) > one of the problems with SC is its never clear as to what makes the most > sense... > > should comp tags ALWAYS trump albumartist tags? > should albumartist tags always trump comp tags? > > and what ramifications and effects should these tags have on how SC operates? > > clear as mud. You're correct about one thing... It needs to be well-defined, so that everyone knows the expected behavior, including the developers. A new database schema isn't going to help solve any problems if the behavior of the server cannot be written in stone. Which one makes the "most sense" is debatable. Off hand, I'd say the COMPILATION tag should take precedence, but then again, having an ALBUMARTIST for a compilation doesn't really make sense, so maybe it should have precedence. But that issue has little to do with _this_ bug. This bug is NOT about detection or determination of compilations or how to treat ALBUMARTIST. In fact, what I'm arguing is that the compilation status of the album is moot. I'm saying you can have "track artists" on both compilations and non-compilations. On non-compilations, these are typically guest artists in a duo with the main (albumartist) artist, or sometimes artists with their own solo track on another performer's album. If these artists have no albums of their own, then they should not appear in the artist list.
The "List compilation albums under each artist/Group compilation albums together" radio button (which needs an overall label), is only defining what artists get displayed in the artists list. I think the names for the options don't help matters. "List under each artist" really means "List all artists in the Browse Artist list". "Group compilation albums together" really means "List artists that only have regular albums". I think that could be changed to: Browse Artist list contains: o All artists o Only artists that have regular albums i.e. this is linked to the first set of checkboxes for Composer, Conductor, Band/Orchestra that also define what appears in the Browse Artist list. The two setting options could be combined for ultra clarity. What I think is being asked for is a way to control what gets displayed when browsing into an artist. I wouldn't complicate the "group compilation albums together" option further, to represent what gets displayed when you have browsed to an artist. I think it would be better as a separate setting. It's not just compilation albums that people may want to show/hide when browsing to music by an artist. It's also guest performances on albums by other people (and maybe other contributor roles). i.e a checkbox for "show compilation/guest performances" (or maybe a checkbox for each contributor role, as people may not want to see composers/conductors/bands too). Rather than add extra options in the settings pages, I think it would be nice to provide this option as an extra control on the Browse Albums WebUI page, similar to the "Show/Hide artwork" option in the Now Playing area. It would need to be configured somehow for the various player UI's.
Sorry, comment #24 was meant for bug 4754, but by a stroke of luck, it's not completely inappropriate here too :-)
Jim, do you give any credence to the idea that SC is too limited? in othr words, why does SC focus on, and force, all data into one master list? shouldn't i, as the user, be able to have several lists simultaneously? for instance, one list could be made as SC does it now, using its various logics and what not. but what about a list of only albumartists? and another of artists? another of both? another of ALL possible contributors, (a massive list, of artists, albumartists, guests, composers, trackartists, etc... any and everything) why do we try to come up with all these rules to make only one usable list?
Well, for one thing, the user experience would be needlessly(?) complex. If the user goes to Browse -> Artists, do we show him/her then another menu that is 'All Artists' 'Album Artists Only' 'Album artists and composers' 'track artists and contributors' etc? Do we show them a list of checkboxes like in the alarm day settings where they can select which tags they want to include in the list? Maybe we could show them the last list, and have a menu item at the bottom to change the list criteria? Maybe we should have a set of favorite list criteria to select from, plus the exhaustive list, plus a menu item to create a new favorite criteria?
see i find that interesting, b/c i think users are smart enough to figure out different ways to browse, BUT i think SC is aleady "weird" in that it has home > artists and home > albums, which i would guess most people sort by artists. that seems redundant and confused... and i understand that browsing albums is different than browsing artists, but i don't see why it has to be done this way. i don't want to clutter the bug report, but if you use winamp you know how great and powerful its media library is, (think user friendly mp3tag) how you can browse and sort ascending or descending by virtually any supported tag, how you can configure the view and add your own custom views, switch in and out of art, quick search, etc... just as one example, why can't i easily in SC switch between browsing TPE1 and TPE2? or both simultaneously?
Browse Artists is far from redundant. I hardly ever have a need to browse albums; I most frequently browse a sub set of albums. i.e. choose an artist, year or genre, and then see all matching albums. I sometimes know I want to play an album, but can't remember the name of it. I probably know the artist, so rather than browse ~2000 albums until I recognise the name, I browse artist, and get a subset of albums to browse through. The only time I directly go to Home > Browse Albums, I order by album. There's no other reason to list all albums, unless I'm trying to go straight to an album title. However, Browse Artists > [artist] essentially displays Browse Albums filtered by the artist, and I often change the sort order to Year, album. If anything, Home > Browse Albums is redundant... >just as one example, why can't i easily in SC switch between browsing TPE1 and >TPE2? or both simultaneously? SC is more intelligently structured than just a grid of data, like iTunes, winAmp, etc. It's got a relational database engine behind it that gives more opportunities for browsing the library. Browse by TPE2 would only show mp3 albums that have BAND data, and many people don't enter anything in there. It's purpose (if used to represent album artist), doesn't mean it should always contain data. Browse Albums, sorted by Artist already does this - you see album artist if there is one, otherwise artist. It's intelligent, deciding the most appropriate artist to display/sort.
>Browse Artists is far from redundant. I hardly ever have a need to browse >albums; I most frequently browse a sub set of albums. i.e. choose an artist, >year or genre, and then see all matching albums. >I sometimes know I want to play an album, but can't remember the name of it. I >probably know the artist, so rather than browse ~2000 albums until I recognise >the name, I browse artist, and get a subset of albums to browse through. <snip> but you can, right now, just order, ie. sort/group, your albums by artist, or artist then year, etc... its only slightly different in that all albums are listed in artist order, instead of just artist names. i'm not saying one or the other is better, personal preference of course, but its such a slight difference. as it happens, i like to see all the albums and artwork, so i always go in via home > albums and sort via artist, year, album with artwork enabled. >If anything, Home > Browse Albums is redundant... exactly my point... depending on POV, one or the other seems somewhat redundant given the current way SC operates with the same single master list. >>just as one example, why can't i easily in SC switch between browsing TPE1 and >>TPE2? or both simultaneously? >SC is more intelligently structured than just a grid of data, like iTunes, >winAmp, etc. It's got a relational database engine behind it that gives more >opportunities for browsing the library. Browse by TPE2 would only show mp3 >albums that have BAND data, and many people don't enter anything in there. >It's purpose (if used to represent album artist), doesn't mean it should always >contain data. Browse Albums, sorted by Artist already does this - you see >album artist if there is one, otherwise artist. It's intelligent, deciding the >most appropriate artist to display/sort. i'm afraid we disagree here. i don't think its intelligent to be inflexible. what you see as brainy i see as dopey. first of all, the forums are full of post after post saying what SC does either doesn't make sense or doesn't suit someones tastes. i know phil that you love how SC behaves, and you conform to it. that isn't going to cut it for most people however, and i think thats whats led to the whole new schema bug 8303 ...the need for flexability. secondly, even if you do design solid rules for creating a master list to cover a given circumstance or scenario, its not ALWAYS appropriate for all uses. i'm sure i could concern myself with creating rules for SC that would make a master list i would like 90% of the time, and that would work great for me. but would that be good for you? what about the other 10% of the time for me? and TPE1 and TPE2 were just the two easy examples... i don't want to get lost in TPE2 discussions. the point i was trying to illustrate that you seem to be ignoring is that if i want to browse ALL my TPE1 data, for example, I CAN'T. now, whats so intelligent about that? maybe i don't always want to or need to, but what about when i DO? SC is too fixated on creating only one usable master list. other apps don't have that limitation.
Browse by ARTISTS gives you a TEXT list of artist names only. It's like browsing the top node only of an artist-> album tree. Browse by ALBUM can optionally show you cover art and displays a list of all albums with hierarchical sorting - which can be configured a number of different ways. Neither one of those modes overlap so neither one can be considered redundant. There is only a single HOME in the menu structure and that exists above both browse modes. The top-most menu makes sense and both browse modes also make perfect sense. Not changing a single thing about the current implementation is a far better way to go than to make some arbitrary change to allow more "power." Since SC has a DB back end, a true power user/dev can create their own display UI and query the DB however they please. That said, I can concur with Mike that perhaps additional or custom sorting and display properties could be added to one or both of the current browse modes. Though I don't really see that adding anything to browse by artist would be wise because any change to the sorting key would no longer make it browse by artist, would it? The album mode already has a pop-up menu to choose sorting and display options which could potentially receive a few others in addition to a "custom" option (or define custom options in prefs ahead of time). HOWEVER, for usability sake, I would strongly recommend keeping both current menu options and not trying to merge the two into a some new combination browse mode. Potentially a third browse could be added called "Custom Browse" which would receive these options instead of them being thrown onto the existing modes. This would keep the current UI as easy to use as it is now without creating unnecessary confusion. Truth be told however, I don't find the current implementation lacking in terms of the ability to display and sort the music catalog. Perhaps for classical something additional might be convenient, but for your typical pop (which can include any other typical genre), there's no need to complicate matters and muddy up the UI. The SEARCH can be used to pull up anything you want and it would make a better UI for enhancement. If your tags are set correctly for all your music and you have SC configured properly the way you want, the current browse modes should list everything appropriately. I have a lot of albums tagged with BAND and being used as ALBUM ARTIST and I have no desire to be able to change the artist browse or album browse to sort on that tag. because my SC is configured the way I want in the treatment of that tag, the current browse modes already put those items where they should be.
"where they should be" -> with the exception of the bugs logged here of course. :) IMO, this discussion is now completely off-topic for this bug and will only serve to confuse the issue.
The database is not inflexable. All the info is in there to browse however you like. There are other plugins, or apps that can take that data and give you control to put the information in any hierarchy you want, sort however you want, etc, and play it on any connected player. SC doesn't do extra browse menus in core currently, but probably will offer more browse options in the future. You *can* browse all artists using Browse Artists, if you so desire. The option is there to not group compilation albums together, and thus all guest artists will appear in the list. You can also add composers, conductors and orchestra/band to the browse artists list, and thus all possible artists in your library are in one ordered list of artists. You can't do the same in other simple "data grid" apps, such as iTunes, because you can sort by only one column, not aggregate artists in several columns together. There is no (or limited) context between rows or columns in a grid, and that is not how music libraries should be handled. So, in WinAmp, how do you get an ordered list of all artists, album artists, bands, orchestras, composers and conductors? Personally, I use CustomBrowse plugin, which is perfect for selecting what browse menus you want. Browse all artists, browse compilations, browse by starting artist letter... they are all there ready to use, or create your own personal browse method. I agree, Mike has yet again caused another thread go off topic to meet his own personal agenda. So, lets leave it at that and get back on topic.
C'mon, guys. I'm the bug reporter, so I can't unCC myself. :-) All of this has been hashed to death elsewhere.
gimmie a break phil, no need to be a jerk... i asked a question to jim in his comment 23 to which a slim employee responded, and so i responded to him, and SO DID YOU. i apologize to jim for the bug report itself getting off track up to whatever degree i am responsible, but i think my original question to jim IS applicable to the problem he is reporting here. SC is too fixated on only having one master list it creates via its voodoo methods to work with, and then locking you into that one list that oftentimes requires changes to settings and full rescans to rebuild if you want a different look. i shouldn't NEED a plugin to achieve this, (if indeed it would do what i want to begin with). in winamp btw, you can choose via several panes how and what to display, (they can act as filters, and you can even choose how many panes you want, and save as many config views as you want). its quite intellegently designed. and inside a pane, each column can be ascending/descending, and winamp knows what order you clicked on the columns, so you can create ad hoc sorting scenarios, like first sort by this, then this, then this... etc. each new column you click then takes precendence, but the one prior then becomes the secondary sort.
This is still an issue with 7.4. Does anyone have an ETA on when it will be addressed or a work around? This bug has been open since January 2009 and I first contacted support in June 2009...
This bug has been opened since June 2007, not Jan 2009. Perhaps JOnathan posted into the incorrect bug. IMO, all comments in this bug report should be ignored except for Jim's original. I believe the other issues have since been dealt with in one way or another. Any further requests for display behavior or master list contents outside the scope of what Jim reported originally should be entered into their own bug reports if needed. Since a sole track artist of "c" will be suppressed from the browse lists when TPE2 (band, ne ALBUMARTIST) contains "a," then Jim's specific second example should also be true and the extra track artist should also be suppressed if it isn't already.
It was a typo 2009 should be 2007. I'm having the problem Jim stated.
I have duplicated Jim's issue. But this issue only happens when you explicitly set COMPILATION to 0. It doesn't happen when you omit the COMPILATION tag completely (remove the tag from your music to fix the issue with the current release). Tested SS version: 7.4 release (Version: 7.4.0 - r28672 @ Mon Sep 28 19:51:11 PDT 2009) Tested server platform: Windows XP Tested files: MP3 ID3v2.3 - tags edited in MP3Tag 2.43 Compilation Tags tested: COMPILATION and ITUNESCOMPILATION The options in SS preferences are set appropriately (these prefs must be set for testing to be valid): checked: Group compilation albums together checked: List albums by band (this is the one that affects the browsing of these types of tracks) checked: Treat TPE2 MP3 tag as Album Artist IMO, this is not the correct way to use those tags, but it's still a bug. If the tracks are not part of a compilation, they should not have the compilation tag at all. Omitting those tags completely will cause the secondary artists to disappear. ALBUMARTIST or TPE2 set with the above prefs already assumes the album is not a compilation unless you had explicitly COMPILATION=1. So, the bug is that if you have compilation tag(s) and they're set to 0, on albums that have an albumartist, secondary artists will be listed in the browse lists even if SS's prefs are set to suppress them. Removing the compilation tag allows SS to display the browse lists correctly, without the secondary artists. Basically SS is treating COMPILATION 0 differently than having no compilation tag at all. This difference in treatment was the subject of an old bug actually. Sounds clear enough to be easily fixed now.
Interesting... I've got an album with "ALBUM ARTIST" tag set and regardless of whether or not I have compilation = 0 or 1, or not present, and regardless of how I've got the "Group compilation albums together" "List albums by band" and "Treat TPE2 MP3 tag as Album Artist" boxes set I get the additional data from the Album Artist field showing up in the artist list.
Jonathan wrote: >I get the additional data from the Album Artist field showing up in the artist list If that's not a typo, then that's the correct behavior. My suggestion is to set the preferences as I've indicated, and check your tags with MP3Tag by selecting the "Extended Tag" option. For testing purposes, make sure only the tags that jim mentioned are present, omitting the COMPILATION or ITUNESCOMPILATION tags by deleting them. If you want to be absolutely sure SS is properly indexing everything, try clearing out its DB completely and let it rebuild the whole thing. I was able to simply rescan to change the behavior back and forth 4 times while testing. You might also rename the tracks filenames to make sure they get picked up in a simple rescan. You know, just in case. Also, try it by creating some fictional artist name (such as "aTestArtist123"), just to be sure that you're not seeing the entry in the list because the tags of some other tracks are still broken/affected. I've actually tested this both by using multiple ARTIST tags as Jim outlined, as well as putting multiple artists within a single ARTIST tag using the separator defined in SS's prefs. Both have the same behavior. The only catalyst seems to be the COMPILATION 0 tag.
That wasn't a typo. Now I'm not sure about what is and isn't the correct behavior. History recap: Prior to 7.3.3 albums which had no compilation field set but had the field AlbumArtist filled in with additional artists suppressed those artists from showing in the Artist browser. I liked that behavior! With versions 7.3.3 and up these additional artists are showing up in the Artist list. In June of 2009 I worked with Anoop (anoop@slimdevices.com) who had me send in a sample FLAC file. He agreed this was a bug in 7.3.3 and refereed me to this bug report 5108. Now, if I understand correctly, you're saying this is the correct behavior? It doesn't make sense to me because regardless of how I set the SS settings I get the additional albumartists showing up. I did, btw, do a complete clear and rescan for all of my experiments. I guess if you were able to tell me how to suppress the AlbumArtist data from showing up in the Artists menu I would happily go back into the woodwork! Until then I'm not satisfied that the behavior change from 7.3.2 to 7.3.3 is correct. Thanks much for your help! Jonathan
(In reply to comment #42) > It doesn't make sense to me because regardless of how I set the SS settings I > get the additional albumartists showing up. I did, btw, do a complete clear > and rescan for all of my experiments. Why would anyone want to suppress ALBUMARTISTs from the artist list? I don't recall that behavior ever being the case. If I have a Frank Sinatra album: TRACKNUMBER=1 TITLE=The Lady Is A Tramp ALBUM=Duets ALBUMARTIST=Frank Sinatra ARTIST=Luther Vandros TRACKNUMBER=2 TITLE=What Now My Love ALBUM=Duets ALBUMARTIST=Frank Sinatra ARTIST=Aretha Franklin Then I don't want Luther Vandros and Aretha Franklin in my artist list, but I do want Frank Sinatra.
(In reply to comment #39) > I have duplicated Jim's issue. But this issue only happens when you explicitly > set COMPILATION to 0. It doesn't happen when you omit the COMPILATION tag > completely (remove the tag from your music to fix the issue with the current > release). I think you've rediscovered what Philip was saying in comment 21. This does work. My only problem with it is that it shouldn't matter if you set an explicit COMPILATION=0 tag, since the album is not a compilation. There's just some oddball logic somewhere that affects the assignment of artist roles in this case.
The issue of the way one tags and organizes their album should be kept separate from the way software operates. That being said... in my case, I have around 1,000 classical CDs, many of which are art songs. Take this album for example: Hyperion Schubert Edition, Vol 34. This album has a composer (Schubert) and about 10 people that sing one or two tracks individually. I have listed these folks in AlbumArtist for the entire album so the information is available to me and, with 976 other CDs that have similar data, I don't have forty eight thousand, six hundred, and seventy three artists in my Browse Artists menu. To be precise ;-) Now, I suppose I could go and re-tag my thousand CD collection, or I could go back to 7.3.2 where this is function worked (and stay there until the cows come home), OR I could hope that someone at Slim could fix what they themselves called a bug back in June. (In reply to comment #43) > (In reply to comment #42) > > > It doesn't make sense to me because regardless of how I set the SS settings I > > get the additional albumartists showing up. I did, btw, do a complete clear > > and rescan for all of my experiments. > > Why would anyone want to suppress ALBUMARTISTs from the artist list? I don't > recall that behavior ever being the case. > >
Having used my squeezebox and transporter since 2006 and with over 1TB of music I always look with great fear to these threads as it might end in changes that will break the way I have tagged my collection and make it hard to use in the future. Jim, Philip, Mike and me have discussed these topics in these and many other bugs and threads over the last 3 years and absolutely nothing has come out of that, not even changing the phrasing of the options so that at least people understands what those options do. This is not to hack on Slimdevices (now Logitech) but the reality is that what those option do and how the server reacts depends on what the tags are used for. With no standard for what tag to use for what, no unique behaviour will ever be possible, and attempts to change the SS behaviour will perhaps fix some use cases but will also certainly break many others. I really whish that Logitech will invest the time that is needed to fix this once for all (and I am sure that there are many volunteers here, including myself, ready to help with that), which requires a two steps approach. 1. Get defined what tags are used for what and what the desired result is. Make lots of examples so that people can review it and understand it. Take Jazz and classical music into the equation. DON'T TRY to leave by all possible players standards. What tags WMP, iTunes, Monkeyplayer etc. uses and saves when ripping are not consinstent and might change in the future. Define a Squeezebox Server standard, get it reviewed by the community and stick to it! 2. Once 1 is done go ahead and write the specifications (as somebody wrote above "carve it in stone"!) for how the whole browsing story is supposed to work and what each option is for. Personally I would prefer to see a solution like Erland's custom browse implemented as standard in Squeezebox server, with a standard configuration out of the box, but the posisbility for advanced users to completely customize the way data is parsed and grouped. This would solve a lot of other bugs related to years and genre browsing. But bottomline is that unless Logitech invest some time into this I will keep leaving in fear that a partial solution will screw up my collection in the future. This is not just another small bug, a real solution takes time.
Jonathan Fredrick wrote: > Hyperion Schubert Edition, Vol 34. > This album has a composer (Schubert) and about 10 people that sing one or two > tracks individually. > > I have listed these folks in AlbumArtist for the entire album so the > information is available to me and, with 976 other CDs that have similar data, > I don't have forty eight thousand, six hundred, and seventy three artists in my > Browse Artists menu. To be precise ;-) I believe you've misunderstood the purpose of ALBUMARTIST, and essentially have it backwards. ALBUMARTIST is used to override the artist(s) that a whole album should be listed under (in browse artists for example) *instead* of the actual ARTIST's. So what you should have done is tagged this album with the specific artists of each track in the ARTIST tag, and set the ALBUMARTIST to Schubert. There were some bugs with ALBUMARTIST in earlier releases but I do not think it ever worked backwards as you seem to imply. It should be easy enough to automatically correct your tags, but I'm not the one to advise you on that as I use linux. Ask on the forums, there seems to be one or two very powerful windows tag editors that should make this easy (but please make a backup first just in case, and I suggest starting on a copy of a small subset of your library as a test case as well).
Jonathan, just to be clear, ALBUMARTIST is the right tool for the problem you are trying to solve, you just used it backwards. If someone at slim told you this was a bug, they must have been confused, and also had it backwards, or there was a miscommunication.
Greg is bang on, Jonathan. You're using the ALBUM ARTIST tag incorrectly. I have been using the Slim products since 2006, pretty much always with beta versions. The behavior that exists today with 7.4 is the correct behavior, except for this bug that Jim has pointed out, caused by the COMPILATION tag presence. Jonathan wrote the following: > The issue of the way one tags and organizes their album should be kept separate from the way software operates This isn't the case and cannot be the case. Certain tags have specific global definitions and Slim is and has been using most of those as per those definitions. The TPE2 tag for MP3s being re-purposed as "ALBUM ARTIST" is a bit of a liberty, but the same one that dozens of other programs take and one that has been a constant since 2006 at least. Except for a small slice of time when a 7.x version came out and broke this, just prior to introducing the new pref that explicitly allows you to define that TPE2 (BAND) should = ALBUM ARTIST. This only affected MP3 files however and not FLAC, which has always had a real ALBUM ARTIST tag. Think of it this way... The ARTIST tag is to list the actual performers of the copies of the music you're tagging. The A:BUM ARTIST tag is to list the name under which the music should be filed and displayed. The ALBUM ARTIST may or may not have performed any tracks from the release at all (in the case of a DJ remix album for instance). This bug in summary: COMPILATION 0 is not treated the same as having no compilation tag and is causing individual artists that don't have other releases to not be suppressed from the browse lists when ALBUM ARTIST is correctly set. Other discussions are outside the scope of the bug Jim filed and I fear are only hindering the bug being resolved.
Is my understanding correct that we have a matrix of 4 possible combinations of the two tags (with or without compilation tag, with or without album artist)? Beside this matrix (which I am not sure it is implemented correctly) the lack of compilation tag should be interpreted as compilation=0. The combinations and expected results should be (of course we are talking of albums with tracks from different artists, and all the three settings discussed above marked): 1. Compilation=0 or missing, Albumartist=<empty> Album is listed under each of the artists found on single tracks, each album for a given artist contains only the artist relevant track(s) (also if the artist does not have any full album, otherwise those tracks will not available anywhere for browsing). 2. Compilation=1, Albumartist=<empty> Album is listed under "Various Artists" in its entirety. Album is also listed under each of the artists found on single tracks each album for a given artist contains only the artist relevant track(s) and only for artists that have at least one full album. 3. Compilation=0 or missing, Albumartist="Album Artist Name" Album is listed under Albumartist in its entirety. Album is also listed under each of the artists found on single tracks each album for a given artist contains only the artist relevant track(s) and only for artists that have at least one full album. 4. Compilation=1, Albumartist="Album Artist Name" Album is listed under Albumartist in its entirety. Album is not listed for the individual artists (otherwise it would be the same as case 3 and we know from hundreds of posts in the forum that there are people that do want also this option).
I don't want to offend anyone, but... Matrices... I'm questioning why I bother to contribute to bug reports at all anymore. I wonder if Jim feels the same way since this discussion has just gotten into an un-ending quagmire. Alessandro, unless you are an active contributor to this feature development in SS or working for Slim, then you can't really say what "should" be. Some of your cases, IMO, are incorrect - they all also depend on various preference settings. They're just serving to cloud the issue in this bug report. The specific issue here has been demonstrated and proven and isolated. There's no need to discuss the other possibilities in tagging that so far seem to work as expected. Jim, how do you feel about closing this bug and opening a new one that expressly mentions that COMPILATION 0 is not being treated the same way as a missing compilation tag? And it's worth noting again, if you have COMPILATION 0 on any tracks, remove the tag completely as a permanent fix for this issue. In two or three years when someone from Slim finished reading all the posts here and manages to pick out the problem, maybe we'll see it fixed. :)
That was actually a question and an attempt to help understand the problem in depth. Anyway no offense taken, just hope that Brandon will read the whole thread before making any changes to SS.
In Comment #50, Alessandro Guida wrote: > the lack of compilation tag should be interpreted as compilation=0. I'm not sure I agree with that. A COMPILATION tag (0 or 1) should override the slimserver auto-VA logic. If not set, then slimserver should DTRT. In particular, I disagree with your case #3 when COMPILATION is not set and I have an ALBUMARTIST: the album should be listed only under the ALBUMARTIST. That's how it works today ... please do not change it! I really think COMPILATION should be ignored when ALBUMARTIST is set. If anyone actually wants the behavior described in your case #3, then it should be a slimserver option rather than abuse the COMPILATION tag. I would actually get rid of most of the special VA logic, and do the following with the COMPILATION tag: if (COMPILATION is set to 1) or (COMPILATION is unset, and multiple track artists exist), then simply add "Various Artists" (actually the configured value) to the set of ALBUMARTIST's for the album. That's it. Yes this means get rid of all the crufty special case logic in the server dealing with the 'variousArtistsObject', etc. Yes it means "Various Artists" will appear only once in "Browse Artists, sorted under "V" rather than at the top of every page. Yes it means that the binary search in Slim/Buttons/Common.pm:numberScroll might actually work correctly.
i agree with greg. not having a comp tag, and comp=0 are NOT the same thing. comp=0 is a tag whose purpose is to explicitly state such and such is NOT a comp. simply not having any comp tag by no means implies that; and to suggest otherwise that it should, would totally defeat the comp logic. where i can see some agreement, is in the idea of optionally user-disabling the current VA logic, and replacing it with either an explicit comp=1 tag, and/or a string recognition system, where the user defines strings to SBS that if it finds mean "this is a comp." bug 8324 was a step towards that. however i also agree with Bruno, too many issues have conflated with this bug that should be dealt with separately (prob in the forums), the issue here is specific and isolated and hopefully won't go overlooked by the devs.
And I agree with Mike and Greg and disagree with myself :-). That was my mistake, sorry. Of course the lack of COMP tag should just revert to the current VA logic to determine whether an album is a compilation or not (which I believe is based on having different track artists within the same album). Given that there are still 4 possibilities (where whether it is a compilation or not is given by the VA logic or overriden by the the COMP flag), I still believe that the 4 combinations are valid and I brought them up because given the amount on comments to this bug it was clear that many people does not know what to expect when combining those tags. I really hope that Logitech will fix the bug reported by Jim, but I really hope they will look at it in the context of all the other combinations so that we don't get other unexpected side effects.
> This bug in summary: COMPILATION 0 is not treated the same as having no > compilation tag and is causing individual artists that don't have other > releases to not be suppressed from the browse lists when ALBUM ARTIST is > correctly set. (In reply to comment #51) > Jim, how do you feel about closing this bug and opening a new one that > expressly mentions that COMPILATION 0 is not being treated the same way as a > missing compilation tag? > And it's worth noting again, if you have COMPILATION 0 on any tracks, remove > the tag completely as a permanent fix for this issue. kinda like bug 9870 and bug 9872 which i closed mostly as too confused, but some similar issues nonetheless. however... it seems to me that if you have an AA tag set, the only way to push A's out into the sbs artist list then, is by using the Comp=0 tag. the explicit comp tags are supposed to over-ride AA tags afaik. thats why removing them works, and i don't think anything about that should change, (unless i've misunderstood something). it would be better if you could ignore comp status, and just choose on the fly what criteria you wanted displayed/to sort by. outside of that, the "how to display" issue has been well covered by bug 4754 and even better in bug 4341
Alan, i thought this might be inside the scope of onebrowser
I do not think so. I have been avoiding getting involved in the compilations can-of-worms.
Would you like to test it?
i still need to test erlands plugins. i would be more interested in testing 7.6 if it sounded closer to being released and if it was certain onebrowser would be included. so, otherwise i will let you know if i get more ambitious. i don't think you can or should "divorce" compilations from onebrowser work. users are going to have compilations, its not like they won't. to me its like saying you want to write a book without vowels.
Since removing COMPILATION=0 I'm no longer seeing this. As long as you don't use COMPILATION=0, track artists don't appear in artists. The bug here is that COMPILATION=0 forces contributors that should have 'track artist' roles to have 'artist' roles instead, and that's why they were displayed in the artist list. There should be no difference in the contributor roles whether the COMPILATION tag is absent or =0. This is not dependent on a new database schema. Please change the target milestone and the assignee.
Jim, did u see my comment 56 ? i think i diagree with you. why shouldn't a comp=0 tag force track artists into the list? if the VA detection is mandatory, and you have no AA tags, but you DON'T want the album showing as VA in the artists list, how else would you force them out?
Agree with Jim's comments in Post 61. This should be a simple change, the current behaviour is incorrect. If an artist doesn't appear somewhere in a library as albumartist they should NEVER feature as anything but track artist.
Created attachment 7731 [details] Don't list track artists if compilation=0 I think this actually is a side-effect of an incomplete change to a very similar report in bug #2638. The fix for that bug only works if the compilation flag is not explicitly set. We should handle it the same if it's set to false.
This should be fixed in 7.9. Please test tomorrow's build.