just to echo a point i made in that thread:

"i think it should read and store both equally. why should some data be more important than other data?

the debate should be over what SC does with it once its in the DB, and i would say that should be a user option. 

so in other words, ALL tags are scanned in, and then the user says treat tpe2 as album artist (or not) [already the case] and ignore/don't ignore comp tags.

that way the user can decide, as it should be.

btw, my understanding was that comp=1 took precedence over ALBUMARTIST even if that data was in the DB. the bug may then only apply to comp=0 i guess we'll find out when the bug gets addressed."

and by that last comment, what i meant is that as far as i knew, the tag data for album artist still made it into the ALBUMARTIST field, and was still used to some extent, but that comp=1 allowed such files to be known and classified to SC as a comp regardless, (and that you couldn't disable the comp tag, only remove it).

totally separately, comp=0 seems to be the verified bug, but we're assuming comp=1 causes it then too.

after i filed the bug phil meyer said:

"The bug is not that with Compilation=0 the album artist logic doesn't work. You stll get album artist, but no track artists, so performing artists on the album still get expanded out onto the main list of artists."

at this point i'm totally confused.

Steven: can you have a look at this one?

Be aware that I think Compilation=0 also has another purpose in the scanner.

I think the original purpose of adding support for Compilation=0 tags in the scanner was to support peoples libraries where songs on an album are not gathered in the same source folder.

This is the default iTunes behaviour - it stores ripped songs in artist/album/track folder hierarchy.  As a result, SC would see compilation albums and albums with guest performers as several different albums with the same name; one for each artist, due to the way SC solves the "Greatest Hits" issue.  The "Greatest Hits" issue was that two albums with the same name but by different artists used to be merged into a single album, and then it would become a compilation album as there were different performing artists on it.

And thus I think a COMPILATION tag (or in iTunes case ITUNESCOMPILATION) with the value 0 can be used to rejoin all songs on a single album spread across multiple folders back into one album.

This needs to be considered in any change to the scanner logic.

I have attempted to verify the issue reported in this bug report.

The issue being reported is not true.  A Compilation=0 tag does not cause album artist tags to not be read.

However, the bug report was not the original source problem that was being reported (in the original forum thread).

The problem reported was: The contributing artists for songs on an album with an album artist and compilation=0 are expanded out into the Browse Artists list (even when "Group compilation albums together" setting is selected and the artist does not have any other albums).  Normally, with "Group compilation albums together" and no compilation tag, the contributing artists would not appear in Browse Artists if they only appear on albums or as track artist contributors.

For information: You have to be very careful when reporting "db field of album artist".  There are two such album artist fields stored in the database: albums.contributor and contributor_album.contributor (where role=5).

My test case:

I ripped an album with a guest artist.  I set ITUNESCOMPILATION=0, and ALBUMARTIST=AAAAAA.

I scanned the album into SC.

The result in the database was:

album.compilation = 0
album.contributor = 'AAAAAA' (the album artist)
contributor_album for the album.id had:
  2x role 1 rows (one for the main artist and one for the guest artist)
  role 5 (album artist) which was also 'AAAAAA'.

The album does not appear as a compilation (ie. not under Browse Artists > Various Artists); it appears correctly under the artist 'AAAAAA'.

The album information reports the album artist, and the main artist and the guest artist.

I browsed to the guest artist (Browse Artist > Bark Psychosis), which I do not have anywhere else in my collection.  This should not be possible has I have selected "Group compilation albums together".  The album is displayed, but with just the one track that the artist appeared on.

As a comparison, I removed the ITUNESCOMPILATION=0 tag from the previous example.

A rescan for new/changed files resulted in strange database content (I think it doesn't recover from the previous content of the album that had already been stored - I will leave this for a new bug report).  As a result, I scanned a totally new album, essentially the same type of tags, but without an ITUNESCOMPILATION tag.

i.e. I ripped another album with a guest artist.  There are no compilation tags, and ALBUMARTIST=BBBBBB.


This album is scanned and is browsable correctly.

The database stores the information as follows:

album.compilation = NULL
album.contributor = 'BBBBBB'
contributor_album for the album.id had:
  2x role 6 (track artist) rows (one for the main artist and one for the guest artist)
  role 5 (album artist) which was also 'BBBBBB'.


As a result, the "group compilation albums together" setting is honoured correctly, because Browse Artists lists any contributor record with role=1 (and would also list any Composers, Conductors and Bands if these roles are enabled in the Music Library settings page).

Phil,

thanks for fully explaining "inthebaths" issue that was described in the thread...  while i can't and haven't verified your findings above, i am sure they are much much closer to describing the issue than my opening stab at it.

the bug title should probably be changed to something more accurate as a result, any suggestions?  (assuming i can do it?)

my original comments in this bug were based on my interpretation of these comments of yours from the URL i posted above, specifically:

"I believe there was a post in the past about the actual order that the scanner processes tags (someone read the code).

I think that the scanner reads the compilation tag first and doesn't set album artist and track artist contributor roles if it finds a compilation tag. That seems to tie in with InTheBath's problem, as his album artist tags were being ignored (had artist roles reported for the songs and not track artists). He has subsequently removed COMPILATION=0 and everything is working.

I think that album artist tags should be detected first by the scanner. If there is a consistent artist for every song on the album (or album artist for each song), the album can't be a compilation."

and

"I assume compilation=1 would also cause skip album artist detection (would result in artist contributor roles, and no album artist or track artist roles)."

the problem is i am still confused.

are those 2 quotes now basically to be ignored and replaced by your take via your bug comments?  i'm just trying to piece it all together to get the big picture, and figure out the wheat from the chaff.

i also would like to say that i would hope that the scanner would simply import all data AND THEN decide what to do with it.

meaning, i do not want SC to make decisions about the meaning of data at the time of scanning, but rather post scan.

in other words, it seems to me that it shoud not matter what info it reads first or last, but rather how it manipulates it after importing ALL the info it finds into the DB.

and this would then allow for what Erland and I think is correct: specifically it allows SC to manipulate ALL the data it finds.  so if a CD had an album artist, AND a comp tag=1, it could be made to manipulate that in the way that Erland outlined.

anyway, thanks for your posts to this bug.

Phil,

i'd also be interested in seeing your results when album artist is set, and comp=1 is set, (in the files tags).  it would complete the data set.

and its very interesting that you discovered a new bug, that:

"A rescan for new/changed files resulted in strange database content (I think it
doesn't recover from the previous content of the album that had already been
stored - I will leave this for a new bug report)."

i take that to mean that remvoing the tag doesn't change everything in the DB that needs changed on a "new/changed files rescan."  yes?

i guess we would assume a "full clear and rescan" would pick up the change tho, right?

>the bug title should probably be changed to something more accurate as a
>result, any suggestions?  (assuming i can do it?)
Yes, I was going to, but don't have permissing - I think only the owner, or Logitech developers can change it.

>my original comments in this bug were based on my interpretation of these
>comments of yours from the URL i posted above, specifically:
Yes, I realise that, sorry.  I think I did explain what I thought the issue was (artist roles instead of track artist roles), but also included reasons/solutions that probably confused the issue a bit.

>i also would like to say that i would hope that the scanner would simply import
>all data AND THEN decide what to do with it.
I think that is a valid approach, but that it is only likely to happen in the new schema changes for 7.4.

It hs been discussed that there could be effectively a two-stage scanning process, eg. cache all tags into a table, and then from that table build some additional tables to represent the chosen library settings.

>meaning, i do not want SC to make decisions about the meaning of data at the
>time of scanning, but rather post scan.
I think some settings would still likely need a "scan", but that would be a lot quicker if it read from the first DB table to rebuild the actual library tables for browsing (rather than re-read from the source file tags).

But that is a discussion for the development forum (best left to developers).

>in other words, it seems to me that it shoud not matter what info it reads
>first or last, but rather how it manipulates it after importing ALL the info it
>finds into the DB.
Yes, I think everyone is in agreement, but it's an enhancement for the future schema changes.

>i'd also be interested in seeing your results when album artist is set, and
>comp=1 is set, (in the files tags).  it would complete the data set.
Yes, I intend to do that too.  Watch this space!

>I take that to mean that remvoing the tag doesn't change everything in the DB
>that needs changed on a "new/changed files rescan."  yes?
Yes.  I've had problems like this several times before, but couldn't put my finger clearly on the problem.  I now have info to be able to report a specific problem (there's probably others).

>I guess we would assume a "full clear and rescan" would pick up the change tho,
>right?
Yes.

I've tried scanning an album with an ALBUMARTIST and ITUNESCOMPILATION=1.

I saw some really odd behaviour in the database content, so I am trying some more rips with slightly different tags before posting my final analysis.

The first attempt (mp3 album) had a combination of artist and track artist album_contributor roles, which is not good.

I tried a fresh album rip in FLAC format using ALBUMARTIST and ITUNESCOMPILATION=1 and got different behaviour - the album was not stored as being a compilation.  It could be that the scanner doesn't look for ITUNESCOMPILATION on FLAC tags (perhaps only looks for ITUNESCOMPILATION on id3v2.3 tags), so I'm trying the FLAC again with COMPILATION=1.

I need to try also with an mp3 album, to check that it has the same results as a FLAC album.

Rescan for new/changed files definitely doesn't work when changing compilation/album artist information in files - it doesn't get rid of the old contributor_roles for example.  This may be a big source of confusing bug reports where tags that work for some users don't work for others (because they have old information in their library that is only tidied up on a full rescan).

Okay, a brand new mp3 album ripped with ALBUMARTIST and ITUNESCOMPILATION=1.

The result in the database was:

album.compilation = 1
album.contributor = 'DDDDDD' (the album artist I defined)

contributor_album for the album.id had:
  an artist role for the main artist
  an artist role for the guest artist
  an album artist role which was 'DDDDDD'

Browse Artists lists the album under "Various Artists" (and NOT under "DDDDDD").
Browse Albums reports the album artist as "DDDDDD".

I'm curious over the guest artist - it isn't exploded out into the Browse Artists list, even though the guest artist has an artist role (not a track artist role like I was expecting).

The Album Artist takes precidence over Compilation tag in defining the album contributor, but the album still has a compilation indicator. I think this may be roughly what Mr Sinatra wanted, except Album Artist and Compilation don't quite live in harmony (depending on browse method, appears under different artists in the library). But, it's actually working quite nicely, I think.

So, when browsing artists, the compilation tag overrules the album artist (the album is only listed under the SC configurable compilation name (and not the album artist stored for the album "DDDDDD").  There is a discrepancy compared to browsing by album - eg. when sorting by artist, the artist appears under "DDDDDD" and not under the SC configurable compilation name "Various Artists".

Phil,

please post the bug number for the "scanning" bug you discovered here, (assuming you posted a bug report for it).

it seems there are a variety of descrepencies and inconsistentcies this bug  has brought to the surface.

i also can't help but wonder what might happen if you had no album artist, but did have comp tags?

in any case, i hope slim will take all this research and hard work on these various bugs to heart and figure out a solution that eliminates these issues across all formats, takes place post scanning, and is intuitive while also optional.

I raised bug 9938 for the rescan issue.

attempting to rename the bug to something more accurate, suggestions welcome.

i think at this point, with so many changes to the scanner, and as confused as this bug was to begin with, the bug should probably be closed as resolved.  if anyone objects, let me know and i will reopen it.  however, i think the best course of action would be to file a new bug if there is a need for it, and reference this one if appropriate.

one problem was the scanner not picking up changes to tags on new and changed scans, that should be fixed now with andys scanner work.  another problem was something to do with comp=0 forcing sbs to not populate the internal sbs AA field or something like that, and there may have been other issues, but i don't use comp=0 tags and like i said, prob best handled in a new bug if you find issues.

don't be timid to speak up tho!  :)  -mdw