Philip Meyer;639065 Wrote: > >Oh, I didn't look later in the list, I only looked for the first > >"Various Artists" entry. > > > Hence why I think it should really be labelled "Compilations" or > "[Various Artists]" - it's not the same as the album artist called > "Various Artists".
what??? WHAT??? you raised HOLY HELL when i suggested that! you "resented" the idea of changing the default from "VArious Artists" to ANYTHING else, no matter how small! you wrote pages of nonsense as to why, and now you claim you said this? sorry, i call shenanigans. Philip Meyer;639065 Wrote: > > >Wouldn't it be enough to just remove the top "Various Artists" entry > >and keep the one under "V" ? > > > No - the top Various Artists is a list of compilations, the one within > "V" section is only albums by AlbumArtist=Various Artists. > i agree with this. its basically restating that home>whatever list should be made with no regard to comp status when browsed, EXCEPT the proposed home>comps item, (made up ONLY of things SBS classified as a comp), which could exist as a link in the other lists, although it would be somewhat needless as a link in those lists, since the items will appear in them under their mysql AA value anyway. erland;639210 Wrote: > The more I think about this I'd really like separate menus for: > - All Artists > - Album Artists > - Composers > - Conductors > - Compilations > - Albums hallelujah! couldn't agree more! i would add to that list a giant "master list" where you could see all albumartists, artists, composers, etc all at once in one list, configureable via some type of SBS or display option. but we agree on the above anyway, its VITAL that a user can easily browse between artists and albumartists in the main core app. erland;639210 Wrote: > But then we are back to how to handle the "Genres" menu again. > > If "Genres" only contains "Album Artists" it wouldn't be possible to > browse to "Genres/Classical/Beethoven" unless you've tagged it with > ALBUMARTIST="Beethoven" which is probably not desirable on a "Hillary > Hahn" album. i think its safe to just let people choose a single sort criteria for genres, and leave it at that, at least for now. erland;639210 Wrote: > Now I'm starting to think that it's best to keep the new "Compilations" > menu I suggested inside the "Artists" menu and just rename it from > "Various Artists" to "Compilations" to avoid the collision. > ok, i keep having to explain this... if the browsing code isn't fixed, where things are hidden b/c they have the string conflict but aren't also classified as comps, then just changing the string ISN'T enough, b/c a user could change the string to ANOTHER string that is ALSO in conflict! so as long as thats the situation, i think your patch is the PERFECT temporary fix for now, until the better solution is implemented later. basiclly, your solution is to have SBS classify things as comps that are otherwise in string conflict. having it appear is BETTER than not having it appear, even if it is in the wrong place, as the niche case phil goes on about would be. i think thats PAINFULLY obvious and its obtuse not to agree. btw Erland, your work on this is incredible, and i am in awe of your ability to actually fully examine the issue and do something about it. Philip Meyer;639325 Wrote: > >If we want a small quick fix for 7.6, it would be possible to just > >change the default name used in the setting from "Various Artists" to > >"Compilations" and that should minimize the risk for collisions, and > we > >can later in 7.6++ do the bigger change. > > > That will however mean that when albums are auto-detected as > compilations, the album artist would be set to "Compilations" instead > of "Various Artist". i.e. there is I think an underlying problem that > the setting defining the name for compilations is used for two separate > things; name of the special artist entry used for displaying a list of > compilations (irrespective of the album artist name on each > compilation), and also used for the name given as the album artist when > making an album a compilation. i agree with this. but this is an issue that should be addressed AFTER the fixes to browsing are done. it doesn't make sense to do these now, and even if you did them now, the settings could still line up to create the string conflict anyway. Philip Meyer;639325 Wrote: > > >Of course, even easier would be to just ask the users that have > problem > >to change the setting to "Compilations" and instead focus on the real > >solution in 7.6++. > Which is what users do, and the conclusion I came to with bug report > 9523. i have several problems with this. first of all, in the bug report i was the first to suggest this, (but credit goes to Jeff Flowerday for the discovery), and in the forums, i am the only one suggesting people do this when they INVARIABLY run into this issue, as forum posts show. secondly, a user NEEDS to KNOW that are are affected/afflicted! one of the worst parts of this bug, is that its easily hidden from view, but still there nonetheless. so you can't say its what users do, since MANY obviously don't know there is a problem, or if they do, don't know that would fix it! thirdly, if you are no longer affected phil in your niche album case, you didn't explain why not...? but as you described the niche album case, (ie. an AA=Various Artists album that ISN'T a comp), the normal user who doesn't use comp tags would be, b/c comp or not, it would be hidden by the string conflict. so please stop with the "it doesn't apply to me" stuff b/c thats besides the point, what matters is the many users it DOES apply to, (if you are going to bother making the niche argument, which i feel i have now categorically demonstrated is not a valid argument against the patch). finally, as i already mentioned, you raised hell at the idea of changing the setting by default, even though you could change it back. that at least would be better, since a lot fewer string conflicts would exist, and anyone who didn't like the new default name could easily figure out how to revert it. i also think there should be a warning there about the string conflict in the help infobox for that option until something is officially done. Philip Meyer;639325 Wrote: > > > I suspect this is what we will end up with for 7.6 > >as there are other a lot more serious problems with higher priority > >which needs to be solved before this. > > > Yes. i agree that this should wait for 7.6.1, but no later. this issue has languished for years and its far more serious than you all seem to think. any user, who does not use comp tags, is probably affected by this bug. i have literally hundreds of such albums. i've employed the workaround, but it the new user logitech should worry about. between having music hidden, and not being able to switch between artists and AA on the fly, why would anyone want to use this crap? thats what they will think. JJZolx;639332 Wrote: > That's one of the reasons that for years I've been saying that the > scanner should always assign a role of album artist for every album, > whether it comes from an explicit ALBUMARTIST tag or just from the > ARTIST tags. It would greatly simplify a number of queries. my understanding is that right now, EVERYTHING in the mysql SBS DB does have an AA value, even if one does not exist in the tags. were you saying thats not the case? or did you mean something else i'm not grasping? JJZolx;639332 Wrote: > So would I. Again, with the recent onebrowser work, this should be > fairly trivial, since little, if any, special handling needs to be done > for the different interfaces now. awesome. one other thing that seems to keep getting mentioned in this thread... a file can only have an AA tag, and an Artist tag. there is NO SUCH THING as a "track artist" tag. the artist tag IS the track artist tag. so why does SBS define three roles for two tags? can someone explain that? surely whatever the reason is, if any, can functionally be achieved without doing so? -- MrSinatra www.lion-radio.org using: sb2 & droid (my home) / duet & ipeng (parents' home) - sbs 7.5.5b - win7 & xp pro sp3 ie9 - p4(ht) 3.2ghz, 2gig ram - 1tb wd usb2 raid1 - d-link dir-655 - 49k+ mp3/flac ::VOTE FOR 'BUG 15604' (http://bugs.slimdevices.com/show_bug.cgi?id=15604)!!!:: ------------------------------------------------------------------------ MrSinatra's Profile: http://forums.slimdevices.com/member.php?userid=2336 View this thread: http://forums.slimdevices.com/showthread.php?t=88072 _______________________________________________ ripping mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/ripping
