This sounds familiar, will investigate further.

I was able to reproduce this behavior when the Artist equals the Conductor as well. However I did not see this behavior when the Artist equals the Band/Orchestra. I suspect this has something this do with the compilation logic. 

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

This does not appear to be OS specific. Changing to all.
Tags appear to be read properly. Changing to database.

I ran into this same problem just a few days ago.  In researching I also found that all the tags are read correctly.  Turns out that while the contributor-track table is populated correctly, the contributor-album table only has one contributor role listed per contributor (I think it's the last one, but I didn't test this rigorously).  I dug a little further and found in the _postCheckAttributes method of Slim::Schema (line 2213 rev 11929) deletes all contributor-album entries for a given contributor before assigning the new role.  I commented out that deletion and all my artist showed up as expected.  I'll attach a patch shortly.  Unfortunately since I don't know why the line was originally there, I'm not sure if my change has further-reaching implications.  Please advise.

Thanks!  Stephen

Created attachment 1937 [details]
Possible fix (simple removal of lines from Slim::Schema::_postCheckAttributes)

Here's the promised patch.  Previous warning applies: I don't know what else this changes, but it does fix this particular bug.

those lines were moved to the current location to fix bug 4516 and bug 3824.

the original code snip, in its original location was added at change 7620, which is the split scanner merge.  Unfortunately that branch is gone. I'm hoping there is a backup of old branches?   

This code is for handling a possible change in album or artist (contributor) tags when running a "new and changed" rescan.  This will need to be tested against a library test case using multiple imports (folder/musicmagic/itunes), playlists with some cases of artist = composer as well as some other roles. We'll need to make sure we don't reintroduce bug 4516, bug 3824 or create any new duplicates or various artists type problems.  

This is the scariest part of the code, in my books (because of the code, but also because of people's reactions to its behaviours).  

That's what I was scared of...  Thanks for the other bug references, I'll look at them, but I can't promise anything.

Looking at the other bugs related to this section of code, it definitely is a slippery slope.  Since I'm not using iTunes or MusicIP, I'm probably okay working with the patched version for the near future.

It's probably also worth mentioning the other workaround is to move the COMPOSER and CONDUCTOR tags to something SlimServer doesn't recognize...  With Vorbis Comments this is pretty easy, with ID3 tags it probably isn't.  Currently I have one album with an ARRANGER tag that matches the ARTIST tag and this problem doesn't come up because SlimServer doesn't have a role for ARRANGER.

For future reference my entire library is FLAC with Vorbis Comments.  I'm not tagging anything with COMPILATION or ALBUMARTIST, and I prefer tracks to appear under each contributor in the "Browse by Artist" list.  I just recently started retagging my library with all the contributors in the ARTIST tag, and that's when this bug cropped up.

In considering fixes for this bug, I noticed that rev 11663 (fixing bugs 3824 and 4516 and creating this one) also created a bug where correcting typos in contributor tags isn't possible without a complete wipe.  Since the loop only deletes contributors that are in the current tags, removed contributors (i.e. typos or spelling errors) will never be deleted from the table.  I leave it to the higher powers to decide if a new bug should be created since it all is tied to the logic being discussed here.

I'm beginning to think that for rescans to work correctly the album-contributor mapping really needs to be created for the complete album in memory and then compared with the database version (if it exists).  This would allow both additions and deletions to occur, and only new changes be applied (probably not a big deal, but it might recoup some of the overhead of creating the complete mapping in memory).  Any other solution I can think of requires either clearing all entries for the album (reintroducing bugs 3824 and 4516) or perpetuating this bug (or at least the removal problem I brought up just now).

This is not going to get fixed for 6.5.2, however we realize it's a serious issue, especially with the increased use of the composer tag.

retargetting to make an earlier attempt than 7

see bug 3699, avoid retriggering that problem.

Please have a look at bug 4882: it's the same problem. (Bug 4882 describes the same issue when Artist = Albumartist.) We've reached the same conclusions independently--including the code revision and the disclaimer.

@Steven or Chris: I think it's pretty safe to mark one of these as a duplicate.

*** This bug has been marked as a duplicate of 4882 ***

Steven and I are both not seeing this any more. 

Thanks for your answer. I looked into the bug and applied the following:
If the Composer tag is not set to be displayed in the Artist list (under Server > Settings -> Behavior), the Artist for a particular track will not be displayed in the Artist list if the Artist tag for that track happens to be identical to the Composer tag.  That is, if the Artist and Composer for a particular track are both set to SOMEARTIST, SOMEARTIST won't display in the Artist list if the Composer tag is not set to display. I suspect, though I haven't verified this, that the same problem will occur if the Conductor or Band/Orchestra tag is identical to the Artist tag. I'm using SlimServer 6.5.2 - 11735 for Windows. thanks david
This partly solves the problem, but makes it even bigger. Now every artist is shown in the Artist list I inquired about, however as I see it, all “Contributing Artist” are chosen and not only the “Album Artists” what I would expect. Let’s say I have an Album from Albumartist “A” and three songs on this album are from Contributing Artists “B”, “C” and “D”, that would leave me with 4 entries in the Artists list, although I am only interested in “A”. My default search pattern (and I suppose there are many more people out there) is by Albumartist. 
Are you differentiating between Albumartist and Contributing Artist? With my music collection, I have about 4500 “contributing artists” while only owning some 1200 albums. This makes navigation super hard.

Thanks for your help
Volker