Bugzilla – Bug 7812
Tracks sorted under Various Artists improperly
Last modified: 2009-07-31 10:19:29 UTC
To get our new Duet working, I upgraded from SlimServer to SqueezeCenter 7.0.1. After several complete DB rescans, I have noticed that the artist I have the most tracks by ("Steve Roach") is now missing from the artist list, although collaborative entries (e.g. "Steve Roach & Kevin Braheny") are still present (there are about 6 of these). Searching artists for Steve Roach works, and all the albums by him are present in the correct place in the album listing. Given that I have 35 albums with 187 tracks by Mr. Roach that I regularly use while working and sleeping, it would be nice to be able to get directly to his stuff in our collection. There were never any problems with this under SlimServer, nor is there when using Rhythmbox or iTunes to access our house-wide music collection. Stats: about 900 artists, 800 albums, about 9000 songs. Squeezebox 2 + Duet systems in separate rooms.
After some hunting around, it appears that what has happened is that sort ordering has changed from SlimServer -> SqueezeCenter. "Steve Roach" is now filed under "Roach", whereas "Steve Roach & Kevin Braheny" is filed under "Steve". I have to say that I find this new ordering quite confusing, and I wonder what the justification for it is.
Please check your file's tags. We don't change the sort order. But if there's an ARTISTSORT tag in the file, it will be used. Pretty often thes ARTISTSORT fields use precedence for the name over the first name.
How can I put this in the best way? My music library did not change across the upgrade from Slim Server to SqueezeCenter. With SS, I would see "Steve Roach" filed under "Steve"; with SqueezeCenter, the same artist is filed under "Roach". In both systems, "Steve Roach and Kevin Braheny" is sorted under "Steve". here's tag info from a solo file: ----------------------------------------------------- ogginfo !$ ogginfo 02\ -\ Where\ I\ Live.ogg Processing file "02 - Where I Live.ogg"... New logical stream (#1, serial: 6f60cbde): type vorbis Vorbis headers parsed for stream 1, information follows... Version: 0 Vendor: Xiph.Org libVorbis I 20070622 Channels: 2 Rate: 44100 Nominal bitrate: 208.000000 kb/s Upper bitrate not set Lower bitrate not set User comments section follows... TITLE=Where I Live ARTIST=Steve Roach TRACKNUMBER=2 TRACKTOTAL=5 ALBUM=New Life Dreaming MUSICBRAINZ_SORTNAME=Steve Roach DISCID=4c102005 MUSICBRAINZ_DISCID=hnAJjCe97aR8l1seGlGd9TQvvxk- Vorbis stream 1: Total data length: 20218723 bytes Playback length: 14m:03.773s Average bitrate: 191.698146 kb/s Logical stream 1 ended ---------------------------------- Here's the tag info from a joint work: ogginfo 01\ -\ The\ Breathing\ Stone.ogg Processing file "01 - The Breathing Stone.ogg"... New logical stream (#1, serial: 68a0d759): type vorbis Vorbis headers parsed for stream 1, information follows... Version: 0 Vendor: Xiph.Org libVorbis I 20050304 (1.1.1) Channels: 2 Rate: 44100 Nominal bitrate: 208.000000 kb/s Upper bitrate not set Lower bitrate not set User comments section follows... TITLE=The Breathing Stone ARTIST=Steve Roach & Kevin Braheny TRACKNUMBER=1 TRACKTOTAL=7 ALBUM=Western Spaces MUSICBRAINZ_SORTNAME=Steve Roach & Kevin Braheny Warning: EOS not set on stream 1 Vorbis stream 1: Total data length: 11058482 bytes Playback length: 6m:52.053s Average bitrate: 214.700013 kb/s -------------------------------------------------------- From my perspective, sort names "Steve Roach" and "Steve Roach & Kevin Braheny" should list fairly close to each other, rather than under different letters of the alphabet.
> From my perspective, sort names "Steve Roach" and "Steve Roach & Kevin Braheny" > should list fairly close to each other, rather than under different letters of > the alphabet. I fully agree. But SC doesn't even try to change the sort order unless told so by some information in the file. Oddly enough it's not what you're seeing using ogginfo. Would you mind uploading that file to this bug? You can limit access to the bug below if you want.
Created attachment 3230 [details] first audio file referenced by bug this file is copyright material.
QA to review
Thanks Paul, sorry for the delay. It seems as though the file you uploaded does not show the issue you're describing. For me SC7.1 is sorting it under S as it should, is this still not the case for you?
i've just upgraded to 7.1 so that we're on the same page. I will next attach a few screenshots. These shots were actually taken with 7.0.0 but i've confirmed that the behaviour is the same in 7.1.
Created attachment 3714 [details] Home->Artists->S in the "steve roach & ..." section Notice all the "Steve Roach & ..." entries, but no "Steve Roach".
Created attachment 3715 [details] Home->Albums->N near "New Life Dreaming" This is the album list near the album that contains the track I sent a copy of. This is just to show that the album does indeed exist in the DB (and on disk) and sorts normally.
Created attachment 3716 [details] Home->Artists->R in the "Roach" area a third shot from the artist list demonstrating that in fact, "Steve Roach" has vanished from even the "Roach" section. the only way to find his music now is "search" or album name.
Created attachment 3717 [details] search page results screenshot Just to prove I'm not crazy ... this is what I get from searching for "Steve Roach". Notice that he does indeed show up in the results.
(In reply to comment #12) > Just to prove I'm not crazy ... I don't think you're crazy Paul! :-) So this bug is still reproducible for you with 7.1 after clear and rescan, I wonder why I don't see it. While the music brainz tags do appear to be correct, would you mind removing them and seeing if that makes any difference?
Created attachment 3718 [details] Home->Artists->V Aha. Another screenshot that may be the one containing the cluestick. OK, so here we are in the "V" section, starting out with "Vangelis" (too many years as a teenager spent listening to space music). Followed by ... hmm, Bill Evans. Yeah, that makes sense. OK, so one or more Bill Evans tracks have been tagged "Various Artists", and he's ended up here along with ... Steve Roach. So this is probably why you don't see it with only that 1 track. What I guess is happening is that the scanner finds *a* Steve Roach track with a sort tag of "Various Artists", proceeds to put him into this list of "merged VA names", and then every subsequent SR track fails to move him back out of this listing? Does that make sense? You will note that there are 17-18 other artists misfiled in this way. Just think of all the Lucinda Williams music I've been missing! :)
proof of the pudding. here's the tag info (grepped) for the album that i think is to blame for triggering this bug: paul[19]>ogginfo *.ogg | egrep '(SORTNAME|ARTIST)=' ARTIST=Braheny & Clark MUSICBRAINZ_SORTNAME=Various Artists ARTIST=Steve Roach MUSICBRAINZ_SORTNAME=Various Artists ARTIST=Tim Story MUSICBRAINZ_SORTNAME=Various Artists ARTIST=David Darling MUSICBRAINZ_SORTNAME=Various Artists ARTIST=Hoppé-Tillman-Wheater MUSICBRAINZ_SORTNAME=Various Artists ARTIST=Thomas Barquee MUSICBRAINZ_SORTNAME=Various Artists ARTIST=Rasa MUSICBRAINZ_SORTNAME=Various Artists ARTIST=Bruce Kaphan MUSICBRAINZ_SORTNAME=Various Artists ARTIST=Mychael Danna MUSICBRAINZ_SORTNAME=Various Artists ARTIST=Mychael Danna MUSICBRAINZ_SORTNAME=Various Artists ARTIST=Michael Stearns MUSICBRAINZ_SORTNAME=Various Artists ARTIST=Coyote Oldman MUSICBRAINZ_SORTNAME=Various Artists ARTIST=Øystein Sevag MUSICBRAINZ_SORTNAME=Various Artists ARTIST=John Boswell MUSICBRAINZ_SORTNAME=Various Artists ARTIST=Bill Douglas MUSICBRAINZ_SORTNAME=Various Artists paul[20]>pwd /music/Various Artists/Slow Music for Fast Times (disc 1)
I'm late on this thread. But what MySQL version are you on? AFAIK 5.0.51 or similar has a bug which can result in broken sort order.
5.0.50: http://bugs.mysql.com/bug.php?id=32202
Thanks Michael, I've reproduced this with 5.0.51a-3ubuntu5.1
I'm using 5.0.27. I did not upgrade MySQL before moving to SqueezeCenter (from SlimServer), and it was that change that created these orphaned "tagged once, tagged forever" artist names, rather than any MySQL updates.
I recently went through these same issues with another customer in bug 7698. Turned out there was some errant sort order tags in some of the customers files as well. SqueezeCenter uses the last sort order tag found for any given artist. This behavior is described in bug 3069. The most likely reason that you did not see this behavior before upgrading is that support for the MusicBrainz sort order tags was added after the last time you upgraded. Bug 5296 covers this enhancement. My recommendation is to either fix or delete those incorrect MUSICBRAINZ_SORTNAME tags from your files and then rescan your music library using the clear library and rescan everything option. I am inclined to mark this bug as works for me. I do wonder why MusicBrainz would tag those files with a sort order of Various Artists in the first place.
MB's tagging is entirely understandable. This album *is* by Various Artists. Tracks from it should sort together when sorted by album-artist. The problem is that they should not sort together when sorted by track-artist. And this is the problem - the SORTNAME (and probably TSOP) tags are being semantically overloaded. SORTNAME != ARTIST can mean at least a couple of things: * artists name is Foo Bar but sort under Bar Foo * artists name is Frank Smith but sort under his better known name of Bob Dole * artists name is Frank Smith but this track should sort under Various Artists What SC is doing it taking the (bad) SORTNAME/TSOP tag for one track, and using it as the sortname for every instance of the matching ARTIST, even when SORTNAME/TSOP is set correctly for those other tracks. Consider the following pairs: A=Foo, Bar SN=Bar Foo A=Bar Foo SN=Bar Foo A=Bar Foo SN=Various Artists A=Baz Bomb SN=Bar Foo A=Bar Foo SN=Foo Bar what should appear in the artist listing, and in what order? I would contend that it should be: Bar Foo Foo Bar Various Artists whereas SC's current behaviour is Foo Bar Bar Foo it could even be Foo Bar depending on discovery order. So, what should be done? I think its pretty simple (conceptually) * discover A, SN where SN != A new ARTIST entry A, sort by SN * discover A, SN Where SN == A => new ARTIST entry A, sort by SN/A * discover A, no SN => new ARTIST entry A, sort by A * discover A, SN matches existing ARTIST => new ARTIST entry A, sort by SN this would put "Steve Roach"/"Various Artists" into the
MB's tagging is entirely understandable. This album *is* by Various Artists. Tracks from it should sort together when sorted by album-artist. The problem is that they should not sort together when sorted by track-artist. And this is the problem - the SORTNAME (and probably TSOP) tags are being semantically overloaded. SORTNAME != ARTIST can mean at least a couple of things: * artists name is Foo Bar but sort under Bar Foo (Syntactic information) * artists name is Frank Smith but sort under his better known name of Bob Dole (Semantic information) * artists name is Frank Smith but this track should sort under Various Artists (potentially confusing semantic information) What SC is doing it taking the (bad) SORTNAME/TSOP tag for one track, and using it as the sortname for every instance of the matching ARTIST, even when SORTNAME/TSOP is set correctly for those other tracks. Consider the following pairs: A=Foo, Bar SN=Bar Foo A=Bar Foo SN=Bar Foo A=Bar Foo SN=Various Artists A=Baz Bomb SN=Bar Foo A=Bar Foo SN=Foo Bar what should appear in the artist listing, and in what order? I would contend that it should be: Bar Foo Foo Bar Various Artists whereas SC's current behaviour is Foo Bar Bar Foo it could even be Foo Bar depending on discovery order. So, what should be done? I think its pretty simple (conceptually) * discover A, SN where SN != A if (!known(A,SN)) { create new A,SN tuple * discover A, SN Where SN == A if (!known(A,SN)) { create new A,SN tuple * discover A, no SN if (!known(A)) { create new A,A tuple this would create two tuples for my bug report case: Steve Roach/Various Artists Steve Roach/Steve Roach when displaying the artist lists, which would consist of selecting unique SN from the tuples present, Steve Roach would thus appear. this is a bit unintuitive, but better than only appearing under the implicit sortname "Various Artists". You could also special case "Various Artists" and it synonyms to specifically avoid this case, leaving just other variants of this issue to be resolved in this way. A few years ago, i'd have written you an SQL table definition and/or query to implement this, but my brain is thankfully now full of real time audio programming and the DB stuff has moved to the corner :)
gah! comment #21 should be ignored. in comment #22, in the 2nd paragraph from the end, it should say "Steve Roach would thus appear TWICE in the list".
I did want to point out that according to the MusicBrainz tag spec at http://musicbrainz.org/doc/MusicBrainzTag is that MUSICBRAINZ_SORTNAME is for Artist sorting while MUSICBRAINZ_ALBUMARTISTSORTNAME is for Album Artist sorting. So I looked up one of the tracks in question using MusicBrainz Picard and here are the current tags: comments: 18 comment[0]: album=Slow Music for Fast Times (disc 1) comment[1]: albumartistsort=Various Artists comment[2]: musicbrainz_artistid=8347dd6d-b9a2-4e96-a610-d1ed67b189f1 comment[3]: title=Realm of Refraction comment[4]: compilation=1 comment[5]: artist=Steve Roach comment[6]: releasetype=compilation comment[7]: releasecountry=US comment[8]: musicbrainz_albumid=28bbd0fd-0a45-4bc4-88a2-28b19f1d679c comment[9]: releasestatus=official comment[10]: totaltracks=15 comment[11]: albumartist=Various Artists comment[12]: musicbrainz_albumartistid=89ad4ac3-39f7-470e-963a-56509c546377 comment[13]: catalognumber=HS11206 comment[14]: date=2001-03-27 comment[15]: tracknumber=2 comment[16]: artistsort=Roach, Steve comment[17]: musicbrainz_trackid=ccb2d315-c3fa-4af5-803d-285636d0ecf3
i am not sure if i understand correctly, but doesn't the distinction between albumartistsort and musicbrainz_sortname suggest that SC is using the wrong tag in this case? the artist should be listed using musicbrainz_sortname (Roach, Steve), not the albumartistsort (Various Artists). did i miss something?
Sorry Paul, your right, that was not very clear. What I was trying to do was point out that the files mentioned in comment #15 need to have the MUSICBRAINZ_SORTNAME tag updated to the correct metadata. Keep in mind that the MUSICBRAINZ_SORTNAME tag is equivalent to the artistsort tag and is only for describing the alpha numeric sort order of the corresponding artist. So for example: ARTIST=Steve Roach MUSICBRAINZ_SORTNAME=Various Artists should be: ARTIST=Steve Roach MUSICBRAINZ_SORTNAME=Roach, Steve or even: ARTIST=Steve Roach ARTISTSORT=Roach, Steve You also have the option of just removing the MUSICBRAINZ_SORTNAME tag all together. By the way SqueezeCenter does not currently support the ALBUMARTISTSORT tag but does support the ALBUMARTIST tag as covered in Bug 4584. I'm not sure where you got the tag MUSICBRAINZ_SORTNAME=Various Artists since that is not what is currently in the MusicBrainz database as I pointed out in comment #24. Perhaps it was updated since you wrote your tags?
Paul have you had a chance to update tags?
Reduce number of active targets for SC