Bugzilla – Bug 17304
Composer and Band tags with non-ASCII characters slip in to Artist listing.
Last modified: 2012-01-27 10:24:01 UTC
In the SBS 7.6.0, approximately since build 32510 I have noticed that if a song/album has the tags BAND and/or COMPOSER (or the equivalent MP3 tags) and the tag value contains non-ASCII characters then the value of these tags appear in the Artist listing on the Web GUI of the SBS, IP3K players and SB Controller. One example is an album I have which is tagged like this: ALBUM: Requiem, op. 89, for Solo Voices, Chorus and Orchestra (CD 1) ALBUMSORT: Dvořák, Antonín-1985 ALLPICTURES: [ HASH(0x6e834b8) ] ARTIST: Antonín Dvořák ARTISTSORT: Dvořák, Antonín BAND: Czech Philharmonic Chorus and Orchestra COMPOSER: Antonín Dvořák CONDUCTOR: Wolfgang Sawallisch Normally this should have been sorted under D for Dvořák because of the ARTISTSORT tag, but as a result of the COMPOSER tag value "Antonín Dvořák" it appears under A in the artist listing. I have tested this and as soon as I remove the BAND/COMPOSER tags with the non-ASCII characters the value disappears from the artist listing. Please note that I have *not* checked the Composer or the Orchestra/Band check boxes on the "My Music" tab in the settings of SBS. I currently currently SBS 7.6.0 32656. By the way I was uncertain which component to choose, that is why I choose Misc. Johan
That person is going to appear in the artist list no matter what, since he's not just a COMPOSER tag, but also an ARTIST. Since there will only be a single record for Antonín Dvořák in the contributors table of the database, it sounds like the problem may be more a matter of the COMPOSER tag causing the namesort value in the contributors table to be overwritten.
Yes that is maybe a better way to describe what is happening.
More information in this thread: http://forums.slimdevices.com/showthread.php?t=90661
Confirming the bug: ALBUMARTIST="Daby Touré & Skip McDonald" ALBUMARTISTSORT="Touré, Daby, McDonald, Skip" ARTIST="Daby Touré" ARTIST="Skip McDonald" COMPOSER="Skip McDonald & Bim Sherman" Will break the sorting based on the ALBUMARTISTSORT tag. Not sure it's directly related to this one, but the COMPILATION tag also seems to break sorting for artists whose names contain non ASCII characters.
As of LMS 7.7.1, this bug is still not fixed. In my case, I have FLAC files with tags like the following: ALBUM: Favorite Chopin ALBUMARTIST: Frédéric Chopin;Vladimir Ashkenazy ALBUMARTISTSORT: Chopin, Frédéric;Ashkenazy, Vladimir ALLPICTURES: [ HASH(0x90177dc) ] ARTIST: Frédéric Chopin;Vladimir Ashkenazy ARTISTSORT: Chopin, Frédéric;Ashkenazy, Vladimir COMPOSER: Frédéric Chopin COMPOSERSORT: Chopin, Frédéric DATE: 1983 GENRE: Classical - Romantic;Classical ORGANIZATION: Decca TITLE: Ballade No. 3 in A Flat Major, Op.47 TRACKNUMBER: 1 VENDOR: reference libFLAC 1.2.1 20070917 It's my understanding that the ALBUMARTISTSORT and COMPOSERSORT tags are ignored by LMS, but I've filled them anyway -- one can always hope that in the future they will be. :-) The semicolon is set to be used as a separator character by LMS. In most cases, this kind of tagging produces what I want. For example, Vladimir Ashkenazy's name appears as "Vladimir Ashkenazy" but is alphabetized under A. But Chopin is alphabetized under F. The conditions that generate this error are complex. What is required: (1) Non-ASCII characters in the name. (2) Besides the ARTIST tag, the name also appears in the COMPOSER or CONDUCTOR tags. (I've heard that BAND will do it too, but I don't use BAND. I have not seen anyone else report that the CONDUCTOR tag will produce the behavior.) I have seen suggestions that the wrongly sorted artists have to appear on Compilation albums, but I can't confirm this. When I convert all albums for an artist to noncompilation albums, the problem is not removed. The conditions above are necessary to produce the problem, but they aren't sufficient: I have cases where the conditions are satisfied but the artist is sorted correctly. So there must be more to it, but I haven't been able to figure out what. But the problem is ubiquitous: in most cases where the above conditions are satisfied, the sorting is incorrect.
I now think some of what I posted in my previous comment is incorrect and also possibly misleading because of the superfluous tags I listed from a random file that exhibits the problem. I have since done some more systematic testing in an attempt to find a recipe for reproducing the problem. Here's what I found. To create a simple setup guaranteed to reproduce the problem, I created a "music collection" consisting of a single album in a single folder with two files. The track listings in LMS are: ALBUM: Most Beautiful Melodies ARTIST: Frédéric Chopin ARTISTSORT: Chopin, Frédéric COMPOSER: Frédéric Chopin TITLE: Berceuse (Lullaby) in D Flat Major, Op. 57 TRACKNUMBER: 4 VENDOR: reference libFLAC 1.2.1 20070917 ALBUM: Most Beautiful Melodies ARTIST: Edward Elgar ARTISTSORT: Elgar, Edward COMPOSER: Edward Elgar TITLE: Enigma Variations, Op. 36: Variation IX ("Nimrod") TRACKNUMBER: 13 VENDOR: reference libFLAC 1.2.1 20070917 (The VENDOR tags aren't mine, and Mp3Tag doesn't show them.) If these tracks were sorted in accordance with the ARTISTSORT tags, they would appear in the LMS Web interface (or in the Duet Controller, etc.) Artists listing as: Frédéric Chopin Edward Elgar But they don't. They're listed in the opposite order, like so: Edward Elgar Frédéric Chopin That's the basic problem. I believe anyone should get this behavior from LMS using files with the tags I've shown. If you don't, let me know and we can compare notes. Further points: I found that I could get the correct sort order listing either by deleting COMPOSER altogether or by removing the nonASCII characters from the value; i.e., by putting "Frederic Chopin" in the COMPOSER tag. I also found all the same results using the CONDUCTOR tag instead of the COMPOSER tag. That is, with COMPOSER deleted, CONDUCTOR = Frédéric Chopin produces the wrong sort order but CONDUCTOR = Frederic Chopin produces the right sort order. But one thing I could NOT get to work was replacing the nonASCII characters in ARTISTSORT. That is, with ARTIST = Frédéric Chopin, COMPOSER = Frédéric Chopin, and ARTISTSORT = Chopin, Frederic, the sort order remains incorrect. This contradicts what I said previously. I thought I had tested this on other files a few days ago, but perhaps not. This is too bad, because it means that the potential workaround of having nonASCII characters in ARTIST but removing them from ARTISTSORT won't work.
I think maybe this bug is what is affecting me as well. My guess is that certain combinations of characters makes the server ignore the ARTISTSORT-tag. In my collection: ARTIST "Niels-Henning Ørsted Pedersen" ARTISTSORT "Pedersen, Niels-Henning Ørsted" is sorted under N. ARTIST "Niels-Henning Orsted Pedersen" ARTISTSORT "Pedersen, Niels-Henning Orsted" is sorted correctly under P. ARTIST "Niels Henning Ørsted Pedersen" ARTISTSORT "Pedersen, Niels Henning Ørsted" is sorted correctly under P. It seems that removing either the hyphen or the letter Ø makes the server read the tags correctly.
(In reply to comment #7) > I think maybe this bug is what is affecting me as well. My guess is that > certain combinations of characters makes the server ignore the ARTISTSORT-tag. > In my collection: > > ARTIST "Niels-Henning Ørsted Pedersen" > ARTISTSORT "Pedersen, Niels-Henning Ørsted" > is sorted under N. > > ARTIST "Niels-Henning Orsted Pedersen" > ARTISTSORT "Pedersen, Niels-Henning Orsted" > is sorted correctly under P. > > ARTIST "Niels Henning Ørsted Pedersen" > ARTISTSORT "Pedersen, Niels Henning Ørsted" > is sorted correctly under P. > > It seems that removing either the hyphen or the letter Ø makes the server read > the tags correctly. Yes, I would guess that it is the same bug. With a large collection of music, the behavior is inconsistent and hard to reliably reproduce. For example, in my own system, Antonín Dvořák is sorted correctly, although that name has all the same tagging conditions (as far as I can tell) as names that are sorted incorrectly. I have still not been able to isolate the exact conditions that produce the incorrect sorting. But I believe that the simplified set of music files I presented above should produce the problem for anybody and at least demonstrates the reality of the bug.