This bug is present the in trunk too.

I don't want to hijack this bug if my problems have a different cause, but I'm seeing problems beyond ALBUMARTIST.  See http://forums.slimdevices.com/showpost.php?p=191580&postcount=2.  If it looks like they're different, I'll open another bug.

I will take a look.

This seems related to Bug 4629.

It seems that this problem only happens when Slimserver uses TRACKARTIST instead of ARTIST. For single artist albums and compilations (having COMPILATION=1) the artists of a track are always showns as ARTIST in the file info page, independently if ALBUMARTIST is set or not. But for albums having ALBUMARTIST set and the COMPILATION flag not set, in the track info TRACKARTIST is shown instead of ARTIST and pressing the RIGHT button on the remote shows empty.

I don't understand why this third kind of artist (TRACKARTIST) is necessary at all. I have the impression that with ARTIST and ALBUMARTIST all cases can be covered (but I may of course be wrong) and that consistly using ARTIST for track artists would reduce the problems.

I also believe that no compilation tag and COMPILATION=0 are not the same thing.

I think it _should_ be the same. As far as I remember Dan or Dean explained in a previous post in the forum that for fome file format (mp3, ogg, flac?) it cannot be destinguished between "not set" or "0". If that is true "not set" and "0" must be handled as the same.

The problems I previously reported (in original bug #3824) happens when ALBUMARTIST is set but COMPILATION is not set (I never set COMPILATION=0, either I set it to 1 or I don't set it at all).

In addition to the behavior that windowshade describes, I also see that the "ALBUMARTIST" tag value is simply not showing up under Home/Artists at all. It does not seem to matter if additional "ARTIST" tags are present or not. This did work in previous versions of the server.

(In reply to comment #4)
> This seems related to Bug 4629.
> 
Could be. But Bug 4269 predates Change 11663--which coincided with this new quirk.

(In reply to comment #6)
> I also believe that no compilation tag and COMPILATION=0 are not the same
> thing.
> 
You are correct. (For instance, setting COMPILATION=0 causes an album to be listed under each of that album's contributors in the Home/Artist/ browse list.) However, in the case of this bug, explicitly defining COMPILATION=0 does not force the Album Artist to display properly in the browse lists, and role 5 is still absent in contributor_album. In essence, it does  not change the behaviour of this bug.

We are working on rigorously specifying this behavior for a future version, but it's not going to get done in time for 6.5.2

I am seeing similar problems relating to the use of ALBUMARTIST and BAND tags:


I have an album by Fripp & Eno, which I have tagged all tracks with:

ARTIST=Robert Fripp;Brian Eno
ARTISTSORT=Fripp, Robert;Eno, Brian
ALBUMARTIST=Fripp & Eno

Slimserver song info page reports this as:
Album Artist: Fripp & Eno
Track Artist: Brian Eno, Robert Fripp

I can see the album listed under Artists/Fripp & Eno, but don't see it under the contributing artists any more.  I believe this is the same issue as reported initially on this bug.

----------------

I have another album by Fripp & Eno, which I have tagged all tracks with:

ARTIST=Brian Eno;Robert Fripp
ARTISTSORT=Eno, Brian;Fripp, Robert
ALBUMARTIST=Fripp & Eno
BAND=Fripp & Eno

Slimserver Song Info reports:
Album Artist: Fripp & Eno
Band/Orchestra: Fripp & Eno
Track Artist: Fripp & Eno

I don't understand why I cannot see the contributing artists in this example.

----------------

I have another album by Fripp & Eno, which I have tagged all tracks with:

ARTIST=Brian Eno;Robert Fripp
ARTISTSORT=Eno, Brian;Fripp, Robert
BAND=Fripp & Eno

I think I ended up with a BAND tag instead of ALBUMARTIST tag as I used iTunes to tag the songs (iTunes album artist sets the BAND tag, and doesn't create an ALBUMARTIST tag).

Artist: Brian Eno, Robert Fripp
Band/Orchestra: Fripp & Eno

I can see this album listed under Artists/Brian Eno and Artists/Robert Fripp, but not under Artists/Fripp & Eno.

I then remembered that I didn't have Slimserver Settings -> Behaviour -> Band/Orchestra ticked, so I ticked it and voila I can now see BANDs in the artists lists, so this fixes that issue.

This does indicate though that by not including the ALBUMARTIST tag, the album appears under the contributing artists.  I can use BAND=Fripp & Eno in this case without needing ALBUMARTIST, but my understanding is that BAND would not group songs together on one album if there were different contributors on some tracks.

As a follow-on from the last post, it would seem that all of my Fripp & Eno albums should be tagged with BAND=Fripp & Eno, and not use ALBUMARTIST.

One side effect of this appears to be that the BAND is listed within Browse Artists sorted under "E" rather than "F".  I can only think that this is because I had entered the contributing artists for one of the albums as "Brian Eno;Robert Fripp" with an ARTISTSORT of "Eno, Brian;Fripp, Robert", and when it creates a BAND entry, it is picking up the ARTISTSORT for the first contributor.

Again, I can fix this individual case, as I can change all contributing artists to be Robert Fripp;Brian Eno, and therefore the band "Fripp & Eno" would be sorted under Fripp, Robert.

However, this would be bad for cases where the BAND name is nothing similar to any of the contributing artists.

Christopher, maybe you could back out the "fix" for bug 3824 that broke this
so that 6.5.2 isn't a step backwards from 6.5.1?

(In reply to comment #13)
> Christopher, maybe you could back out the "fix" for bug 3824 that broke this
> so that 6.5.2 isn't a step backwards from 6.5.1?
> 
I wouldn't agree with that. With the present status at least the artists of "normal" compilation albums (albums having ALBUMARTIST=Various and COMPILATION=1) can be searched for. Only albums having ALBUMARTIST set and COMPILATION=0 still have a problem. In my library the latter are much less than the "normal" compilation albums.

(In reply to comment #14)
> I wouldn't agree with that. With the present status at least the artists of
> "normal" compilation albums (albums having ALBUMARTIST=Various and
> COMPILATION=1) can be searched for. Only albums having ALBUMARTIST set and
> COMPILATION=0 still have a problem. In my library the latter are much less than
> the "normal" compilation albums.

As a counterpoint to that datum: every single album in my collection has ALBUMARTIST set, whether it's a compilation or not.  A minority are compilations, so for my library most albums cannot be found when searching by artist.

And albums that have ALBUMARTIST with no COMPILATION tag will not work either, I think?

retarget for 6.5.2 as this is also related to the code section covered by change 11662.

(In reply to comment #10)
> We are working on rigorously specifying this behavior for a future version, but
> it's not going to get done in time for 6.5.2
> 

As discussed on the forums, this bug does not address the users' perceptions of how SlimServer ought to function; it describes incomplete collection of information. That said, a rigorous specification will not help if the scanner does not record the data correctly.

Here's what I've found: ALBUMARTIST roles are not being entered into the contributor_album table when the Album Artist/Band/Orchestra is the same as one of the contributing Artists. (Most Album Artist entries are also listed as contributing Artists, so this applies to almost all albums which have an Album Artist defined.)

The bug was introduced when a snippet of code in Slim\Schema.pm was moved inside a while loop because it was breaking other scans--MusicMagic, for instance. (See change 11663.) The offending code follows:

># Remove all the previous contributor album mappings
># for the contributor & album combination.
>$self->search('ContributorAlbum', {
>        'album'       => $albumObj->id,
>        'contributor' => $contributorObj->id,
>})->delete_all;

I believe this effectively removes an ALBUMARTIST entry from the contributor_album table when that string is already present as an ARTIST (or TRACKARTIST). To test my hypothesis, I've commented the above text out of Schema.pm and used ActivePerl to run a scan using that (hacked) file. Lo and behold--Album Artists display properly! Hurrah!

By now it should be clear to everyone that I am NOT a programmer, Perl or otherwise. I have no idea what repercussions this modification will have, but I've determined the source of the problem. The above code is deleting an ALBUMARTIST entry from the table whenever that contributor is already associated with the album as an ARTIST or TRACKARTIST. The code appears to serve a cleanup role of some sort, but it needs to do it more selectively.

I hope this will help. I'll post my hacked Schema.pm file in an effort to encourage others to tamper.

Created attachment 2020 [details]
Schema.pm with offending code commented out

kdf just referred to the same code as I was composing this entry--sounds promising. Of course, this is not a fix--it just demonstrates the source of this problem.

*** Bug 4925 has been marked as a duplicate of this bug. ***

"multiple roles for same contributor removed from contributor_album table" 

I've revised the Summary to describe the general case of the bug--including the Artist=Composer issue (see bug 4925). When a contributor is already associated with an album in a given role (TRACKARTIST, COMPOSER, i.e.), additional roles for the same contributor are deleted. Two examples:

ALBUMARTIST is deleted when TRACKARTIST=ALBUMARTIST
ARTIST is deleted when COMPOSER=ARTIST

Erland, the developer of the "Custom Browse" plugin, has come up with a potential quick and dirty fix for this bug.  Please see this post on the beta forum: http://forums.slimdevices.com/showpost.php?p=202837&postcount=29

As 4925 has been marked resolved now, I want to highlight one of my last comments from that discussion: change 11663 also introduces a bug where it is impossible to REMOVE an artist from the contributor_album table without a complete wipe.  Any solution to this bug must take that into account.  For further musing about what that potential solution looks like, feel free to see my comments on 4925.

(In reply to comment #23)
> As 4925 has been marked resolved now, I want to highlight one of my last
> comments from that discussion: change 11663 also introduces a bug where it is
> impossible to REMOVE an artist from the contributor_album table without a
> complete wipe.  

I've tested 'typo correction' using an earlier revision (Slim/Schema.pm change 11134) and observed the same problem. I did not roll back the entire installation, though, so I can't say for sure. Are you certain that bug surfaced with change 11663? On a related note, is there a bug filed? 

Heads up to triode's proposed fix for bug 4882: http://forums.slimdevices.com/showthread.php?p=203159#post203039.

sorry. http://forums.slimdevices.com/showthread.php?p=203039

As windowshade just pointed out, Triode has proposed an easy fix: Adding the following two SQL statements to the top of schema_optimize.sql:

DELETE FROM contributor_album;

INSERT INTO contributor_album (role,contributor,album) SELECT DISTINCT role,contributor,album FROM contributor_track,tracks where tracks.id=contributor_track.track;

I've tested this fix with both 6.5.x svn 12053 and the trunk and it seems to completely solve the problem this bug causes with my library (i.e. COMPOSER tags seem to kill ARTIST tags).  Also, this fix does not seem to add appreciably to the library scan time. 

patch added to 6.5 in change 12074

Marking this as fixed and verified, if anyone is still seeing this please feel free to re-open with more details. 

This bug seems to be not completely fixed. I have a Toni Braxton album on which one song is a duett from Toni Braxton and Shaggy. So all tracks have ARTIST=Toni Braxton and the duett has in addition ARTIST=Shaggy set. Additionally for all tracks ALBUMARTIST is set to Toni Braxton to list the album as Toni Braxton album. COMPILATION is not set.

In my library the duett from the above album is the only track for which Shaggy exists as artist. This is important since the described problem does not exist if the artist is additionally an artist on another album (an own album or a compilation on which he is the sole artist of a track).

With this artist the follown problem exists:

When I search for Shaggy in the web interface using the simply search Shaggy is found (that's ok).
However, when I search for Shaggy as artist in the advanced search nothing is found.

When I browse to the above album, select the duett to show the song info page and click on the artist link for Shaggy an empty page is shown.

Similar problems appear on the squeezebox:

When I search for Shaggy as artist on the squeezebox using the remote nothing is found (this is equivalent to the advanced search in the web interface).

When I browse to the album, scroll to the duett track, press RIGHT, scroll to artist Shaggy and press RIGHT "empty" is shown (this is equivalent to browsing in the web interface).

So it seems that Shaggy is not correctly identified as artist.

So I think this bug should be reopened (which I cannot do).

(In reply to comment #29)
> So I think this bug should be reopened (which I cannot do).
> 

Dieter,
Works for me. (I am unable to reproduce your problem in exactly the same circumstance.) If you haven't already done so, try a wipe & rescan to ensure the problem persists. If it does, you may have identified a new bug. 

Hey--there IS some funny behaviour from Advanced Search. I stand corrected.

Could you raise a new bug (after checking existing bugs) for the specific cases which don't work.  This way we will be able to address them.  I'm reasonably confident that the original bug here is resolved, so now we need to know of any related bugs so they can be addressed.

Sorry, I have at the moment no time to check that in detail and create a new bug report since I am just leaving for a one week vacation. What I forgot to mention is that I use MusicIP. This was important for the previous problems since I had the previous problems only when using MusicIP.

Part of comment 26 sounds like (or similar too) bug 4629.

Is this actually working for people in 6.5?  I just finally got around to updating my code from SVN,
and added the TPE2 tag to a single album, a Bob Dylan tribute with different artists performing his
songs.  As an example, the tags for one of the songs look like this:

greg@lwm| id3info /music/mp3/cd/Dylan,\ Bob/A\ Nod\ To\ Bob/01\ -\ Love\ Minus\ Zero-No\ Limit.mp3 

*** Tag information for /music/mp3/cd/Dylan, Bob/A Nod To Bob/01 - Love Minus Zero-No Limit.mp3
=== TIT2 (Title/songname/content description): Love Minus Zero/No Limit
=== TPE1 (Lead performer(s)/Soloist(s)): Eliza Gilkyson
=== TALB (Album/Movie/Show title): A Nod To Bob
=== TYER (Year): 2001
=== TRCK (Track number/Position in set): 01/15
=== TCON (Content type): (80)
=== TLEN (Length): 233000
=== TPE2 (Band/orchestra/accompaniment): Bob Dylan
*** mp3 info
MPEG1/layer III
Bitrate: 320KBps
Frequency: 44KHz

I have the following possibly relevant server settings:
* Group compilation albums together == variousArtistAutoIdentification
* List albums by band == useBandAsAlbumArtist

After doing a clear DB and fresh rescan, I do not see the desired behavior, which is that this
album should be listed with my other "Bob Dylan" albums when browsing by artist.  Instead, it
appears under "Various Artists".

Looking at the database, I see that for this track, the contributor_track table contains two
contributors, "Eliza Gilkyson" with role=1(artist) and "Bob Dylan" with role=4(band).  I guess
I was expecting the second to have role=5(albumartist) since I have the useBandAsAlbumArtist
option set but this looks OK so far.

Looking at the contributor_album table, I see contributors with role=1(artist) for all the
actual performers, and a contributor "Bob Dylan" with role=4(band) which again seems reasonable.

However, looking at the albums table, the entry for this album has the contributor column
populated with "Various Artists".

It looks like we need to add a bit of code to actually transform the BAND/TPE2 tags to ALBUMARTIST when the useBandAsAlbumArtist option is set.  I suspect adding something like the following to the top of the function _mergeAndCreateContributors, just after exiting when the track is non-local will do the trick:

        if (Slim::Utils::Prefs::get('useBandAsAlbumArtist') &&
            $attributes->{'BAND'} &&
            !$attributes->{'ALBUMARTIST'}) {

            $attributes->{'ALBUMARTIST'} = delete $attributes->{'BAND'};

            if ($::d_info && $_dump_postprocess_logic) {
              msgf("-- Contributor '%s' of role 'BAND' transformed to role 'ALBUMARTIST'\n",
                   $attributes->{'TRACKARTIST'});
            }
        }

I'll test this and report back.

that seems to work, modulo the cut-n-paste-o in the mesg() output line.
since this bug is closed, I will open a new bug and attach a proper patch.
will likely upgrade to pre- 7.0 first..

This bug has been fixed in the 7.3.0 release version of SqueezeCenter!

Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already.  

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.