Created attachment 3402 [details]
Patch for new auto detect option

Steven, Dean: what do you guys think about this pref?

Oh no, not another option! ;)

Seriously, I have never been a big fan auto detection logic of any kind in SqueezeCenter and would prefer to rely on just the tags.  I also know not having any auto detection at all would not make everyone happy either.  The thing is if we were to add an option to enable/disable the VA logic I feel it would only be fair to add options to enable/disable all the other auto detection logic we do such as Greatest Hits.

One solution would be to have a single option that enables/disables all SqueezeCenter auto detection logic instead might be better.  At least this would only add one option to the interface.  Would that be doable?

Steve,

can you go into a bit more detail?  what exactly is the "Greatest Hits" logic?  and what are the other auto logics that SC uses?

i for one, do not think a global setting is the way to go.  i don't think people look at these varying things as all or nothing.  i'm not sure i'd want GH logic off just b/c i want VA logic off.  imo, thats a different bug request.

i don't understand the resistence to adding options either.  yes, i realize support is an issue and the desire to keep a streamlined interface, but look at successful apps like winamp...  it has ENDLESS options and yet organizes them very successfully.

i agree that options like this are for advanced users, so why not just stick all such options in the advanced area?  i think ultimately it is better to have the options then not to have them.

http://forums.slimdevices.com/showthread.php?p=312382#post312382

can someone please confirm ALL aspects of the current VA/comps detection logic?

i know it uses TPE1 / artist mismatches, (just one will do), but does it use anything else?  strings in tags?  folder names or locations?  etc?

(obviously comp tags ID comps, but i am asking about when SC uses logic beyond explicit comp tags)

also, if one is using TPE2 to populate SC's ALBUMARTIST field, or if someone has explicit ALBUMARTIST tags, does that defeat SC's VA auto-detection / classification of a comp?  i know it takes priority in sorting, but does having such a tag keep the logic from classifying a given album as a comp?

(and what if the TPE2 says "Various Artists?")

thx.

with the new schema seemingly the new project upcoming, i want to re-request that slim incorporate this option that Erland has given the code for.

i do not need or want SC trying to figure out independently what is or isn't a comp.  i probably also don't want it doing "Greatest Hits logic" or any other logic.  i have no beef with self identifying comps to SC, its the auto detection logic thats at issue.

none of that stuff is intuitive nor is it even explained by SC that its doing that stuff.  these "features" only apply to SC and i simply find they are in my way or useless.

i think each of these should have its own on/off setting.  on = it does what it does today, off = it doesn't do anything / totally disabled.

if a compilation was scanned but the VA auto detect setting was off, the album should just show up under each artist regardless of any other setting.

(i also don't even want to get into the issue that decisions on media library handling shouldn't be made at scan time anyway, but rather only POST scan)

i do want to point out again that the VA logic is totally NOT fullproof or anything close to it.  assuming just one TPE1 mismatch means its a comp is ludicrous.

secondly, i think killing unnecessary steps in the scanning process is something infrant users, but not only them, will be very happy about.

a fullproof solution would be to let users specify strings that SC would then know mean its a comp.  for instance, if SC find "Various Artists" in the TPE2 field, it would know thats a comp, (even if TPE2 was populating SC's ALBUMARTIST field)  i only suggest this as another method, not as part of this bug request.

that solution is similar to having SC recognize comp tags, except it allows the user to stick with standard tags almost all apps support editing.

settings has an advanced area, why not put this option there and allow users to get away from this?

In my opinion, there is no need for an option to turn off compilation detection.

There's already enough confusing options, and I really don't see that there are any problems with compilation detection that need fixing.  Giving another option just means there are more combinations that need testing/can go wrong.

Having yet another option will complicate the code further, and can only slow it down, as it would need to do more checks whilst scanning each song.

People do not need to turn compilation detection off, there are always proper alternatives to get the music collection scanned properly.

In addition, some music tag formats, eg. id3 v2.3 do not have a standard compilation tag.

If a user does turn it off, they may get albums broken up with an explosion of artists in the Browse Artist page, with each artist having a sub-set of songs on the album.

I haven't seen a convincing example as to why such an option would be necessary.

I believe (2) in the original post is no longer an issue in that TPE2 can be used as ALBUM ARTIST.

in response to phil:

>In my opinion, there is no need for an option to turn off compilation
>detection.

so phil to infrant users: "tough noogies!"

just a joke.  ;)

>There's already enough confusing options, and I really don't see that there are
>any problems with compilation detection that need fixing.  Giving another
>option just means there are more combinations that need testing/can go wrong.

one problem is with comp detection itself.

you said there is 'no need for the the option.'

what if a user simply doesn't want comps detected at all, for any reason?

should they be FORCED to add either comp=0 tags or album artist tags?

no, they shouldn't.

another problem is that it often gives bad results, meaning results that don't reflect reality of the album itself.

another problem is that it starts a domino effect where more and more tags need to be added to try to manipulate outcomes, the ramifications of which aren't always obvious or desirable.

>Having yet another option will complicate the code further, and can only slow
>it down, as it would need to do more checks whilst scanning each song.

that makes no sense.  this isn't adding an option, this is making it possible to disable a "feature."  this should mean less checks.  disabling it should also make the "merge various artists" stage unnecessary.

and you can ALWAYS argue that changes make the code more complicated.  that isn't a valid argument b/c it would mean the code could never change.

>People do not need to turn compilation detection off, there are always proper
>alternatives to get the music collection scanned properly.

disagree.  see above.  and its not always about forcing users to comply, sometimes SC should comply.

the VA detection should NEVER have been mandatory to begin with.

>In addition, some music tag formats, eg. id3 v2.3 do not have a standard
>compilation tag.

all the more reason to allow a user to turn it off.  if you want to defeat it, you don't want to have to use non-standard tags.

>If a user does turn it off, they may get albums broken up with an explosion of
>artists in the Browse Artist page, with each artist having a sub-set of songs
>on the album.

and maybe, just maybe, thats what a user wants?

in winamp, i can easily browse both TPE1 and TPE2 and switch between them without a rescan.  there are times that browsing TPE1 is desired.

>I haven't seen a convincing example as to why such an option would be
>necessary.

i have made arguments for this that i feel are compelling.  you can disagree, np.  but why you want to FORCE everyone to be subjected to it, rather than allow everyone to opt in or opt out, makes no sense to me whatsoever.

>I believe (2) in the original post is no longer an issue in that TPE2 can be
>used as ALBUM ARTIST.

well, yes and no.

yes in that if you have TPE2 treated as album artist, you can defeat it.

but also no; what if you use TPE2 as Band correctly?  what if you don't use any non-standard tags?  what if you don't use TPE2 at all but don't want comps identified?

>one problem is with comp detection itself.
There is no problem, it detects compilations based on the rules fine.

>what if a user simply doesn't want comps detected at all, for any reason?
Why?  Because the user hasn't got correct tags, things appear as compilations when they don't want them.  Turning off compilation detection won't fix the problem, it will just show up in a different way.  Probably by an explosion of artists that have albums of the same name (where they should be a single album).

>should they be FORCED to add either comp=0 tags or album artist tags?
>no, they shouldn't.
They shouldn't normally need comp=0.  Adding that to everything, which is equivalent to turning off compilation detection, wouldn't fix the problem.
They should add an album artist tag, or set the artist tags to be the same.

>another problem is that it often gives bad results, meaning results that don't
>reflect reality of the album itself.
The results reflect the tags on the files.  Garbage in, garbage out.  An option to ignore the garbage doesn't fix the problem.

>another problem is that it starts a domino effect where more and more tags need
>to be added to try to manipulate outcomes, the ramifications of which aren't
>always obvious or desirable.
Untrue.

>this isn't adding an option, this is making it possible to disable a 
>"feature". this should mean less checks.  disabling it should
>also make the "merge various artists" stage unnecessary.
>
I should have said that it may be slower.  It's unclear.

If it was turned off, that could result in more artists and albums being created in the database.  I'm unclear exactly how the scanner phases work, but it's certainly possible that extra database writes could happen - it may be slower.

Turning off the auto detection would not mean "merge various artists" is not necessary, because compilation tags could still be added, and I think this is still needed for albums that are split over different folders too.

>and its not always about forcing users to comply, sometimes SC should comply.
SC should comply with what?

>the VA detection should NEVER have been mandatory to begin with.
It wasn't to begin with, but it was added to solve problems.  The vast majority of users seem happy with it.

>if you want to defeat it, you don't want to have to use non-standard tags.
There really should not be a need to defeat an album that has been deemed a compilation, by setting compilation=0.  That generally is not the right thing to do.  Add an album artist tag, if the album contains guest artists.

>and maybe, just maybe, thats what a user wants?
If the user wants to see all artists, there's already an option to "List compilation albums under each artist".

>what if you use TPE2 as Band correctly?  what if you don't use any
>non-standard tags?  what if you don't use TPE2 at all but don't want comps
>identified?
If a user doesn't have any album artist, and has guest artists, then not having compilation detection would result in several albums - one for the main artist and one for each song with a different guest on it.

Turning off compilation detection doesn't solve the underlying problem.

i don't want to restart old arguments or debates, but i do think this is a worthy option to add to SBS / LMS.

Erland did the code, its attached to the bug, so that shouldn't be a problem.  

the option has several uses:

1. it eliminates a scan step, saving time for those who don't need or want it, esp useful for underpowered hardware users.

2. it allows users to decide if they want comps detected or not.  some users might not want them detected, might want their "master lists" made up of all track artists, etc.

and wouldn't it be nice to have the OPTION to see what your lists look like as a consequence of ONLY one's tags, and not some built in logic invisible to the user?

3. its a nice debug option.  if you suspect that having comps detected is causing issues, you can turn it off and test the hypothesis.

thx!