i should also add that i think i had Treat TPE2 as Album Artist enabled when i filed this bug.  however, it may or may not exist still today regardless of if its enabled or not, i haven't checked that recently.

Here's how this shows up for me:
I have an album where every track has ARTIST="Various Artists" and COMPILATION is not set.  I set "group compilations" on the settings page.  I have TPE2=Band selected, and do not have ALBUMARTIST set. When I browse to Genre> or Artists> I see "Various Artists" at the top which contains all compilation albums.  As expected, this album does *not* appear here. (Well, maybe you wish it would, but from what I understand of how SC handles compilations, I don't expect it to show up.) There is also an artists entry under "V" called "Various Artists", where I would have expected to find this album, but it doesn't appear.  I noticed that the html query for the link to this "Various Artists" contains "album.compilation=1", which would seem to indicate that it's only asking for albums with artist="Various Artists" *and* compilation set.  (The special "Various Artists" item at the top of the artist list also contains "album.compilation=1".)  This behavior doesn't seem correct to me: the VA item at the top is the special one for compilations, the VA under v in the artist list should probably be for albums where the artist is VA, but aren't compilations, or else maybe should be omitted.

If you set an alternate name for compilations instead of the default "Various Artists" (I used "Compilations") then you find an item at the top of the artist list called "Compilations" which correctly holds all compilations and you find an item called "Various Artists" under v in the artist list that does not contain "album.compilation=1", and so correctly displays albums with artist=Various Artists but aren't compilations.  (I didn't check what would happen if there were an album tagged with ARTIST=compilation -- might it too have the "album.compilation=1" set?)

Essentially, the "Various Artists" item under v in the artist list is acting as a subset of the albums appearing in the "Various Artists" item at the top of the artist list.  Does this seem like the right behavior?

This sounds like correct behaviour to me.

This bug report reads "I can't see albums that are not compilations under the compilations artist".

The "Various Artists" special SC artist appears under "V" and at the top of the list.  Both are identical entries, and are configured to display compilation albums.

It is not correct to enter an artist or album artist that matches the special name used to denote compilations (by default "Various Artists") and not have the album marked as a compilation.

SC only lists compilation albums under that special artist, so if an album is not a compilation, it should not be listed there.

If you change the special name that is used for displaying compilation albums under, then your "Various Artists" artist that does not contain various artist albums will display the albums by the artist called "Various Artists".

If you were to set COMPILATION=1 on all songs, then it would be listed under "Various Artists" without changing the special name to "Compilations".  Better still, tag the songs correctly to say who performs on each song, or don't have an album artist if the album is a compilation, and it would automatically be listed correctly.

Phil,

what isn't correct is SC using a special name that is also used by gracenote and many, many apps and users.

it is SC that needs to change and adapt, not the infinite marketplace of users out there.

all SC has to do is change the "special name" of "Various Artists" to ANYTHING else that is not likely to be used out there by users / apps.

one such suggestion would be "Compilations, Various Artists, etc"

logitech seems more interested imo to meeting the needs of its customers, not trying to strongarm them into changing what they probably didn't set to begin with.

i'm not saying SC/slim should be omniscient and have known this would happen, but since it is now made known to them, i think they should adapt to the reality out there.

Perhaps the behavior I described in comment #2 isn't what the OP was describing (it's a little vague as to which VA item the OP is referring.)  However,

Phil said in comment #3:
>This sounds like correct behaviour to me.
>
>This bug report reads "I can't see albums that are not compilations under the
>compilations artist".
>
>The "Various Artists" special SC artist appears under "V" and at the top of the
>list.  Both are identical entries, and are configured to display compilation
>albums.

Both entries are not identical.  The "special" VA entry at the top of artist lists holds all compilations.  The VA entry at "V" only shows compilations with ARTIST="Various Artist".

I don't have a problem with albums tagged with ARTIST="Various Artists" not showing up in the compilations -- that seems perfectly reasonable and consistent with SC's compilation behavior.  I also understand that if ALBUMARTIST is set then it will also not show up in compilations (although having the special case of ALBUMARTIST="Various Artists" be identified as a compilation might go along way towards satisfying those (like Mike) who have music tagged in this way.)

I'm just pointing out what I consider a fairly harmless quirk, namely that the VA listing under "V" is not the same as the one at the top of the page. 

See comment #25 in this thread for more details:
http://forums.slimdevices.com/showthread.php?p=367960#post367960

-s

>what isn't correct is SC using a special name that is also used by gracenote
>and many, many apps and users.
Rubbish - SC has just as much right to indicate that compilation albums are by Various Artists as any other application.

>all SC has to do is change the "special name" of "Various Artists" to ANYTHING
>else that is not likely to be used out there by users / apps.
All a user has to do if they don't like "Various Artists" is change their configuration.

>one such suggestion would be "Compilations, Various Artists, etc"
So, listing albums would report "<album> by Compilations, Various Artists, etc".  That wouldn't be very nice, I think.

its not rubbish phil.

sure, they have just as much right, to do it properly, which they don't.

you're the one who said it was "special."  well, there's clearly a bug here involved with it being "special."  and the bug conflicts with how gracenote and many apps tag the music.

logitech isn't in business to martyr itself.  all they have to do is pick a category name that isn't common, and then folks like you who are unaffected by the bug can change it back to "Various Artists"

but as long as SC isn't going to handle those with "Various Artist" in their tags properly, SOMETHING needs to be done to fix the issue, b/c it isn't going away.

I resent the idea of SC having to change the default name "Various Artists" to be another name, just to satisfy people who haven't got compilation albums but decide to label them as being by Various Artists.  Various Artists is the correct name to use, and many users are happy with it.

If that causes problems, change the configurable name, or correct your tags. Setting a compilation indicator would then show them correctly.

I personally would like a Browse Compilations option, moving compilation albums out of the Browse Artists list.  That would be less confusing.  However, it probably hasn't been done, because it depends on people having true compilation albums (not just named Various Artists).  I have done the equivalent using CustomBrowse instead.

If the data was correctly entered, there's more opportunities for adding nicer ways of browsing the music library.

i don't know why ANYONE would "resent" this, honestly, that seems out of place.

also, remember, its not about me.  a user can come to SC with his files tagged by gracenote, or himself, and those tags will have "Various Artists" for album artist.

or a user might decide they simply want to use the string "Various Artists" for their artist tag.

OR someone might even have music by a specific band with the gimmick name "Various Artists"

in ANY of those cases, SC blows it.

the simple and easy fix is that SC simply changes the default special case name to something unlikely to ever be used by anyone.  this shouldn't hassle you or anyone else, b/c you can configure it back to "Various Artists" if you want.

SC/slim should try to avoid an issue like this that there is no question but that many users will run into it, and they easily can, they just have to choose to do so.

they could even use "-Various Artists-"  ...that would be enough.

>the simple and easy fix is that SC simply changes the default special case name
>to something unlikely to ever be used by anyone.  this shouldn't hassle you or
>anyone else, b/c you can configure it back to "Various Artists" if you want.
>
The simple and easy fix is for the user to change the default compilation name in the settings.  Better still, improve their tags.

If SC were to change the default name, that would break things for a lot of existing users.

no, it is easier to avoid the problem FROM THE START, which would be what changing the default SC name would do.

and you don't explain AT ALL how SC changing the default name would "break things" for existing users.

and when you say "improve your tags" thats nonsense.  who are you to say that the "Various Artists" string is wrong?  you can make a case that it is, and i certainly see and understand your points, but to act as if you are the final authority on it is more than a little presumptuous, imo.

>and you don't explain AT ALL how SC changing the default name would "break
>things" for existing users.
Isn't that obvious?  If SC were to change the default name from "Various Artists" to "Compilations", then existing users would not see "Various Artists" any more.  When browsing albums, they would not be reported as "<album> by Various Artists".

>and when you say "improve your tags" thats nonsense.  who are you to say that
>the "Various Artists" string is wrong?
There is no such thing as an artist called "Various Artists".  But I wasn't suggesting that people change that if they depend on it for other apps, if that's how they want it to work.

I'm suggesting that if they want it to be considered as a compilation in SC with minimal fuss, they can add COMPILATION=1, which would be an improvement to their current tags, such that the hidden albums appear as compilations correctly.

>but to act as if you are the final authority on it
Oh give me a break.  I'm merely trying to make useful suggestions to aid the understanding of the problem.

>is more than a little presumptuous, imo.
I could say the same about you!

>>and you don't explain AT ALL how SC changing the default name would "break
>>things" for existing users.
>Isn't that obvious?  If SC were to change the default name from "Various
>Artists" to "Compilations", then existing users would not see "Various Artists"
>any more.  When browsing albums, they would not be reported as "<album> by
>Various Artists".

oh no!  a disastor...  (one they could simply change back to "Various Artists" IF that worked for them).

first off, <album> by "VA" or "-Various Artists-" or "Various Artists-" or "(Various Artists)" or "Compilations" isn't BROKEN, its just DIFFERENT.  and it could be changed [back] to whatever works for you, including "Various Artists"

second, the point is to avoid a problem that is ABSOLUTELY going to happen to a not insignificant amount of users.  logitech def is trying to "dummyproof" the system, and this is a way to help in that regard.

>>and when you say "improve your tags" thats nonsense.  who are you to say that
>>the "Various Artists" string is wrong?
>There is no such thing as an artist called "Various Artists".  But I wasn't
>suggesting that people change that if they depend on it for other apps, if
>that's how they want it to work.

there is a band called "The The" but there is no such thing as a band called "Various Artists"?  and you can prove this how?  besides which that isn't the point, (altho i should point out that other posters in the thread said such bands do exist).

the point is that you have no way to say as a final authority that it is wrong to use that string in that field.  where is this bible of tagging that serves as the last word on such matters?

if anything, the DE FACTO standard out there is the most relevant data, even if you think it wrong.  and keep in mind, i am not saying it is right or wrong, i am merely saying its how it is, and SC would be wise to realize that and work with the reality, not how we wish things to be.

>>I'm suggesting that if they want it to be considered as a compilation in SC
>>with minimal fuss, they can add COMPILATION=1, which would be an improvement >>to their current tags, such that the hidden albums appear as compilations
>>correctly.

most mainstream apps don't support that tag, and that tag isn't standard.  again, i am not saying that there's anything wrong with that suggestion, assuming it works right with SC, which i haven't currently verified.  but its so silly to expect to put users thru all these paces who won't expect to be put thru all these paces.

>>but to act as if you are the final authority on it
>Oh give me a break.  I'm merely trying to make useful suggestions to aid the
>understanding of the problem.

no, you are categorically saying it is WRONG to use that string, and i simply ask you to provide me with proof and source of that assertion, and even if you had proof and source, explain how/why it should over rule the de facto standard.

>>is more than a little presumptuous, imo.
>I could say the same about you!

unlike you, i haven't said "here the good word, go forth and obey."  i have said "here is a problem, its based on a reality and environment [gracenote, etc] that is beyond SCs control, so here is my suggestion of how SC could best deal with the issue that doesn't make any judgments and/or most minimally forces anyones hand."

big difference.

"Various Artists" has been the name used for representing Compilation albums in SC for several years now - many people use it.  It should not change to aid a few fringe cases where users don't want to change their tags to be more correct.

>the point is to avoid a problem that is ABSOLUTELY going to happen
Like I said, it's been like this for a few years.  It hasn't been a big disaster yet... how long do we have to ABSOLUTELY wait for this problem to happen?

>the point is that you have no way to say as a final authority that it is wrong
>to use that string in that field.  where is this bible of tagging that serves
>as the last word on such matters?
>
I'm not saying people should change their Album Artist from "Various Artists", if that's what they want.  If they want to keep that naff name, they can.  It's only text.  If they want that, then add a compilation tag.  Or change the default name SC uses to represent compilations from "Various Artists" to something else, if the user doesn't want an artist called "Various Artists" to be a compilation artist.

>most mainstream apps don't support that tag, and that tag isn't standard.
>
A compilation tag is standard in all tagging formats, except id3v2.3.

In id3v2.3, it is a standard to allow custom tags, and COMPILATION is a valid custom tag.  iTunes, probably the biggest maistream app, and Mp3Tag, one of the leading mainstream tagging apps, and other apps, support a de facto standard TCMP frame that represents Compilation.

>"Various Artists" has been the name used for representing Compilation albums in
>SC for several years now - many people use it.  

so what?  so that somehow means its law?  that it can't change?

even "Various Artists." (with a period) would work.

if we know there is an issue that could be avoided, and there is a way for you to put it back to how you want it easily, why in gods name would you fight it?  

slims whole push as far i can tell is to make things easier and just work from the start; this aids in that.

>It should not change to aid a
>few fringe cases where users don't want to change their tags to be more
>correct.

few fringe cases?  its how CDDB/GRACENOTE does ALL such albums.

you do realize, SC/slim is aiming for mass market users don't you?

>>the point is to avoid a problem that is ABSOLUTELY going to happen
>Like I said, it's been like this for a few years.  It hasn't been a big
>disaster yet... how long do we have to ABSOLUTELY wait for this problem to
>happen?

you don't have to wait at all.  it already affects any users with tags by gracenote, and cddb/gracenote works with some mainstream apps.

users probably are either:

A. unaware or haven't noticed music is missing
or
B. know something is wrong, but SC might be doing so many things to their music that they don't know THIS bug is whats causing this specific issue.

>>the point is that you have no way to say as a final authority that it is wrong
>>to use that string in that field.  where is this bible of tagging that serves
>>as the last word on such matters?
>I'm not saying people should change their Album Artist from "Various Artists",
>if that's what they want.  If they want to keep that naff name, they can.  It's
>only text.  If they want that, then add a compilation tag.  Or change the
>default name SC uses to represent compilations from "Various Artists" to
>something else, if the user doesn't want an artist called "Various Artists" to
>be a compilation artist.

see, this is where we disagree...  i'm not saying those solutions work or don't work, but at first glance i'd guess they do work.

but that isn't the point, the point is that SC should anticipate problems it knows about, and do something to try to avoid them, rather than leave it totally on the user to actually identify the problem, and then correct it.

i think what i am saying makes the most sense, esp given logitech's push for dummyproof simplicity.  you seem to think leaving this landmine in place and getting a user to address it post explosion, (if they even realize they've stepped on it to begin with) is the better course of action.  but i see no way to justify that POV, and just saying "SC has done this for years" is not going to cut it.

>>most mainstream apps don't support that tag, and that tag isn't standard.
>A compilation tag is standard in all tagging formats, except id3v2.3.

and 2.3 (or 1.1) is what i was talking about, and represent the HUGE portion of the marketshare.

>In id3v2.3, it is a standard to allow custom tags, and COMPILATION is a valid
>custom tag.  iTunes, probably the biggest maistream app, and Mp3Tag, one of the
>leading mainstream tagging apps, and other apps, support a de facto standard
>TCMP frame that represents Compilation.

indeed thats true, but a lot of good that does a WMP user.

again, the point is SC/slim should de-boobytrap their App, esp if their goal is to make it "easy" and "just work" for new users, as i keep hearing the devs say.

look, you have your opinion, i have mine, and the devs can read this thread and decide what to do about it.  who knows, maybe the new schema will invalidate this whole bug and argument, and neither solution will be necessary.  lets hope so.

i haven't tested it, but i saw some posts in the forums that made it sound like this bug might apply if TPE1=Various Artists as well.  just wanted to put it here b4 i forgot.  :)

If all contributing artists are "Various Artists", then the artist name that the album will appear under would also be "Various Artists", so yes, it is the same issue of having a Various Artists album artist, without a compilation flag set.

So, it's the same type of fix.  Either:
1. Add a compilation flag to the album if it is meant to be a compilation
2. Change the artists to be the correct artist names
3. Change the Squeezebox Server compilation artist name in Library Settings to be something else.

4. Suggest some weird fix where compilations and non-compilations with the same Various Artists name are shown together [dangerous], or show two Various Artists artists in the Artists list (one being the special one for compilations, the other for non-compilation Various Artists albums).

Suggest the best thing for users to do is fix their tags.

or the easiest fix of all, simply change the default "special SBS category" name of "Various Artists" to be ANYTHING else, such as: "-Various Artists-" or "Various Artists." ...so as not to conflict out of the box with tags a lot of users and mass-tagging sources will foist on SBS, (rightly or wrongly depending on one's POV).

(of course the option to do this already exists in the settings, however a user would have to be aware of the issue and know to do it if they were one of the affected, which is not a given or even likely.  if a user objected to the default name being changed to one of the suggestions above, as Phil does, they could simply change it back in their own usage to "Various Artists"  this would be best as it would avoid the problem which is GUARANTEED to occur with ANY user who has "Various Artists" in TPE1 or TPE2 and no comp tag, like ALL winamp users or WMP users)

Phil,

two simple questions here:

1. do you agree that 9523 represents an actual bug in SBS?

(i am guessing from your previous entries you do NOT agree, that you think the problem is not with SBS, but rather with the users, via their tags that their apps, which you don't approve of, like WMP, winamp, and so on, gave them)

i am further guessing that basically, in your view, SBS should not change at all, correct?  that there is no problem here, from the SBS POV.

2. if you do blame the users/apps/tag sources 100%, and not SBS at all, then my next question is how do you expect them to know they are "at fault" for whatever it is you blame them and their apps/tagging sources for?

ie. since the issue is EASILY hidden (not noticeable) by SBS, (since the tags work just fine in EVERY OTHER APP), and not at all obvious, especially if a large collection is brought to SBS, then how do you expect them to know anything is wrong?  that anything needs to be fixed or adjusted?

i would REALLY like to know how you expect them to know to do something if they don't catch the problem.

thx.

still waiting for a reply.

btw, this bug is related to bug 10942

(In reply to comment #20)
> still waiting for a reply.
> 
I wasn't going to bother, as I didn't have anything new to add, and it doesn't look like any developers have any enthusiasm/time to spend on this anyway.

To repeat again what I have said in the past, I think there should be a separate "Browse Compilations" browse menu, instead of the special "Various Artists" sub-tree within Browse Artists, which obviously would only list albums that are compilations (regardless of artist/album-artist name).

Then Browse Artists and Browse Albums menus should show all artists/albums, regardless of whether an album is a compilation or not.  Trying to mix the two browse methods in one browse menu is the underlying issue.

I have achieved this in my SBS using Erland's Custom Browse plugin, and this behaviour matches iTunes.

(In reply to comment #21)
> (In reply to comment #20)
> > still waiting for a reply.
> > 
> I wasn't going to bother, as I didn't have anything new to add, and it doesn't
> look like any developers have any enthusiasm/time to spend on this anyway.

"nothing new to add"???  Phil, other than comment 8 which really didn't explain itself, this is the FIRST time in this bug you have suggested the below, and its TOTALLY different then your past "solution" which was "screw the user, why should SBS change???  let them eat cake (and "fix" their tags)" ...even though nothing is wrong with their tags and the SBS issue is totally masked, so they wouldn't know to do anything anyway, or what was "wrong" even to begin with.

btw, you totally dodged my two questions, as i thought you would.  but no matter, i am fine with your proposed solution below AS LONG AS...

> To repeat again what I have said in the past, I think there should be a
> separate "Browse Compilations" browse menu, instead of the special "Various
> Artists" sub-tree within Browse Artists, which obviously would only list albums
> that are compilations (regardless of artist/album-artist name).
> Then Browse Artists and Browse Albums menus should show all artists/albums,
> regardless of whether an album is a compilation or not.  Trying to mix the two
> browse methods in one browse menu is the underlying issue.
> I have achieved this in my SBS using Erland's Custom Browse plugin, and this
> behaviour matches iTunes.

..it works...?  let me clarify:

this is FINE with me, and certainly sounds better than the current buggy implementation.  my only question is, what would happen in the following situations?

1. a user has an AA of "Various Artists" with no comp tags.  would it then just show up, as it should, as just another artist in the home>albums and home>artists list?  (and browse compilations would be empty presumably)

2. a user has an AA of "Various Artists" with explicit comp=1 tags.  would it then show up in ONLY the 'browse compilations' menu or would it show up there AND in the home>albums / home>artists list?

personally, for #2 i'd like to see such tracks in all the areas, not just browse comps. 

lets agree then to make this the proposed way forward, so users are no longer afflicted by this issue.  i don't think SLIM/Logitech/Devs should have a beef with doing it this way, as it can be easily explained that if one wants their VA tagged stuff to show up in browse comps, they need to add explicit comp tags.  that may not be perfect, but its not horrible either, and certainly lightyears better than what we have today.

btw, your bug, which seem to want to address this bug, should have mentioned this bug, imho.

bug 15604

and arguably relatedly:

bug 18362

correction:

bug 16362

> this is the FIRST time in this bug you have suggested ...
I didn't bother to read through all posts again.  I'm sure I've mentioned it in many many places before; surprised if it's not in this one too.

I did: comment 8 - "I personally would like a Browse Compilations option".

> btw, you totally dodged my two questions, as i thought you would.
I didn't dodge it - I have nothing further to add to what I have already said in previous posts.

> 1. a user has an AA of "Various Artists" with no comp tags.  would it then just
> show up, as it should, as just another artist in the home>albums and
> home>artists list?  (and browse compilations would be empty presumably)
> 
Yes.  All artists that have albums would be listed.

> 2. a user has an AA of "Various Artists" with explicit comp=1 tags.  would it
> then show up in ONLY the 'browse compilations' menu or would it show up there
> AND in the home>albums / home>artists list?
> 
Personally, when using Browse Artists, I'd prefer not seeing artists that are only for holding Compilation albums, as I'd always look for these under Browse Compilations.

But when browsing albums, it shouldn't matter if an album is a compilation or not - all albums would be listed (with the album artist, band or artist label as appropriate, depending on settings).

(In reply to comment #24)
> > this is the FIRST time in this bug you have suggested ...
> I didn't bother to read through all posts again.  I'm sure I've mentioned it in
> many many places before; surprised if it's not in this one too.
> I did: comment 8 - "I personally would like a Browse Compilations option".

did you even read my comment you are responding to???  i said:

> "nothing new to add"???  Phil, other than comment 8 which really didn't explain
> itself, this is the FIRST time in this bug you have suggested the below,

did you miss that?

like i said, comment 8 hardly explained anything.  but whatever, lets get on the same path...

> > btw, you totally dodged my two questions, as i thought you would.
> I didn't dodge it - I have nothing further to add to what I have already said
> in previous posts.

you didn't answer the questions, ergo you dodged it.  thats pretty much the definition of dodging.  but again, whatever, i am more than happy to support your proposed fix, which makes sense to me.

> > 1. a user has an AA of "Various Artists" with no comp tags.  would it then just
> > show up, as it should, as just another artist in the home>albums and
> > home>artists list?  (and browse compilations would be empty presumably)
> > 
> Yes.  All artists that have albums would be listed.

perfect.  sounds good to me.

> > 2. a user has an AA of "Various Artists" with explicit comp=1 tags.  would it
> > then show up in ONLY the 'browse compilations' menu or would it show up there
> > AND in the home>albums / home>artists list?
> > 
> Personally, when using Browse Artists, I'd prefer not seeing artists that are
> only for holding Compilation albums, as I'd always look for these under Browse
> Compilations.

can you clarify this?  do you mean to say that if an AA tag was "Soundtrack" you would not want the individual artists listed, OR you would not want the AA tag value listed in the normal artist list, or both?  (i'm guessing you would say both)

imo, both things should be a toggle/option.  i think someone should be empowered to put AA tags in the home>artists list IF they want them there, and they should also be empowered to put all the individual artists of a comp in the list too if they want, or both, or neither.

so 4 settings for home>artists:

normal artists
albumartist + normal artists [but no 'comp only' artists]
albumartist + normal artists + 'comp only' artists
normal artists + 'comp only' artists [but no 'unique' albumartist]

the logic would have to be smart enough for the fourth setting to realize that when the artist = albumartist thats a normal artist, ergo omitting only "unique" albumartists.

this starts to get into the whole ide that forcing an either/or situation of artist tag OR albumartist tag, into the ONE SBS DB field of "artist" is a bad design, imo.  but even so, even as it is today, what i am saying and what you are proposing could work with the current implementation.

> But when browsing albums, it shouldn't matter if an album is a compilation or
> not - all albums would be listed (with the album artist, band or artist label
> as appropriate, depending on settings).

perfect, that sounds good too.

i think this overall task should be done, probably in bug 15604, and with some sense of urgency, b/c its not only more intuitive as you point out, but it will solve the "out of the box" bug i have described in great depth here, a bug which is a lot more prevalent than is known, b/c it is so well masked.

This long standing bug needs fixing.

SBS is not handling files created by two of the most common rippers out there - WMP and Winamp, which use AA = "Various Artists and which do not set the Compilation tag. Bug 16991 provided evidence that this is still true for WMP12 in Windows 7.

This discussion has, I think made it sound so complicated no one wishes to touch it! but it is actually quite simple. The quickest, maybe a short term fix) is:

[PSUEDO-CODE]
If "Album Artist" = "Various Artists" THEN set SBS-COMPILATION=YES (regardless of the state of the Compilation Tag, or if you like, only if the compilation tag is missing)
[/PSEUDO-CODE]

The only possible problem with this is I do not know if it works for
non-English installations. If they use a local translation for "Various
Artists" when ripping it will not be picked up. However, it will not break
anything for any one, nor affect any ones library in a negative way.

The better solution IMO is to add a field in SBS config: "Album Artist value(s) which indicate an album is a compilation". By default, this would have "Various Artists", but people could add others, separated by commas. You then apply the same test as above using all the values entered into SBS settings. The user can remove them all if he wishes. But this better solution could follow later. The quick solution solve the problem of albums created by those two very common tools disappearing from artist view, which is true right now.

(In reply to comment #26)
> SBS is not handling files created by two of the most common rippers out there > WMP and Winamp, which use AA = "Various Artists and which do not set the
> Compilation tag.
>
SBS is handling them, but not displaying them in Browse Artists > Various Artists, because it expects them to be compilations.

A very simple work around for you, if you don't want to make your tags better, is to change the SBS compilation album artist name from "Various Artists" to anything else (via Settings > My Music > "When compilation albums are grouped together, they appear under "Various Artists" by default. You can change that name below.").

Your non-compilation Various Artist albums will then be visible under an artist called Various Artists, which you will find sorted under "V" (not at the top of the artist list).

> This discussion has, I think made it sound so complicated no one wishes to
> touch it! but it is actually quite simple.
> 
It is not complicated.

> The quickest, maybe a short term fix is:
> If "Album Artist" = "Various Artists" THEN set SBS-COMPILATION=YES (regardless
> of the state of the Compilation Tag, or if you like, only if the compilation
> tag is missing)
> 
No, this is not a good idea to hard-code names, and making them configurable just adds to the complexity too.

In fact, it wouldn't even necessarily be the correct behaviour - there may be some albums that have an artist of "Various Artists" that are not compilations (I used to have one in my library).  i.e. where many artists perform on an album, but the same set of artists perform on every song, and there's too many to list on each song.

There shouldn't be an association between album artist names and compilation status.

> The quick solution solve the problem of albums created by those two very
> common tools disappearing from artist view, which is true right now.
>
Not true - waiting for a solution that requires developers to develop a fix, whether it is a quick bodge or a better solution, would be to simply add the Compilation tag to those albums, using a better tagging too (eg. Mp3Tag).  This is still compatible with all apps (the ones you mention would ignore it), and would then also give better functionality in SBS and other apps, such as iTunes.

Phil, you obviously have strong views on this, as do we. That is fine. But there is one simple fact you have wrong. You say "SBS is handling them, but not displaying them in Browse Artists > Various
Artists, because it expects them to be compilations", this is just wrong. Such albums are not displayed AT ALL under artists, just because their name is "Various Artists". All other values of "Album Artist" can be displayed. It is SBS that is treating this name as something special.

It is also just a simple fact that several very popular tools do attribute special meaning to "Album Artist" = "Various Artists". The argument on whether this is right or wrong needs to be taken up with them. SBS should make as best stab as it can of displaying people's music correctly without re-tagging.

I understand your point about hard-coded names. Thinking about it though it should not be hard-coded it should be "Various Artists" or whatever is in the "When compilation albums are grouped together, they appear under "Various Artists" by default. You can change that name below" box.

You say "it wouldn't even necessarily be the correct behaviour" but your example is pretty rare! If you are concerned that SBS gets it right in such a rare case,, surely it should get it right for this incredibly common case of music tagged by WMP or Winamp, which use Album Artist, but not Compilation.

I'm not even sure your example is valid you talk about "Artist" being "Various Artists". Well that would not be an issue. We are talking about "Album Artist" being "Various Artists". It would indeed be a strange album that was sold with both "Artist" and "Album Artist" being "Various Artists", but it not being legitimately called a "Compilation"! Maybe you could provide the name of this album?

I agree the quickest solution is for me personally is to re-tag, although your solution until (hopefully, yet to test) today's nightly build would not have worked for WMA files. SBS until yesterday ignored the "compilation" tag set by MP3Tag, dbPowerAmp and even W7, in WMA. Andy fixed it yesterday in Bug 16911. In fact I have retagged in a different way for now (making AA = "Various" instead of "Various Artists"). But the point Mike has made several times is you cannot impose this on all people who use WMP, Winamp or others to tag their music just to avoid SBS hiding their stuff due to its own hard-coded behaviour concerning Album Artist. SBS has made the problem it needs to fix it.

But, this could go on forever. I could understand your resistance to this if it negatively affected you, but the suggestion should have no impact whatsoever apart from, maybe, some action with this special "Various Artists" album you mention. However, this is CERTAINLY likely to be a MUCH rarer case than all the people using Winamp/WMP, who are currently affected.

> there is one simple fact you have wrong. You say "SBS is handling them,
> but not displaying them in Browse Artists > Various Artists, because it 
> expects them to be compilations", this is just wrong.
>
With all due respect, I did not write anything wrong with my last comment.  I am fully aware that non-compilation albums labelled with album artist="Various Artists" does not appear within the Browse Artists view.
SBS *does* handle the album, in that it does keep songs on the album together, it does appear as an album in the Browse Albums view, and the album can be played.
The album not appearing in the Artists lists is localised to this context.  It is easily solved by simply adding a compilation tag to the music files, without affecting any other app.  Or, if not modifying files is for some reason important, it is easily avoided within SBS by changing a single config item within the SBS settings.

My proposed solution of creating a way to browse compilation albums separately would also resolve the Browse Artists solution, and be consistent with other apps that do support Compilation tags (eg. iTunes, iPods, etc).  This would help have consistency for people that sync their SBS library from an iTunes library.

There may be other equally viable solutions, but any proposed solution is unlikely to be made by developers and go live before 7.6 release (and I suspect you won't see a change either for 7.6).

 Such
> albums are not displayed AT ALL under artists, just because their name is
> "Various Artists".
Not specifically "Various Artists" but that it matches the SBS config setting, which happens to be "Various Artists" by default.  Change this value and you will have your intended behaviour, where Various Artists albums will not be treated as compilations but will be displayed in Browse Artist list.

> All other values of "Album Artist" can be displayed. It is
> SBS that is treating this name as something special.
>
Not completely correct; SBS is treating albums with Compilation=1 as something special; there are no hard-coded rules that are looking for a specific album artist name.  It doesn't make the situation any better (and you may consider the end effect the same), but I'm merely pointing out that the SBS setting is only used for auto-assigning the album artist name, and thus for the display of the album artist to the user.

> It is also just a simple fact that several very popular tools do attribute
> special meaning to "Album Artist" = "Various Artists".
Are you sure they actually have special logic applied when album artist = Various Artists?  I'm pretty sure there is no special logic; only that this is an adopted label value that gets assigned to such albums.

> I understand your point about hard-coded names. Thinking about it though it
> should not be hard-coded it should be "Various Artists" or whatever is in the
> "When compilation albums are grouped together, they appear under "Various
> Artists" by default. You can change that name below" box.
> 
That would be better, yes.  It would require a forced rescan for a change in the setting to have an effect on the library content, which isn't indicated in the settings page.

> You say "it wouldn't even necessarily be the correct behaviour" but your
> example is pretty rare!
>
Probably right.  I don't know how often it may happen in people's library, but it's probably not a normal occurrence.  The issue is that users may have this situation, and would be affected by a change.  It might happen more for some users than others.  eg. people that collect tribute concerts, etc, where Various Artist albums may not be considered compilations.

> If you are concerned that SBS gets it right in such a
> rare case,, surely it should get it right for this incredibly common case of
> music tagged by WMP or Winamp, which use Album Artist, but not Compilation.
> 
Hence better if files were tagged appropriately to remove guesswork and special case logic, so SBS doesn't get it wrong some times.

> I'm not even sure your example is valid you talk about "Artist" being "Various
> Artists". Well that would not be an issue. We are talking about "Album Artist"
> being "Various Artists".
Are you saying that albums where artist=Various Artists without an album artist tag do get listed correctly with Browse Artists list?

Anyway, the album artist may also be set to the same value as the artist name.  In either case, SBS would treat that as a non-compilation album as the artist name is constant, or there is an album artist defined without a compilation tag.  This is not incorrect.

> It would indeed be a strange album that was sold with
> both "Artist" and "Album Artist" being "Various Artists", but it not being
> legitimately called a "Compilation"! Maybe you could provide the name of this
> album?
> 
"A Special Tribute To Pink Floyd".  I can attach the Back cover artwork later if you like.  But effectively there's about 30 names of artists that appear on the songs, without defining exactly who is playing on each track.  It would potentially be possible to list all 30 artist names on every track, but for convenience, and for lack of more detailed info, a single "Various Artists" is assigned to each song, but the album isn't a compilation (some people might decide to label the album artist as "Pink Floyd" or "Tribute", etc, but I consider it a normal album (not a compilation) and not an album by Pink Floyd, etc).  Other people may assign only the singer for each track as the artist, and then set the album artist as Various Artists, and would consider the album a compilation.  There's no right or wrong way, really.

> I agree the quickest solution is for me personally is to re-tag, although your
> solution until (hopefully, yet to test) today's nightly build would not have
> worked for WMA files.
Oh, I didn't know that WMA compilation tag was not being read - sorry.  Point taken.

> But the point Mike has made several times is you
> cannot impose this on all people who use WMP, Winamp or others to tag their
> music just to avoid SBS hiding their stuff due to its own hard-coded behaviour
> concerning Album Artist. SBS has made the problem it needs to fix it.
> 
I don't disagree with this.  I was only suggesting that tagging is always the best option to guarantee success everywhere, and would not break other apps, and that a workaround has already been identified, which is no more/less a bodge than some rule based on album artist name content.  It's available now, which would be quicker than waiting for a fix, for which I'd prefer waiting a little bit longer for a proper fix/reworking the way that compilation albums can be browsed.  If a bodge fix is put it, it might detract from ever applying a nicer browse mechanism.

> I could understand your resistance to this if it negatively affected you
>
It *could* negatively affect me and others:
- potentially could make scan time longer, as it would need more complex auto-detection logic in determining compilation albums.
- more potential for side effects, bugs, more confusion for further maintenance.
- detract limited development resources away from fixing other bugs or new enhancements that might be more worthwhile.
- fringe cases for users (inc. me), where Various Artists has been used for some non-compilation albums (probably rare, but no-one can really know how users apply their own tagging regime).

Phil,

i have to laugh at your pretzel logic, its like you were in Steely Dan.  ;)    honestly, it would be better to just acknowledge the other side has a stronger case than to not back down from your initial viewpoint.

you have proposed bug 15604 but even that contradicts your earlier view of "resenting" SBS having to change the boobytrap name/SBS function of VA.  if you are willing to enact bug 15604 why then oppose changing the current default "special category" name of VA in SBS to something SLIGHTLY different that solves the issue out of the box, right now, today, without requiring much effort from the devs?  you'd still have a way back to any name you wanted to use, incl.VA.  but somehow, you can't allow that to happen, for you, thats verbotten.  ridiculous.

you also never address the FACT that most users affected by this will NOT be aware of it unless they are lucky enough to happen to notice it, (as i was, four years after starting to use SBS), and even then they will have to research it to find the fix!  after that, they have to either change their tags or SBS settings out of a normal default; but that doesn't bother you.

you constantly raise the boogeyman of "bad things could happen by making changes" but that never bothers you for changes you want to see.  there also is no reason to think its true.  eg. as i said before, a user could void the entries for string tag recognition just as they can for guess tag format.  if there are no entries, you will not be affected.  but boogeymen persist in your argument.  the boogeyman did not get anyone when bug 8001 or bug 8380 was enacted, regardless of your dire warnings.

string recognition should not be hardcoded, i agree with that, (thus negating your silly example of VA on a non-comp), but should be available to the user, b/c there are a lot of users who want their comps recognized as comps (not just displayed) by SBS, but don't want to have to learn yet another app or be bothered to add comp tags.  why force them to do that?  why not just allow SBS to recognize AA strings IF the user sets SBS to??  that doesn't negatively affect you AT ALL.  (void = the logic isn't invoked, ie. dead code)

[and btw David, you don't want to conflate the proposed user defined string recognition idea with the setting SBS already has of what the VA category should be called, for multiple reasons]

i understand why SBS doesn't show the files under home>artists but that isn't the same as "handling it."  to say that SBS DOES handle it, when it effectively masks and hides the files from the user, with no indication it does so, or how to fix it, is like a fat chick saying she's going to lose weight drinking diet pepsi!  its just ridiculous.  SBS handles it by getting it screwed up, thats how its "handled."

finally, i have to comment on this silly VA = not a comp album.  first of all, as David said, how many people are in that boat, compared to how many use winamp and WMP?  secondly, you could leave AA blank, or you could set a comp=0 tag, or you could set AA tags to equal A tags, or AA could equal "Pink Floyd tribute" (which is how i do it).  the idea that this is the reason the devs can't address 9523 is laughable.  an album btw, you "USED" to have, and one that by the sounds of it, most people would tag differently/subjectively.

to sum up:

like i said before, i will go with bug 15604 just to get the fix done.  but there is no reason this serious bug from 2008 should languish when a simple fix could be done by the devs of changing the special category name, a "find and replace" fix more or less.  secondly, that issue aside, the user should be empowered to have SBS recognize something is a comp by string recognition IF they want to.  thats b/c lots of things are comps with AA tags but no comp tags, thats how many apps work.  SBS should accommodate common scenarios, not strongarm users into using yet another app just to apply comp tags.  comp tags are not some universally supported feature the way AA tags are.

you keep saying things like users should "appropriately tag"  ..well guess what, they ARE appropriately tagged!  its SBS that doesn't handle the situation appropriately!

its not about, and shouldn't be about, what you consider to be "someone making their tags better."  what it SHOULD be about is making SBS BETTER!

frankly, this ALL should be obvious to everyone.

(In reply to comment #30)

This is not a place to chat - suggest you take your issues to the forum.  To be honest, even I can't be bothered to read your messages any more, so you'll probably be ignored wherever you take your attitude.

There is already a workaround, and there is total avoidance by doing the right thing by adding the compilation tag.  One of several fixes suggested here could also be applied; some are temporary fixes, some are enhancements for better music browsing that also fix this issue.  A developer can now choose to do one of these or nothing, and I don't know if there is much added value discussing further here (the more comments on this bug, the less likely it is that anything will happen).

I don't think you've added any extra value to what has already been said, other than "your view is crap, my view is perfect" in your usual childish way with slander, etc.

Just some comments to finish off:

> finally, i have to comment on this silly VA = not a comp album.
It's not silly at all.  I may have others that are like this.  Others may also.  Artist="Various Artists" doesn't mean it's a compilation album.  SBS has a distinction between compilations and album artist names.  Whilst it is true that most of the time people probably are happy with Various Artists albums being labelled as compilations, song by Various Artists are not necessarily part of compilation albums.
I merely mentioned it as a possible issue to be considered; not as a reason for not making a change.  I mentioned it because I had that situation in my library; it was a real case.  In fact I still have that album, it's just I had a duplicate, because I have the same album duplicated (same album with different names, that I didn't initially realise was due to a re-issue).

> there is no reason this serious bug from 2008 should languish when a simple
> fix could be done by the devs of changing the special category name,
> a "find and replace" fix more or less.
>
That could seriously change behaviour of users albums upon a rescan.  Albums with differing artists without an album artist would not then appear under their usual "Various Artists" name.
Potentially such a change could be the default for new installations, and not change prefs for existing libraries, but new users would then see different content to other users.  And what would the new default be?  It should be something useful, but another default value may cause the same issue for different users.  eg. if some people have Album Artist="VA" or "Various", etc.  It could be changed to "I NEVER WANT TO SEE THIS COMPILATION ALBUM NAME", but that's not a sensible default.

> secondly, that issue aside, the user should be
> empowered to have SBS recognize something is a comp by string recognition IF
> they want to.
No - why?  Does any other app do that?  Why should SBS?
Guess Tags was a bit of a mistake in SlimServer, which has cause no end of confusion for users.

> thats b/c lots of things are comps with AA tags but no comp
> tags, thats how many apps work.
>
Then they should be treated as non-comps in the same way.  All that is being argued is that they should be visible within SBS, not hidden.  It doesn't mean that SBS has to start guessing whether albums are comps or not based on tag values.

> you keep saying things like users should "appropriately tag"  ..well guess
> what, they ARE appropriately tagged!
Then if a user hasn't set the compilation tag, it should not be displayed within SBS as a compilation.  If the user does want it to be a compilation and an album artist is present, the compilation tag must be set.  That is appropriate tagging.

SBS scanner is handling the situation.  SBS Browse Artists view is the only thing that is not displaying the album due to complexities of mixing compilations and non compilations together.

Slander?  are you crazy?  what slander?  i attacked your argument, not you.  you however attack me without compunction.

i love how you ignore such inconvienent questions as "how would a user even know/notice they are affected?"

and to respond to the points you did make, if a user has one of your "rare" type CDs, which you claim is appropriately tagged (while how others tag is wrong in your view, funny how you can simultaneously claim that) then unless they have a comp tag, and you say it isn't a comp, THEY ARE AFFECTED TOO.  if the string "Various Artists" is in AA or in A in the tags, then SBS masks it!

i love how you say doing the "right thing" is adding an itunes invention, but that wouldn't work for your non-comp VA cd.  brilliant.

i also love how you think people are somehow, not doing the "right thing" if they don't want to add comp tags.  what makes it wrong, to not want to have to do that?  why on earth do you think anyone should?  to satisfy SBS?  SBS is to satisfy customers, not be satisfied by them.

guess tag format isn't "a mistake," esp if you use wav files or other untaggable formats.  its amazing your myopic view on these things, you think no one out there wants or benefis from it?  guess tag format kept things from being hidden from me in some cases.  

phil says:
>>
That could seriously change behaviour of users albums upon a rescan.  Albums
with differing artists without an album artist would not then appear under
their usual "Various Artists" name.
Potentially such a change could be the default for new installations, and not
change prefs for existing libraries, but new users would then see different
content to other users.  And what would the new default be?  It should be
something useful, but another default value may cause the same issue for
different users.  eg. if some people have Album Artist="VA" or "Various", etc. 
It could be changed to "I NEVER WANT TO SEE THIS COMPILATION ALBUM NAME", but
that's not a sensible default.
>>

thats right, thats the whole point, they would show up for ALL users under whatever the NEW default name would be, like for example "Various Artists." or "-Various Artists-" or whatever, just something that isn't in OBVIOUS CONFLICT with WMP/winamp/AMG/Gracenote, etc...  THATS THE WHOLE POINT!

you and others like you could then switch it back if you liked!  but no, you have to fight it tooth and nail for no good reason!  amazing!

and you say you're against doing that HERE IN THIS BUG, b/c the default name of "Various Artists" is scared to you apparently, BUT MEANWHILE you have no problem suggesting in bug 15604 to change it to something totally different!  remarkable!

i don't know if any other app recognizes strings or not, but whether any others do or not isn't the point.  the point is users who use AA tags but not comp tags should have a way to ID comps to SBS without using comp tags.  there's no good reason to fight that.  besides, some apps, like winamp, strip comp tags on edits.  while i agree they shouldn't, thats also not the point...  SBS has to deal with what users actually bring to it, not what it WANTS users to bring to it.

i love this one:

>> thats b/c lots of things are comps with AA tags but no comp
>> tags, thats how many apps work.
>>
>Then they should be treated as non-comps in the same way.  All that is being
>argued is that they should be visible within SBS, not hidden.  It doesn't mean
>that SBS has to start guessing whether albums are comps or not based on tag
>values.

like the way SBS assumes anything with an AA tag isn't a comp?  (unless obviously it has a comp tag)  is that what you mean?  and there's no "guessing" involved.  a user would define the strings they want SBS to ID as a comp.  i agree its not part of this bug, but its the next natural extension of it.

more:

>> you keep saying things like users should "appropriately tag"  ..well guess
>> what, they ARE appropriately tagged!
>Then if a user hasn't set the compilation tag, it should not be displayed
>within SBS as a compilation.  If the user does want it to be a compilation and
>an album artist is present, the compilation tag must be set.  That is
>appropriate tagging.
>
>SBS scanner is handling the situation.  SBS Browse Artists view is the only
>thing that is not displaying the album due to complexities of mixing
>compilations and non compilations together. 

i haven't checked other views, (besides home>albums), not that it matters, as home>artists is a fairly important one.

does it get more SBS-centric than this?  its like screaming at a wall.  the user has tags appropriate for not only their app, but ANY APP OTHER than SBS if they have AA tags on everything, including comps.  but you want to say its somehow not appropriate, presumably b/c its not how SBS likes it.  thats just breath taking.

finally, grow up phil, don't get all pissy at me for poking holes in your shoddy, rubbish argument.  its not personal, of that i assure you, its just a matter of logic.

(In reply to comment #32)
Okay, I was quite happy to ignore any further chatter on this bug report, as it wasn't the place for it, but you seem content in not following that basic rule either, so what the hell - I'll take the bait.  Chances are your chatter will cause developers to turn away from looking any further at this problem, which is not a concern for me, because SBS works fine for my needs.  I'd quite like a Compilations album browse mode, which I still think would be the best solution, such that Browse Artists is made really simple with less special logic, and thus quicker, but I can live with it as it is, and have Custom Browse set up with better menus anyway.

You're arguments aren't convincing me any further than all other posts in this thread.  I was trying to have reasonable conversations, but you've brought it to a whole new level, once again.

> i love how you ignore such inconvienent questions as...
How is quite easy; you probably meant why.

> "how would a user even know/notice they are affected?"
> 
Because they can't find an album that they were expecting in the list?  Otherwise, why would they care?

> and to respond to the points you did make
>
Wish I hadn't now...

> if a user has one of your "rare" type CDs
You're right - they may not be as rare as I initially thought - many users might has similar situations.

> which you claim is appropriately tagged
Yes.  Seems appropriate to me that when there are many artists performing on a song, "Various Artists" would be an appropriate name to use.

> (while how others tag is wrong in your view
Where did that come from?  I'm quite happy with the majority of different ways that people may tag.  Some concepts are just wrong, and I'm sure you have the same feelings about other people's tagging behaviour too.

> then unless
> they have a comp tag, and you say it isn't a comp, THEY ARE AFFECTED TOO.  if
> the string "Various Artists" is in AA or in A in the tags, then SBS masks it!
> 
Did you really try that?  Because actually my album is visible within Browse Artists > Various Artists.  The tags for every album have Artist=Various Artists, and there isn't a comp tag:

TALB: Test: A Special Tribute To Pink Floyd
TCON: Progressive Rock
TDRC: 2005
TIT2: Money
TPE1: Various Artists
TRCK: 01/11 

> i love how you say doing the "right thing" is adding an itunes invention, but
> that wouldn't work for your non-comp VA cd.  brilliant.
> 
Are you actually fighting against my suggested solution?  Do you actually think it's the wrong thing to do?  Are you just making an argument for the sake of it?

If you'd actually bothered to read the suggestion, which you probably haven't, you'd know that it would work, because Browse Artists would then not have any special rules for compilations appearing as "Various Artists" at the top of the Browse Artists list.  All artists/album artists would appear exactly as the users tags have specified (whether they are comps or not).  At the same time, a different Browse menu would list only compilation albums.

I'm pretty sure this is what you wanted (all artists displayed in the list), but at the same time people who want to find compilations could do so easily.  And at the same time, performance would be improved, code would be simplified - it would be more maintainable.  Everyone should be happy?

> guess tag format isn't "a mistake,"
Not only my words, but that of a developer a while back.  They mask so many issues that users have, eg. when tags aren't recognised within a file, the default guess tag rules kick in and can have really bad effects on the users music file, followed by lots of posts/bugs.

> esp if you use wav files or other untaggable formats.
>
wav files *do* support some tagging.  There are other solutions, which I have used, such as tagging via cue sheets.

> thats right, thats the whole point, they would show up for ALL users under
> whatever the NEW default name would be, like for example "Various Artists." or
> "-Various Artists-" or whatever, just something that isn't in OBVIOUS CONFLICT
> with WMP/winamp/AMG/Gracenote, etc...  THATS THE WHOLE POINT!
> 
And what about the people who do want albums auto-detected as "Various Artists".  Don't you care about them?

> you and others like you could then switch it back if you liked!
If the change did do that, I would know and could easily sort it out.  But others who do not frequent bug reports and forums could get a nasty surprise.

> but no, you have to fight it tooth and nail for no good reason!  amazing!
> 
Because there's a better solution that fits everyone, and would provide more functionality for browsing music.  I'm not really fighting tooth and nail, either.  I'm pretty happy with what I've got, and any solution wouldn't drastically affect me.  It's true that I'm a perfectionist, but there's always a reason.

> "Various Artists" is scared to you apparently, BUT MEANWHILE you have no
> problem suggesting in bug 15604 to change it to something totally different! 
> remarkable!
>
I don't understand - I haven't suggested in bug 15604 changing Various Artists to something completely different.  Did you actually read the suggestion?

> i don't know if any other app recognizes strings or not
Not that I'm aware of.

> but whether any others do or not isn't the point.
Why?

> the point is users who use AA tags but not comp
> tags should have a way to ID comps to SBS without using comp tags.
>
Why should they?  If they don't want to add a comp tag, and happy with their tagging without for other apps, why should they have a way to set a comp indicator without having to set a comp tag?

Actually they do have a way - remove the album artist tag ;-)

> there's no good reason to fight that.
Yes there is - there's no good reason to have it.

> besides, some apps, like winamp, strip comp tags on edits.
Decent apps don't.  Decent file formats (not id3) are probably treated better.

> while i agree they shouldn't, thats also not the point...  SBS has to
> deal with what users actually bring to it, not what it WANTS users to bring to
> it.
>
If a user has added a comp tag, and it's been stripped out by a faulty app, that's hardly SBS's fault or concern.  SBS shouldn't have to work out that actually the user wanted it to be a compilation, even though it has an album artist, which usually means it is not a compilation.

> like the way SBS assumes anything with an AA tag isn't a comp?  (unless
> obviously it has a comp tag)  is that what you mean?
Yes.  That is SBS logic.

> i haven't checked other views, (besides home>albums)
I did - they are fine.

> not that it matters, as home>artists is a fairly important one.
> 
One that in the past (until today, when you decided to pick a fight) you have on countless occasions said you don't use, because you only ever use Browse Albums, sorted by Album Artist, as you don't want lists without artwork.

(In reply to comment #33)
> (In reply to comment #32)
> Okay, I was quite happy to ignore any further chatter on this bug report, as it
> wasn't the place for it, but you seem content in not following that basic rule
> either, so what the hell - I'll take the bait.  Chances are your chatter will
> cause developers to turn away from looking any further at this problem, which
> is not a concern for me, because SBS works fine for my needs.  I'd quite like a


let me just reiterate, this is NOT personal.  i have no beef with you, just your logic, such that it is.  considering nothing has been done about this since 2008 i really don't worry about cluttering this bug report.  let me also repeat that i support your bug 15604 !!!  i voted for it, i put it in my sig, etc... so its not like i object to what you say here just b/c you say it.  i also let this go, but when David told you some fundamental truths and you basically gave distorted untrue answers, i set the record straight, i'm not picking a fight, i'm calling you on your lack of logic.  you responded to David with some inane nonsense, you're above being corrected?


> Compilations album browse mode, which I still think would be the best solution,
> such that Browse Artists is made really simple with less special logic, and
> thus quicker, but I can live with it as it is, and have Custom Browse set up
> with better menus anyway.


again, i voted for it, and promote it.


> You're arguments aren't convincing me any further than all other posts in this
> thread.  I was trying to have reasonable conversations, but you've brought it
> to a whole new level, once again.
> > i love how you ignore such inconvienent questions as...
> How is quite easy; you probably meant why.
> > "how would a user even know/notice they are affected?"
> > 
> Because they can't find an album that they were expecting in the list? 
> Otherwise, why would they care?


thats the whole point Phil, the WHOLE POINT that you REFUSE to acknowledge!  in a large collection, it would be very easy NOT TO NOTICE.  and even if you did notice, there would be no clues or indications of how to fix it.  further, its easy to imagine a situation where a user had some VA albums with comp tags and some without, not only would would that be even less noticeable, but even if noticed, to a novice it would really be confusing as to wtf is going on.

WHY PUT THE USER IN A SITUATION THE DEVS COULD EASILY AVOID????  ANSWER THAT.


> > and to respond to the points you did make
> >
> Wish I hadn't now...


i like to see ur maintaining your sense of humor Phil, :)


> > if a user has one of your "rare" type CDs
> You're right - they may not be as rare as I initially thought - many users
> might has similar situations.


until now, i have never seen someone tag a non-comp with an AA of VA when all the A tracks share the same set of artists, but i have NO BEEF whatsoever with someone who wants to tag like that, altho i would not.  but your example doesn't in any way mean OPTIONAL string recognition shouldn't be implemented.  thats what i was saying.


> > which you claim is appropriately tagged
> Yes.  Seems appropriate to me that when there are many artists performing on a
> song, "Various Artists" would be an appropriate name to use.


bully for you!  i love how you always cast yourself as the arbitor of what is, and what is not appropriate, for tagging.


> > (while how others tag is wrong in your view
> Where did that come from?  I'm quite happy with the majority of different ways
> that people may tag.  Some concepts are just wrong, and I'm sure you have the
> same feelings about other people's tagging behaviour too.


according to you its wrong to put "Various Artists" in an AA tag, but now suddenly it isn't...  or its ok to put it in the A tag, yet in either case, for this album, with no comp tag, so it wouldn't show up in home>artists b/c of the bug, brilliant!


> > then unless
> > they have a comp tag, and you say it isn't a comp, THEY ARE AFFECTED TOO.  if
> > the string "Various Artists" is in AA or in A in the tags, then SBS masks it!
> > 
> Did you really try that?  Because actually my album is visible within Browse
> Artists > Various Artists.  The tags for every album have Artist=Various
> Artists, and there isn't a comp tag:
> TALB: Test: A Special Tribute To Pink Floyd
> TCON: Progressive Rock
> TDRC: 2005
> TIT2: Money
> TPE1: Various Artists
> TRCK: 01/11 


perhaps you should read your own words, comment 17 in response to my comment 16 is it it slander to use your own words against your argument?

besides, it doesn't make sense...  you must have changed the SBS VA option for what to name the special category, b/c if ALL the tracks shared TPE1=Various Artists SBS would use that to be AA in the SBS DB as you well know, thus your comment 17 so i put it to you that something is out of default in your example.


> > i love how you say doing the "right thing" is adding an itunes invention, but
> > that wouldn't work for your non-comp VA cd.  brilliant.
> > 
> Are you actually fighting against my suggested solution?  Do you actually think
> it's the wrong thing to do?  Are you just making an argument for the sake of
> it?


no, i was making a further point on what i just explained above.

in other words, in default, SBS would mask your TPE1=Various Artists non-comp tagged CD.

you contradict yourself all over the place, and not to mention you constantly build fallacious arguments on false premises of whats "appropriate" tagging.

but i'm not without some graciousness Phil, i support bug 15604 (with the caveat that it does work as intended of course, which is always how i support any bug).


> If you'd actually bothered to read the suggestion, which you probably haven't,
> you'd know that it would work, because Browse Artists would then not have any
> special rules for compilations appearing as "Various Artists" at the top of the
> Browse Artists list.  All artists/album artists would appear exactly as the
> users tags have specified (whether they are comps or not).  At the same time, a
> different Browse menu would list only compilation albums.


i did read it, and i support it.  not the point.  the point is your rare case CD which you used as a reason to NOT support string recognition is itself affected by the current bug described here in 9523!  you do this all the time, you pivot from one point to another never addressing things in proper context.  i don't know if its deliberate ofuscation or not, but its really intellectually dishonest.

and as an aside, as i mentioned before, you would have many workarounds for your rare case CD.


> I'm pretty sure this is what you wanted (all artists displayed in the list),
> but at the same time people who want to find compilations could do so easily. 
> And at the same time, performance would be improved, code would be simplified -
> it would be more maintainable.  Everyone should be happy?


thats why i voted for it!  :)


> > guess tag format isn't "a mistake,"
> Not only my words, but that of a developer a while back.  They mask so many
> issues that users have, eg. when tags aren't recognised within a file, the
> default guess tag rules kick in and can have really bad effects on the users
> music file, followed by lots of posts/bugs.
> > esp if you use wav files or other untaggable formats.
> >
> wav files *do* support some tagging.  There are other solutions, which I have
> used, such as tagging via cue sheets.


very limited tagging and most people with wavs will have NO tags, and its not the only format like that.  guess tag format is in there for a reason, and i see np's with it.  you can void it if you want, it doesn't in ANY WAY put you out...  but it IS useful to others...  sound familiar?

just fyi, i'd be fine if the default for a new SBS install was having it voided, but i'd be against removing it as an optional feature (obviously).


> > thats right, thats the whole point, they would show up for ALL users under
> > whatever the NEW default name would be, like for example "Various Artists." or
> > "-Various Artists-" or whatever, just something that isn't in OBVIOUS CONFLICT
> > with WMP/winamp/AMG/Gracenote, etc...  THATS THE WHOLE POINT!
> > 
> And what about the people who do want albums auto-detected as "Various
> Artists".  Don't you care about them?


ridiculous.  first of all, their shit wouldn't be masked, it would have a SLIGHT change in the default name of the special VA category, which is CLEARLY the lesser of two evils between that, and todays situation.

secondly, THEY COULD EASILY CHANGE IT BACK IF THEY WANTED TO!  its not like they couldn't...  at least they would SEE something was different and it would be obvious; not a hidden obfuscated issue like the one today!  i can't even believe you would attempt to make that argument!

besides which, you're the one saying in bug 15604 you want a "Browse Compilations" menu.


> > you and others like you could then switch it back if you liked!
> If the change did do that, I would know and could easily sort it out.  But
> others who do not frequent bug reports and forums could get a nasty surprise.


you are kidding right?  you must be, right?  you couldn't possibly be serious, could you?

"Various Artists." instead of "Various Artists" is a "NASTY SURPRISE"?????

HAHAHAHHAHA

funny Phil, you had me going there...  (you weren't serious, were you????)

and to compare that horrendous bit of satanic nastiness, to the true functional, practical, actually impactful bug HERE is INSANE.

good one, you almost had me.  (you were kidding, right?)


> > but no, you have to fight it tooth and nail for no good reason!  amazing!
> > 
> Because there's a better solution that fits everyone, and would provide more
> functionality for browsing music.  I'm not really fighting tooth and nail,
> either.  I'm pretty happy with what I've got, and any solution wouldn't
> drastically affect me.  It's true that I'm a perfectionist, but there's always
> a reason.


in this case Phil, no good reason.  honestly.

but yes, i support your bug, in case there was any doubt.


> > "Various Artists" is scared to you apparently, BUT MEANWHILE you have no
> > problem suggesting in bug 15604 to change it to something totally different! 
> > remarkable!
> >
> I don't understand - I haven't suggested in bug 15604 changing Various Artists
> to something completely different.  Did you actually read the suggestion?


i might "sacred" not "scared" above, so my mistake, sorry.  

but yeah, i read it.  to me it sounds like you want a "Browse Compilations" menu.  VA would still exist, but as a function of the tag name or VA auto detect, (thats my interpretation of your rather sparsely worded bug).


> > i don't know if any other app recognizes strings or not
> Not that I'm aware of.


well, i should correct myself...  winamp will do something interesting...  if you sync files to an ipod, it will set a "comp flag" on the ipod for any files that you sync to the ipod that have VA for the AA.  thats essentially the same idea.

i try to stick to SBS, winamp, and mp3tag, and so i don't know much about other apps but i'll research it.  i'm not so sure its totally unheard of.


> > but whether any others do or not isn't the point.
> Why?


b/c SBS needs to handle files brought to it AS IS, commonly expected scenarios.  it is bad design to expect either comp tags, (not universal, see WMP, winamp, etc) or a lack of AA tags, (again, see WMP, winamp, AMG, Gracenote, etc...).  many files will come to SBS, as David told you, with no comp tags but all AA tags.

as a media player that does not create or edit files, SBS should give users the ability to ID those files properly, without the user having to further edit their tags with solutions their apps don't support.

thats a very simple, straightforward concept, and i don't see whats controversial or objectionable about it.


> > the point is users who use AA tags but not comp
> > tags should have a way to ID comps to SBS without using comp tags.
> >
> Why should they?  If they don't want to add a comp tag, and happy with their
> tagging without for other apps, why should they have a way to set a comp
> indicator without having to set a comp tag?


well Gee Phil, maybe b/c they are CUSTOMERS who want a good exp with somethinglogitech wants them to BUY.  you see here, in my country, we understand the idea of trying to improve ourselves for the customer, and we reject the idea of trying to improve the customer.  that way, we'll have more, happier customers, who buy from us.


> Actually they do have a way - remove the album artist tag ;-)


again, funny.  but that would break the exp on the app they created their files with, just in case you didn't know.


> > there's no good reason to fight that.
> Yes there is - there's no good reason to have it.


the reason to have it, is to ID AA tagged comps to SBS without a comp tag.  thats a good reason, regardless of if you agree or not.

the reason not to fight it, is that it wouldn't harm you, just like guess tag format doesn't harm you, if it was implemented.


> > besides, some apps, like winamp, strip comp tags on edits.
> Decent apps don't.  Decent file formats (not id3) are probably treated better.


again, not the point.  i already said i agree winamp shouldn't, but it does.  SBS has to deal with the world as it is, not the world it wants.

thats really the fundamental problem here.  i'm a pragmatic realist, you're a hardline idealist.  not slander, in fact, i think you'd agree.  but as i've said to you many times before, SBS is not in business to martyr itself.  it has to deal with things as they are, not how they wish they were.


> > while i agree they shouldn't, thats also not the point...  SBS has to
> > deal with what users actually bring to it, not what it WANTS users to bring to
> > it.
> >
> If a user has added a comp tag, and it's been stripped out by a faulty app,
> that's hardly SBS's fault or concern.  SBS shouldn't have to work out that
> actually the user wanted it to be a compilation, even though it has an album
> artist, which usually means it is not a compilation.


see above.  winamp, which makes the files SBS uses, and WMP, and other apps like them, don't use comp tags.  don't fixate on what winamp does or doesn't do.  the point is how does SBS handle the REALITY of the marketplace of files brought to it.  i am suggesting a way for it to improve given the reality.


> > like the way SBS assumes anything with an AA tag isn't a comp?  (unless
> > obviously it has a comp tag)  is that what you mean?
> Yes.  That is SBS logic.


so the irony is lost on you then?


> > i haven't checked other views, (besides home>albums)
> I did - they are fine.


again, as per your comment 17 i think you're currently out of default, so i don't trust this finding.


> > not that it matters, as home>artists is a fairly important one.
> > 
> One that in the past (until today, when you decided to pick a fight) you have
> on countless occasions said you don't use, because you only ever use Browse
> Albums, sorted by Album Artist, as you don't want lists without artwork.


i don't NORMALLY use it, (is what i said), but that doesn't matter as to the logic of my argument, and it certainly doesn't stop you from fighting solutions which would not adversely affect you in any way.

before you respond refuting everything i said Phil, really consider if you want to say that "Various Artists." is a worse, "nasty surprise" than the actual bug masking AA VA albums i posted here.  think about it.

It would be interesting to know if this behaviour has changed with onebrowser

No, nothing has changed. The behavior is identical in 7.5 trunk, 7.6 trunk and 7.6 onebrowser. An album tagged with ALBUMARTIST=Various Artists, and no COMPILATION field does not appear under 'Various Artists'.

When such an album is in the library a second 'Various Artists' appears in the browse artists list sorted under 'V', and this artist has the same list of compilation albums as the other.

There are two things happening here:

  1. The determination of whether an album is a compilation. This is done
     during scanning and stored in database in the albums table, 
     compilation column.
  2. The retrieval of albums for the 'Various Artists' artist.

For #1, three things coming into play:

  A. Auto-detection of compilations when tracks in an album have differing
     ARTIST fields.
  B. The presence of an ALBUMARTIST field. Having an ALBUMARTIST field 
     overrides the auto-detection and an album will NOT be considered a
     compilation if it exists.
  C. The presence of a COMPILATION=1 field. Having a COMPILATION=1 field
     overrides both A and B and an album WILL be considered a compilation
     if it exists.

For #2 what is happening is that ONLY compilation albums are retrieved for display under the 'Various Artists' contributor.

To fix it, either:

  - During a scan, if an ALBUMARTIST has the same name as the name set in
    prefs for the special compilation artist, then the album should be
    marked as a compilation.

  or

  - During retrieval of albums for the compilation artist you need to 
    retrieve both compilation albums _and_ albums attributed to an 
    an ALBUMARTIST with the same name as that set in prefs for the 
    special compilation artist.

  or

  - Leave it as it is, but fix the albums retrieved under the second 
    'Various Artists' in the browse artists list. These should be any
    non-compilation albums attributed to that artist.

  The first solution is probably relatively simple, but it does require a 
  rescan if the special name is changed. Another advantage is that there
  won't be a second 'Various Artists' created in the contributors table, 
  so it won't be listed twice when browsing artists.

  The third solution still leaves some confusion, as you have two artists
  in the list with the same name, but with different lists of albums.

thx Jim for that fine work.  however i'm not sure i agree or follow your proposed solutions, please see below:

(In reply to comment #36)
> To fix it, either:
>   - During a scan, if an ALBUMARTIST has the same name as the name set in
>     prefs for the special compilation artist, then the album should be
>     marked as a compilation.


are you talking about the currently existing option in SBS to change the so-called "special category" name for comps?  if so i have problems with this solution.  first, i think this should remain ONLY a "display" option.  meaning, its only there to let the user decide what to call the VA/comps category, and i don't think it should be conflated with any other function.

second, as you say, if the display option is changed, it would then require a rescan.

finally, it would only apply to things that match the currently blankly listed  default of Various Artists, (i think that should show as the entry rather than be blank) or whatever the user specified.  while that would in fact solve this bug of AA string=category name conflict, it doesn't address larger issues that could be better handled with a bigger solution.

i still think bug 15604 is prob the best solution.


>   or
>   - During retrieval of albums for the compilation artist you need to 
>     retrieve both compilation albums _and_ albums attributed to an 
>     an ALBUMARTIST with the same name as that set in prefs for the 
>     special compilation artist.


again, this would work, but i think its not the way to go, b/c what we really want to be able to do, is classify comps to SBS, and then display ONLY those things classified as comps to SBS in that category.  as above, i think it would be better to not have SBS try to figure this out by conflating the option to rename the VA category name.


>   or
>   - Leave it as it is, but fix the albums retrieved under the second 
>     'Various Artists' in the browse artists list. These should be any
>     non-compilation albums attributed to that artist.
>   The first solution is probably relatively simple, but it does require a 
>   rescan if the special name is changed. Another advantage is that there
>   won't be a second 'Various Artists' created in the contributors table, 
>   so it won't be listed twice when browsing artists.
>   The third solution still leaves some confusion, as you have two artists
>   in the list with the same name, but with different lists of albums.


i really don't like the third option at all, its basically saying things aren't comps that probably are, and its having to rule out things that are known to be comps.  whats the point of it?

as i said, bug 15604 is prob the big picture way to go.  but there is a really easy way to fix this immediately: instead of having the default comp category name in SBS be "Various Artists" have it be ANYTHING else that is not likely to conflict with AA/A tags, such as "Various Artists."  PROBLEM SOLVED!  anyone who doesn't like that default name can go into the already existing option in SBS and switch it back to without the period, or to whatever they like.  its really a no-brainer, i don't know why this has languished since 2008.

also, regardless of how this bug is fixed, or if bug 15604 is done or not, it would be good to allow users to specify AA strings that would mean "such and such" is a comp.  i have proposed this at bug 17031

if 17031 were done with a single default entry of "Various Artists" it would solve this bug 9523 and it would keep string recognition as a separate function from category name displaying, along with allowing for multiple strings to be defined.

thx again for your work on this!

(In reply to comment #36)

Good summary Jim.

> To fix it, either:
> 
>   - During a scan, if an ALBUMARTIST has the same name as the name set in
>     prefs for the special compilation artist, then the album should be
>     marked as a compilation.
> 
Don't like that idea much, for various reasons (no pun intended!).  A scan-time solution means having to recalculate/rescan whole library if any of the prefs are changed, or the library will become inconsistent.  This makes it hard/impossible to correct through "scan new/changed files".

>   or
> 
>   - During retrieval of albums for the compilation artist you need to 
>     retrieve both compilation albums _and_ albums attributed to an 
>     an ALBUMARTIST with the same name as that set in prefs for the 
>     special compilation artist.
> 
In some ways better than the first suggested fix, in that a rescan is not required to fix the library if prefs change.  But probably a harder fix as lists have to be aggregated and sorted, and slower performance (at least for browsing compilations - and Various Artists is perhaps an artist that can have a lot of albums associated; some users have lots/majority of their library).

>   or
> 
>   - Leave it as it is, but fix the albums retrieved under the second 
>     'Various Artists' in the browse artists list. These should be any
>     non-compilation albums attributed to that artist.
> 
This is kind of along the lines of my solution in previous posts; simplify Browse Artists to just look for artist names.

Browse Artists should be about browsing artist names; no special logic for compilations.  Compilation albums that didn't have an album artist and thus assigned the default album artist name at scan time would show up under their starting letter (i.e. "V" for Various Artists and not top of the list).

Compilation albums can have any arbitrary album artist name, and the album should be found under that album artist name.  i.e. if COMPILATION=1 and ALBUM ARTIST=Soundtrack, then the album should only appear within Browse Artists > Soundtrack.

If there were a way of browsing compilations, eg "Browse Compilations" that only listed albums with COMPILATION=1, then people could find a list of those albums, irrespective of the ALBUM ARTIST name (i.e. ones that have automatically been assigned "Various Artists" and ones explicitly tagged with "Various Artists" or any other name).

This is a clear separation of concerns, that should suit everyone, and align nicely with other music library programs that effectively do it this way.

> but there is a really easy way to fix this immediately:
> instead of having the default comp category
> name in SBS be "Various Artists" have it be ANYTHING else that is not likely to
> conflict with AA/A tags, such as "Various Artists."  PROBLEM SOLVED!  anyone
> who doesn't like that default name can go into the already existing option in
> SBS and switch it back to without the period, or to whatever they like.  its
> really a no-brainer, i don't know why this has languished since 2008.
> 
Firstly I agree with you that it would make more sense to set the default compilation album artist prefs value to "Various Artists" explicitly, rather than allow blank.

However, I don't think it's a no-brainer to set this by default to "anything else".  That would look like a hack to first-time users; any users who explore the prefs may think "no, I don't want compilation albums to be called (whatever), I want them known as Various Artists".  It's building in a kind of side-effect action for the pref, making use of undocumented behaviour.

If the default were changed to something else, how/when would this be set?  For people installing SBS for the first time?  If people re-install, they would see a different effect in their library - maybe good for some, but possibly bad for most established users as many will be depending on automatic assignment of Various Artists.

The default was "Various Artists" for a reason - it's what people expect to see their compilation albums appearing as.

(In reply to comment #39)
> > but there is a really easy way to fix this immediately:
> > instead of having the default comp category
> > name in SBS be "Various Artists" have it be ANYTHING else that is not likely to
> > conflict with AA/A tags, such as "Various Artists."  PROBLEM SOLVED!  anyone
> > who doesn't like that default name can go into the already existing option in
> > SBS and switch it back to without the period, or to whatever they like.  its
> > really a no-brainer, i don't know why this has languished since 2008.
> > 
> Firstly I agree with you that it would make more sense to set the default
> compilation album artist prefs value to "Various Artists" explicitly, rather
> than allow blank.


i'm glad we can agree on something!  :)


> However, I don't think it's a no-brainer to set this by default to "anything
> else".  That would look like a hack to first-time users; any users who explore
> the prefs may think "no, I don't want compilation albums to be called
> (whatever), I want them known as Various Artists".


yes, its true that a user * might * seek out the option and unintentionally reinstate the conflict.  but first of all, it would be better if they did that, and have the bug occur as a result of their deliberate actions, rather than occur by default "out of the box" as it does now.  the current situation is an instant fail, no chance of success when the criteria i laid out are met.

secondly, the sbs VA display option could explain in its tool tip that you do NOT want the string in the option to equal a string in the tags, (unless of course explicit comp tags are also present).  easy enough to explain that where the option is.

thirdly, as i explained, it would be ok even if there was conflict, AS LONG AS comp string recognition was also implemented, as per bug 17031  ...in other words, the bug would become very difficult to unintentionally reimplement.

btw, i'm glad we agree that that display option in SBS should not be conflated with any other function or meaning.


>  It's building in a kind of
> side-effect action for the pref, making use of undocumented behaviour.
> If the default were changed to something else, how/when would this be set?  For
> people installing SBS for the first time?  If people re-install, they would see
> a different effect in their library - maybe good for some, but possibly bad for
> most established users as many will be depending on automatic assignment of
> Various Artists.


bug 8001 eventually changed the default of how TPE2 was treated by default on new installs.  i don't know what happens on existing installs, but i'd say it doesn't matter to me.  if logitech wants to respect the current setting, fine by me.  but on new installs, yes, it absolutely should be something else, and i don't see that as problematic.  if it wasn't blank, as we agree it shouldn't be, it would be obvious why some people had "Various Artists" while others had "Various Artists." or even "VA/Comps" or whatever logitech wanted a new install to say.

SBS needs to do SOMETHING to fix this problem.


> The default was "Various Artists" for a reason - it's what people expect to see
> their compilation albums appearing as.


obviously, but also just as obviously its currently problematic for a not insignificant amount of users.  the whole point of this bug is addressing the problem, which exists by default, and not trying to explain it away as something that should be ignored.

and i don't understand why "Various Artists." is such an abomination anyway?  u insist it has to be "Various Artists" but in bug 15604 you want it called "Browse Compilations"

> yes, its true that a user * might * seek out the option and unintentionally
> reinstate the conflict.  but first of all, it would be better if they did that,
> and have the bug occur as a result of their deliberate actions
>
Changing the value could be seen as moving the problem elsewhere; it might fix something for some users, and have a detrimental effect for others.

> bug 8001 eventually changed the default of how TPE2 was treated by default on
> new installs.  i don't know what happens on existing installs, but i'd say it
> doesn't matter to me.  if logitech wants to respect the current setting, fine
> by me.  but on new installs, yes
>
I'm not sure if the software can tell.  eg. if a user is upgrading, and uninstall previous and then install a newer (or the same) version, do the prefs remain, unchanged?

> and i don't understand why "Various Artists." is such an abomination anyway?  u
> insist it has to be "Various Artists" but in bug 15604 you want it called
> "Browse Compilations"
>
No, I think album artist should be defaulted to "Various Artists" for compilations without an album artist name.
In addition, I think there should be a Browse Compilations menu to view all compilations.
There isn't a relationship between those statements.

Compilation status should be separate, not tied to an Album Artist name, or anything else.  e.g. Suggesting that GENRE=<some string> (such as Soundtrack) could also mean that an album is a compilation, would be as wrong as ALBUM ARTIST=<some string> (such as Various Artists) representing a compilation.

A Soundtrack genre doesn't imply that all Soundtrack albums are compilations, nor are all compilations soundtracks.  Not all Various Artists albums may be compilations, and not all compilations may be by Various Artists.

(In reply to comment #41)
> > yes, its true that a user * might * seek out the option and unintentionally
> > reinstate the conflict.  but first of all, it would be better if they did that,
> > and have the bug occur as a result of their deliberate actions
> >
> Changing the value could be seen as moving the problem elsewhere; it might fix
> something for some users, and have a detrimental effect for others.


thats rather existential Phil, and frankly meaningless.  you can make that statement, but unless you can back it up showing a reasonable example case of HOW it has a "detrimental effect" on others, it doesn't have much sway.

i have demonstrated a current, actual, detrimental effect.  it isn't "in theory," its real.  i have suggested, since 2008, a quick fix that would work.  you are suggesting (in the quote above) boogeymen vis a vis that fix.

there is no good reason not to de-boobytrap SBS.


> > bug 8001 eventually changed the default of how TPE2 was treated by default on
> > new installs.  i don't know what happens on existing installs, but i'd say it
> > doesn't matter to me.  if logitech wants to respect the current setting, fine
> > by me.  but on new installs, yes
> >
> I'm not sure if the software can tell.  eg. if a user is upgrading, and
> uninstall previous and then install a newer (or the same) version, do the prefs
> remain, unchanged?


do you lose all your pref settings when you upgrade to a newer SBS?  i don't.  i think most people upgrade over top an existing install, or even if they uninstall first i think the prefs remain, unless deliberately deleted.  i don't think any of this matters.  if they can change the default for 8001 they can change it for this.


> > and i don't understand why "Various Artists." is such an abomination anyway?  u
> > insist it has to be "Various Artists" but in bug 15604 you want it called
> > "Browse Compilations"
> >
> No, I think album artist should be defaulted to "Various Artists" for
> compilations without an album artist name.
> In addition, I think there should be a Browse Compilations menu to view all
> compilations.
> There isn't a relationship between those statements.


i agree, and i want that too.  but "Browse Compilations" could be what the new SBS VA-category-name-option-default is called, instead of "Various Artists" which sounds similar to bug 15604


> Compilation status should be separate, not tied to an Album Artist name, or
> anything else.  e.g. Suggesting that GENRE=<some string> (such as Soundtrack)
> could also mean that an album is a compilation, would be as wrong as ALBUM
> ARTIST=<some string> (such as Various Artists) representing a compilation.
> A Soundtrack genre doesn't imply that all Soundtrack albums are compilations,
> nor are all compilations soundtracks.  Not all Various Artists albums may be
> compilations, and not all compilations may be by Various Artists.


Compilation status logic should be separate from the existing SBS VA category name option, we agree on that.  but if a user wants to define AA/A strings to SBS that SBS would then use to classify something as a comp, its no skin off your nose.  if you don't like it, just void any entries for it, and its defeated.

i never said anything about using genre strings btw.  and fixing this bug does not require bug 17031 be implemented, or bug 15604 altho i support both.  it only requires changing the special VA category name to a new default unlikely to be in conflict with a users tags.

and as to yor final point, its basically absurd to say something with "Various Artists" in the AA tag isn't a comp.  99% of users will want something with an AA tag of "Various Artists" identified as a comp, your "rare case" aside.  if it didn't suit you, you could void the string, or add comp=0 tags.

again, the point is to fix the issue for the vast majority of affected users out of the box, while at the same time giving power users the ability to work around ANY fixes or implementation.  what i suggest does that.

since there seems to be agreement on not having a blank box for the VA comp category option, i filed this bug:

bug 17081

please vote for it!  :)

> thats rather existential Phil, and frankly meaningless.
The effects of changing the pref with no name that is currently blank that represents "Various Artists" are well known.  I was trying to keep my post short, rather that repeat what has been said elsewhere.

It will mess up people that get Various Artists assigned automatically at the moment.

> do you lose all your pref settings when you upgrade to a newer SBS?  i don't.
I don't upgrade through running an installer, as I fetch and run the source code from SVN.  I have little idea what happens through normal uninstall/install cycles any more.

> i agree, and i want that too.  but "Browse Compilations" could be what the new
> SBS VA-category-name-option-default is called, instead of "Various Artists"
> which sounds similar to bug 15604
> 
Which would mean that for users who get assigned an Album Artist when it is detected as a compilation, the name of the album artist would be "Browse Compilations", which wouldn't look too good, would it!

> and as to yor final point, its basically absurd to say something with "Various
> Artists" in the AA tag isn't a comp.
I disagree - it's not absurd.  I came up with a real-life example where I had such a case.  Lots of artists contributing to every track, the same list of artists for each track, so it's not a compilation, but instead of listing all the names, "Various Artists" is used instead.  i.e. each song is by Various Artists, but this represents the same various artists on each song, not that each song has a different artist.

That's not absurd; but I agree that it may not be too common.

(In reply to comment #44)
> > thats rather existential Phil, and frankly meaningless.
> The effects of changing the pref with no name that is currently blank that
> represents "Various Artists" are well known.  I was trying to keep my post
> short, rather that repeat what has been said elsewhere.
> It will mess up people that get Various Artists assigned automatically at the
> moment.


i have yet to hear whats detrimental about that?  frankly, i don't think anyone's world ends, or is irreparably harmed if they get "Various Artists." assigned instead of "Various Artists" (especially since they could easily change it back if they wished); and if thats the price that needs to be paid to fix this issue that is very tangibly and demonstrably detrimental in a practical way for affected users, so be it!

i do find what you are saying interesting in another sense altogether though.  i was under the belief that the VA naming option ( bug 17081 ) did no more than that; that it simply allowed users to rename the special SBS VA category name, which i thought was a category populated only by those things SBS had classified as a comp, (by either comp tag or VA logic).

are you suggesting that that naming option actually assigns in the DB what the SBS imposed AA term should be for things SBS auto-detects as VA?  i'm not at all suggesting you are incorrect, i just want to be sure thats what you mean to say and i also want to know if you know that to be true, or are just assuming its true?

it would seem very odd and disjointed/unintuitive/unnecessary to me for the category name option to impact how the VA auto-detection fills in the SBS AA field for things it detects as comps.  to me, the VA auto-detection should always use "Various Artists" for the SBS AA field as well as setting a comp flag, and the SBS VA naming option should have nothing to do with that, it should only apply to naming the displayed name of the VA category.

but either way, it doesn't change my argument.

btw, if AA tags are blank, does SBS fill in the SBS/DB AA field for comps, or does it just assign a SBS/DB comp=1 value?


> > i agree, and i want that too.  but "Browse Compilations" could be what the new
> > SBS VA-category-name-option-default is called, instead of "Various Artists"
> > which sounds similar to bug 15604
> > 
> Which would mean that for users who get assigned an Album Artist when it is
> detected as a compilation, the name of the album artist would be "Browse
> Compilations", which wouldn't look too good, would it!


if thats what the user wanted, whats the beef?  it would work and make sense.

again, you might have just told me something i didn't know if what you're saying is true, but it really doesn't change my argument.  SBS has a default that is in conflict with how many apps tag.  as long as the default doesn't conflict with common tag strings, thats all that really matters.


> > and as to yor final point, its basically absurd to say something with "Various
> > Artists" in the AA tag isn't a comp.
> I disagree - it's not absurd.  I came up with a real-life example where I had
> such a case.  Lots of artists contributing to every track, the same list of
> artists for each track, so it's not a compilation, but instead of listing all
> the names, "Various Artists" is used instead.  i.e. each song is by Various
> Artists, but this represents the same various artists on each song, not that
> each song has a different artist.
> That's not absurd; but I agree that it may not be too common.


it would be basically nobody, b/c no tagging source i know of tags those albums that way, and its not even a de facto standard among users.  i mean why would you tag it with AA=Various Artists since all the tracks have the same listing?  why not just have AA=A?  or, if it were me, i'd make AA=Pink Floyd tribute.  i mean, to say its not common is putting it mildly.  and it wouldn't affect you anyway, b/c if bug 17031 wereimplemented, you would have no entries for it, so SBS wouldn't call it a comp even tho it had the SBS default comp name.

> i have yet to hear whats detrimental about that?
Well, for someone that has their library working exactly as they like it, to upgrade and find it's then slightly not what they expect, it is detrimental.  It may not be a show stopper, but unexpected.  Changing the name would mean a full rescan, which is also not a wonderful thing to do.

To then discover that SBS has changed a setting from a good reasonable default, to something not quite as good, and having to change it back and another full rescan to fix, is detrimental user experience.

> are you suggesting that that naming option actually assigns in the DB what the
> SBS imposed AA term should be for things SBS auto-detects as VA?  i'm not at
> all suggesting you are incorrect, i just want to be sure thats what you mean to
> say and i also want to know if you know that to be true, or are just assuming
> its true?
> 
Yes, that's what happens.  When the scanner finds mismatches in artist names on an album, and there no album artist tag, it stores Album Artist=Various Artists (or whatever the pref setting is), and Compilation=1.

Changing the Various Artists name setting therefore means a full rescan.

> if thats what the user wanted, whats the beef?  it would work and make sense.
> 
So you think that when playing an album, the Now Playing screen should be displayed as "Hits of the 80's by Browse Compilations"? That doesn't make sense to me.

> it would be basically nobody, b/c no tagging source i know of tags those albums
> that way, and its not even a de facto standard among users.
>
There are some albums in FreeDB that return Artist=Various Artists.
I wouldn't tag an Album Artist for these songs, but some users may set Album Artist to the same as the artist (unnecessarily), so in this case Album Artist would also be Various Artists.

> i mean why would you tag it with AA=Various Artists since all the
> tracks have the same listing? 
You tell me - that's what you say most people do.  i.e. every album would have an album artist tag.

(In reply to comment #46)
> > i have yet to hear whats detrimental about that?
> Well, for someone that has their library working exactly as they like it, to
> upgrade and find it's then slightly not what they expect, it is detrimental.


as i said, an existing user shouldn't see it changed b/c prefs persist, but even if hypothetically they did see it change, it would be the lesser of two evils anyway.  what happens as described here in bug 9523 is far worse than what you are describing as "bad."  and again, its moot anyway b/c the pref would persist for current installs.

 
> It may not be a show stopper, but unexpected.  Changing the name would mean a
> full rescan, which is also not a wonderful thing to do.
> To then discover that SBS has changed a setting from a good reasonable default,
> to something not quite as good, and having to change it back and another full
> rescan to fix, is detrimental user experience.


none of that would be necessary.  but if it were, it would be a one time thing worth doing to fix the issue.  i also want to reiterate that it is crazy to me that the VA naming option is conflated with the DB field entries.  that option should not trigger rescans or impact DB entries!  crazy.


> > are you suggesting that that naming option actually assigns in the DB what the
> > SBS imposed AA term should be for things SBS auto-detects as VA?  i'm not at
> > all suggesting you are incorrect, i just want to be sure thats what you mean to
> > say and i also want to know if you know that to be true, or are just assuming
> > its true?
> > 
> Yes, that's what happens.  When the scanner finds mismatches in artist names on
> an album, and there no album artist tag, it stores Album Artist=Various Artists
> (or whatever the pref setting is), and Compilation=1.
> Changing the Various Artists name setting therefore means a full rescan.


thats good to know, but thats really stupid [of SBS].  the naming/display option is to name the category.  it should not impact at all, in any way, what SBS scans in for the AA term for comps.  this should be changed if only to allow users to change the name without requiring rescans!

the VA category name and the internal AA DB field are two different things that should have nothing to do with one another.  the VA autodection logic should just always use "Various Artists" if it detects a comp.


> > if thats what the user wanted, whats the beef?  it would work and make sense.
> > 
> So you think that when playing an album, the Now Playing screen should be
> displayed as "Hits of the 80's by Browse Compilations"? That doesn't make sense
> to me.


i thought NP always used the (track) Artist info?  in fact isn't there a bug right now where someone is complaining that they can't get AA info on the NP screen?

besides, imo there should not be this conflation between the SBS VA category naming option and what is entered in the DB for AA.  i really can't get over it.

even if you [plural] think i'm all wet regarding what i'm saying here, surely you don't want to have to rescan everytime you change that option?  why conflate it???


> > it would be basically nobody, b/c no tagging source i know of tags those albums
> > that way, and its not even a de facto standard among users.
> >
> There are some albums in FreeDB that return Artist=Various Artists.


yes, and all those albums would be screwed as per this bug, since EAC for example doesn't assign a comp or AA tag.  if A=VA then sbs AA will =VA and the tracks would be hidden!


> I wouldn't tag an Album Artist for these songs, but some users may set Album
> Artist to the same as the artist (unnecessarily), so in this case Album Artist
> would also be Various Artists.


and again, as per this bug, hidden!


> > i mean why would you tag it with AA=Various Artists since all the
> > tracks have the same listing? 
> You tell me - that's what you say most people do.  i.e. every album would have
> an album artist tag.


no, thats what most APPS do.  most assign an AA tag, comp or not, usually at rip-time, but also via auto-tagging.  and most comps are assigned a AA=VA tag.

now, you were saying you had a "rare case" cd[s] where you had the same multiple artists on every track, so you'd assign AA=VA, but now you're saying even you don't do that!

> as i said, an existing user shouldn't see it changed b/c prefs persist, but
> even if hypothetically they did see it change, it would be the lesser of two
> evils anyway.
>
So you think that only new users should see the fix, and all users who experience the problem would not get the fix?

> none of that would be necessary.  but if it were, it would be a one time thing
> worth doing to fix the issue.
>
Only if the user has tags in such a way as to actually experience the issue, and hasn't already worked around it.

> i also want to reiterate that it is crazy to me
> that the VA naming option is conflated with the DB field entries.  that option
> should not trigger rescans or impact DB entries!  crazy.
> 
It's not crazy.  Creating the DB entry for Various Artists means consistency throughout the app, so for example the albums will appear in search results, will appear in third-party apps (eg. iPeng) without needing to code special logic.

> thats good to know, but thats really stupid [of SBS].  the naming/display
> option is to name the category.  it should not impact at all, in any way, what
> SBS scans in for the AA term for comps.  this should be changed if only to
> allow users to change the name without requiring rescans!
> 
No, I disagree.  What it is currently doing is sensible.

> the VA category name and the internal AA DB field are two different things that
> should have nothing to do with one another.  the VA autodection logic should
> just always use "Various Artists" if it detects a comp.
> 
No, I think the opposite.  The name given for an Album Artist if autodetecting a compilation album can be configurable (i.e. allow for different languages), but potentially the way that compilation albums are browsed could be fixed.  At the moment it is the same name; Browse Artists > {Compilations album artist name} contains albums that will have Album Artist = {Compilations album artist name}.

I am suggesting a Browse Compilations > {list of albums that are compilations}.

The way the scanner works to assign the pref name to the album artist name to auto-detected compilations is not a problem.

> i thought NP always used the (track) Artist info?  in fact isn't there a bug
> right now where someone is complaining that they can't get AA info on the NP
> screen?
> 
Depends on the player type.  Unless it's recently changed, Touch NP shows Album Artist name FIRST, followed by track artists.  Touch NP is not configurable through format strings like the older players.

> even if you [plural] think i'm all wet regarding what i'm saying here, surely
> you don't want to have to rescan everytime you change that option?  why
> conflate it???
>
I never change the option; and I'm sure not many people have ever changed it either.  But there are a few options that affect the scanner, and thus require a rescan if changed.  In my opinion, they should all be put in a separate "Scanner Prefs" page, so it is clear that they are scan-time preferences.

> no, thats what most APPS do.
Same difference.

> now, you were saying you had a "rare case" cd[s] where you had the same
> multiple artists on every track, so you'd assign AA=VA, but now you're saying
> even you don't do that!
Correct.
I assign ARTIST=Various Artists, and Compilation=1.  No Album Artist.

(In reply to comment #48)
> > as i said, an existing user shouldn't see it changed b/c prefs persist, but
> > even if hypothetically they did see it change, it would be the lesser of two
> > evils anyway.
> So you think that only new users should see the fix, and all users who
> experience the problem would not get the fix?


i'd actually leave that decision up to logitech.  changing the setting to only new installs is how bug 8001 was eventually done, but as you suggest this is a slightly different situation since this is a bug rather than an option.  i'd be fine with whichever way logitech thought best.  if they did only apply it to new installs, at least it wouljd be fixed for those users.


> > none of that would be necessary.  but if it were, it would be a one time thing
> > worth doing to fix the issue.
> Only if the user has tags in such a way as to actually experience the issue,
> and hasn't already worked around it.


right, which is all default WMP users, all default winamp users, etc...


> > i also want to reiterate that it is crazy to me
> > that the VA naming option is conflated with the DB field entries.  that option
> > should not trigger rescans or impact DB entries!  crazy.
> It's not crazy.  Creating the DB entry for Various Artists means consistency
> throughout the app, so for example the albums will appear in search results,
> will appear in third-party apps (eg. iPeng) without needing to code special
> logic.


i actually don't mind that SBS DB values for AA are created, thats fine.  i just don't think that option should be conflated with that task.  

to me it calls for two distinct options that don't impact each other.  one option would be for what string the VA auto-detection should use for SBS DB AA, (and that would necessitate rescans but accommodate differing languages), while the other option would strictly be for what to call/denote/display as the comp category in SBS, (and a user could change that without triggering a rescan).

a user would not necessarily want the two things to be one and the same.


> > thats good to know, but thats really stupid [of SBS].  the naming/display
> > option is to name the category.  it should not impact at all, in any way, what
> > SBS scans in for the AA term for comps.  this should be changed if only to
> > allow users to change the name without requiring rescans!
> No, I disagree.  What it is currently doing is sensible.


its not sensible if you want the two things to be different as i just laid out.  its also not sensible if you have AA tags without comp tags that equal the options value.  thats the heart of the conflict this bug represents.

consider your bug 15604   ...lets say they implemented it.  what if a user wanted to change your Default name of "Browse Compilations" to "Comps"?  how would they do it?  to me, thats what the current VA naming option is for.  it shouldn't conflate with the SBS DB string used for AA/VAs.


> > the VA category name and the internal AA DB field are two different things that
> > should have nothing to do with one another.  the VA autodection logic should
> > just always use "Various Artists" if it detects a comp.
> No, I think the opposite.  The name given for an Album Artist if autodetecting
> a compilation album can be configurable (i.e. allow for different languages),
> but potentially the way that compilation albums are browsed could be fixed.  At
> the moment it is the same name; Browse Artists > {Compilations album artist
> name} contains albums that will have Album Artist = {Compilations album artist
> name}.
> I am suggesting a Browse Compilations > {list of albums that are compilations}.
> The way the scanner works to assign the pref name to the album artist name to
> auto-detected compilations is not a problem.


i understand what you are saying, and i support bug 15604, but i already explained directly above why i feel differently about the conflation, so i won't rehash it.

what i will point out though, if that if you do think they should be conflated, then it seems to me that its inconsistent of you to think/say that SBS should not assign a comp=1 value to anything it finds with an AA value equal to the entry (or default) of that conflated option.  i know i know, you'll say it isn't inconsistent, but if the string SBS would autofillin MATCHES what it finds in the tag for that option, then i don't see how you can say it shouldn't recognize that at least.


> > i thought NP always used the (track) Artist info?  in fact isn't there a bug
> > right now where someone is complaining that they can't get AA info on the NP
> > screen?
> > 
> Depends on the player type.  Unless it's recently changed, Touch NP shows Album
> Artist name FIRST, followed by track artists.  Touch NP is not configurable
> through format strings like the older players.


right, but thats a bug i've seen filed, (people don't like that), and i've seen other bugs where on other UIs people can't get AA to show at all.  i'll look for them if you like?


> > even if you [plural] think i'm all wet regarding what i'm saying here, surely
> > you don't want to have to rescan everytime you change that option?  why
> > conflate it???
> I never change the option; and I'm sure not many people have ever changed it
> either.  But there are a few options that affect the scanner, and thus require
> a rescan if changed.  In my opinion, they should all be put in a separate
> "Scanner Prefs" page, so it is clear that they are scan-time preferences.


yes, i def agree that there should be clear delineation between pre-scanner, and post-scanner options, ie. those that require rescans and those that don't.

but i am also further saying that i don't think that option should necessitate rescans, and it wouldn't if it weren't conflated.


> > no, thats what most APPS do.
> Same difference.


well no, it isn't.  the difference i am trying to highlight is the difference between a deliberate action of the user, and the default actions of an app.  that is important.  what we are talking about is making the default files made by a given app work out of the box on slim, and thats an important goal to achieve, as opposed to the vagaries of what a user might or might not do.


> > now, you were saying you had a "rare case" cd[s] where you had the same
> > multiple artists on every track, so you'd assign AA=VA, but now you're saying
> > even you don't do that!
> Correct.
> I assign ARTIST=Various Artists, and Compilation=1.  No Album Artist.


yes, but freedb and EAC don't set the comp=1 tag, therefore those files in the default state of the app would be hidden as per this bug.  (its only b/c u do extra "user stuff" those files don't end up affected.

i know in our endless back and forth here we've gotten knee deep in the weeds about all this, and i know you've suggested bug 15604 as a fix and i support that, but all i am trying to say is that until the devs show a willingness to do that, they should do something right now about the current AA TAG=SBS option name conflict that causes this bug.  i think what i have suggested should have been done in 2008, and if it had been, it would be a moot issue by now.

What is the status of this with onebrowser (latest 7.6 builds)?

according to Jim, no difference whatsoever.  this bug really seems to have nothing to do with onebrowser.

just FYI, the reason it exists is because of a conflict in the logic.  your sbs "special category" default name for comps is "Various Artists" which is also what winamp, WMP, etc use as the ALBUMARTIST tag in files, but those files do NOT have a comp tag, and so do not qualify as comps to SBS; (by virtue of simply having any AA tags, regardless of what value is in the string)

so until that conflict is fixed, the bug will continue, and that means regardless of what happens in onebrowser.

i am more than happy to suggest various fixes, including:

bug 15604 
bug 17031 
bug 17081

or as i suggest here in this bug, simply adding a period or ANYTHING to the sbs "special category" default name of "Various Artists" which is an out of the box built-in conflict for users of apps like winamp and WMP.

btw, bug 6658 is basically this bug, just filed earlier obviously.  someone erroneously closed that bug as fixed however, it should be reopened.

> just FYI, the reason it exists is because of a conflict in the logic.  your sbs
> "special category" default name for comps is "Various Artists" which is also
> what winamp, WMP, etc use as the ALBUMARTIST tag in files, but those files do
> NOT have a comp tag, and so do not qualify as comps to SBS; (by virtue of
> simply having any AA tags, regardless of what value is in the string)
> 
Just to be clear, it is not due to a conflict in the scanner logic; it's due to a conflict in what it is trying to display.  Browse Artists attempts to display the distinct union of artists and also a special artist representing compilation albums in one list.

An album can quite happily exist with an Album Artist=Various Artists and not be a compilation.  But when browsing Artists > [first artist in list representing compilations called "Various Artists"], it will only list compilation albums (irrespective of the album artist name that each compilation has).

> or as i suggest here in this bug, simply adding a period or ANYTHING to the sbs
> "special category" default name of "Various Artists" which is an out of the box
> built-in conflict for users of apps like winamp and WMP.
>
Which will not only affect the Browse Artists > "Various Artists" name, but also the album artist name assigned to albums by the scanner.

(In reply to comment #53)
> Just to be clear, it is not due to a conflict in the scanner logic; it's due to
> a conflict in what it is trying to display.  Browse Artists attempts to display
> the distinct union of artists and also a special artist representing
> compilation albums in one list.
> 
> An album can quite happily exist with an Album Artist=Various Artists and not
> be a compilation.  But when browsing Artists > [first artist in list
> representing compilations called "Various Artists"], it will only list
> compilation albums (irrespective of the album artist name that each compilation
> has).


i agree, but i'm not sure you made it anymore "clear."  yes, strictly speaking its not the scanner logic itself, its a display conflict.  but it happens b/c actual CD comps in the real world are not classified as comps by SBS.  why?  b/c they have AA tags (which happen to = Various Artists) with no Comp tags.

its a major flaw in both the design and execution of the program that affects winamp, WMP, and other users.  a pretty big flaw that is the culmination of not considering and properly handling likely user scenarios.  


> > or as i suggest here in this bug, simply adding a period or ANYTHING to the sbs
> > "special category" default name of "Various Artists" which is an out of the box
> > built-in conflict for users of apps like winamp and WMP.
> >
> Which will not only affect the Browse Artists > "Various Artists" name, but
> also the album artist name assigned to albums by the scanner.


indeed, and that will fix the bug and resolve the conflict!  thats the whole point!  and anyone who then doesn't like that, already has an option in SBS to change it back, if they so desire.

Created attachment 7329 [details]
Patch for setting compilation flag

The attached va.patch file will set the compilation flag in albums table to 1 if albumartist="Various Artists" (the name configured in SBS settings).
It will not change anything if COMPILATION=0 exists as a tag.

I've tested it in my own library which contains one album tagged with Musicbrainz Picard which contains this problem because I haven't manually added a COMPILATION=1 tag.

I've not tested that it works with MusicIP and iTunes scanner but I suspect it will since they both use the Slim::Schema code to create their scanned data in the database. I've only tested it on Linux but since there isn't any OS specific code I think it should also work on Windows and OSX.

My feeling is that since many tagging softwares, including Musicbrainz Picard, will add ALBUMARTIST="Various Artists" as a tag but not add the SBS specific COMPILATION=1 tag, this patch will be a good addition to the SBS automatic compilation detection logic. IMHO, there is no reason the user should be forced to manually add a COMPILATION=1 tag for these albums to make them browsable through Artists menu.

It would be possible to correct this also in the browsing code but my feeling is that it's better to keep the browsing code simple and add some extra logic to the scanner.

Erland,

great stuff.  but does the patch only apply it to that string, OR to any string in the comp naming option in sbs settings?

thats important, b/c if a user changes the option to say "Soundtracks" and they have AA = Soundtracks in their tags, they are again victimized by the bug.

and i def appreciate this patch, don't get me wrong, but i also think after 7.6 is official, it would be better and simpler to fix the browsing code.  there is no need to check comp status for making home>whatever lists, (except home>comps as prposed in bug 15604 )

> The attached va.patch file will set the compilation flag in albums table to 1
> if albumartist="Various Artists" (the name configured in SBS settings).
> It will not change anything if COMPILATION=0 exists as a tag.
>
Is this for any SBS release, or 7.6 only?

At best, I think this is a temporary workaround - it may only work for some, and can have side effects for others.  If it is to be included officially, it should at least be possible to enable/disable.

Some people add album artist tags to avoid albums being classed as compilations.  This muddies the water.

The standard logic is:
1. Set Compilation=1 if there are differing artists on an album,
2. but not if there is already an album artist tag,

This adds an additional rule:
3. except if the album artist matches the name of the label used for representing a compilation, in which case ignore rule 2.

Usually, when there is a compilation tag without an album artist, the songs on the album will have Artist contributor roles (role=1).  When there is an album artist tag present, the songs on the album will have track artist contributor roles (role=6).  With this patch, when auto-setting the compilation tag, will we see songs with artist role, or track artist role?

> My feeling is that since many tagging softwares, including Musicbrainz Picard,
> will add ALBUMARTIST="Various Artists" as a tag but not add the SBS specific
> COMPILATION=1 tag, this patch will be a good addition to the SBS automatic
> compilation detection logic.
>
Some software will sometimes add ALBUMARTIST=Various Artists, but at the mercy of the quality of metadata.  Therefore this will help to make some albums that the user hasn't requested to be treated as compilations appear in the place where compilations are listed, but not all albums that may be considered to be compilations.

Worse (for me at least), is that there are some cases where I have used Artist=Various Artist consistently for each artist on songs on an album, and do not consider the album to be a compilation.  I have a few now like this - albums where the artists are unknown or have a lot of performing artists list; and not credited with a band name.

An example being a live concert with many artists listed as performers on all songs.  Rather than add a long list of artist contributors to each song (the names of which I don't care about - they are not well recognised popular artists), the songs are tagged with "Various Artists" - i.e. there are a collection of artists that play on the songs.  But the album is NOT a compilation.  Setting COMPILATION=0 does not have the same effect as having no compilation tag.

> It would be possible to correct this also in the browsing code but my feeling
> is that it's better to keep the browsing code simple and add some extra logic
> to the scanner.
>
I think that would be better - the browsing code is over-complicated with additional logic to handle the compilations case, and very inefficient.  Implementing a better solution to the browser code could simplify and also improve performance.

(In reply to comment #56)
> 
> great stuff.  but does the patch only apply it to that string, OR to any string
> in the comp naming option in sbs settings?
> 


The patch will look at the value in SBS settings.


(In reply to comment #57)
> > The attached va.patch file will set the compilation flag in albums table to 1
> > if albumartist="Various Artists" (the name configured in SBS settings).
> > It will not change anything if COMPILATION=0 exists as a tag.
> >
> Is this for any SBS release, or 7.6 only?


The patch has only been tested on 7.6, I don't think it will work in 7.5 and I didn't think it was worth making one for 7.5 as 7.6 probably will be released sometime in the near future and I suspect Logitech don't want changes like this in a 7.5.5 bug fix release.


(In reply to comment #57)
> 
> At best, I think this is a temporary workaround - it may only work for some,
> and can have side effects for others.  If it is to be included officially, it
> should at least be possible to enable/disable.
> 


If we think it might cause problem for a  lot of people, I agree, then we should probably not apply this patch. Personally I still think does more good than bad. People that don't like it can always add a COMPILATION=0 on the albums where they've used ALBUMARTIST="Various Artists", the patch will only set compilation flag on albums which don't have an explicit COMPILATION tag.

But in general I agree, it's a temporary workaround until someone dares to solve the much bigger compilation/Various Artists problem.

people who have things that AREN'T comps, but still that have a value matching the SBS option string are STILL victimized by the bug, so i don't see Phil's niche case as a compelling reason to not apply the patch.

http://forums.slimdevices.com/showthread.php?p=639009#post639009

I can't test the patch myself, as 7.6 doesn't work (scanner frequently randomly crashing).

> People that don't like it can always add a COMPILATION=0 on the
> albums where they've used ALBUMARTIST="Various Artists", the patch will only
> set compilation flag on albums which don't have an explicit COMPILATION tag.
> 
Have you actually tested this?  I don't think I've ever tried a combination of COMPILATION=0 + an ALBUM ARTIST tag.

COMPILATION=0 has some iffy effects - I believe is different to COMPILATION=NULL.

e.g. an album artist tag tells SBS to join varying track artists into one album, compilation=0 will be telling it to split albums into several, one per performing track artist.

Effects of whether songs become track artists or normal artists won't change as you are modifying albums as a tidy-up phase after scanning tags into the schema.

But it might subtly change browse/navigation actions if a compilation usually has artists but instead has track artists (or vice-versa).

Also, changing the pref value should now cause a full rescan.  Changing the pref and partial scanning won't undo any auto-detecting logic.  This will go against progress in 7.6/onebrowser to remove the need for full rescans and supporting auto-rescan.

Comment on attachment 7329 [details]
Patch for setting compilation flag

Marking patch as obsolete since it's not the right way to solve this. 

In 7.6 there is two "Various Artists" entries and the one under "V" already lists the problematic albums, at least in my setup, so this requires further investigation before it can be committed.

Here is an additional wrinkle: Search Music doesn't bring up albums with ARTIST=Various Artists
ALBUM_ARTIST=Various Artists
that have no COMP or COMPILATION tag set.

That means if I rip an album with CDex and use Various Artists as the artist name, it won't show up under Browse Artists or under Search Music when I look for Various Artists.  I have to take an additional step of explicitly adding the COMPILATION tag in order for them to come up properly.

That is broken.

It's great that Logitech Media Server is smart enough to recognize albums with mixed ARTIST tracks, and flagged as COMPILATION, and set their ALBUM_ARTIST to "Various Artists".

But it should not ignore or un-set the ALBUM_ARTIST tag for tracks with ALBUM_ARTIST="Various Artists" just because they don't also meet the criteria in the preceding paragraph.

Why would you do that?  All I'm seeing is some vague sense that anyone who uses software that doesn't add the COMPILATION tag, is "doing it wrong" and deserves to have their library treated like the garbage it is.  That's a religious position, not a pragmatic one.

right on John, I couldn't have said it better myself!  you are 100% correct!