Bugzilla – Bug 2144
Incorrect sorting for tracks with DISCNUMBER tags
Last modified: 2008-09-15 14:36:01 UTC
I treat multi-disk albums as a single album in Slimserver. I have a 12 disk album that uses the DISCNUMBER tag. I have found that when I browse the album, the tracks are not listed in "disk num, track num" order. Tracks are ordered correctly within each disk, but the disk order isn't correct. I believe there are problems due to use of 2-digit disk numbersm and perhaps use/non-use of leading 0's. Most of the time I have put leading 0's in the the disk numbers. Where I haven't, the order goes wrong. It would be better if SlimServer interpretted the disk number as a number for sorting purposes. Also, some of my multi-disk albums use a tag called PARTINSET instead of DISCNUMBER. Slimserver doesn't seem to currently support this (although I am sure this tag used to work). Nb, my DISCNUMBER PARTINSET tags also contain the total number of disks, eg. DISCNUMBER="2/12". Is this the standard way of tagging, or should I be using a different tag for the total number? Most tag editors seem to use this technique for TRACK="n/n" and either DISCNUMBER="n/n" or PARTINSET="n/n" as far as I can tell.
How are you browsing the album? Could you send a file with the PARTINSET tag? Thanks.
As of todays nightly (SlimServer_v2005-09-19.exe), and following a complete rescan, I am now seeing albums tagged with PARTINSET being handled correctly. I am browsing the albums with PARTINSET tags by selecting "Browse Artists", selecting an artist, and then selecting an album that contains tracks over several disks. For albums that have several disks, with tracks tagged with eg. PARTINSET="01/03", I was seeing all track 1's, then all track 2's, etc. I now see all disk 1 tracks, then disk 2, etc, which is the same as if they were tagged with DISCNUMBER="01/03". One thing that would be really useful though, is to display the disk number in the track information (ie. in the web interface, when clicking on a track title, or from a Squeezebox when drilling down into tag info). Also, display formatting doesn't seem to work. Although I have my display format set to "DISC-TRACKNUMBER. TITLE", I never see disk numbers in the display. Is this because it only works if "DISC" tag is used? If I change the display format to "DISCNUMBER-TRACKNUMBER. TITLE" I actually see "DISCNUMBER" as a word in the format, ie. it doesn't understand it as a tag. Am I right in thinking that scanning should understand either DISC, DISCNUMBER or PARTINSET and store this in the DB as the discnumber, and therefore "DISC" in the title format should work for any of those tag aliases that are used? The windows "Audio Shell Tag Editor" seems to support both DISCNUMBER and PARTINSET tags. www.softpointer.com/AudioShell.htm.
Philip - I assume by PARTINSET you are referring to the TPOS ID3 tag, which we do handle. It gets turned into DISC & DISCC internally. Try removing the - in your format. I've checked in subversion change 4424 which strips leading 0s from the DISC / DISCC values. Please open another bug if the format issues need one.. Thanks.
I use ID3-TagIt, which provides entry boxes "Position in media set: n / n". I also use Mp3tag, which doesn't directly support any specific disc number tag. However, it does allow any Metadata name/value pair to be viewed/updated. After entering the position in media set info using ID3- TagIt, and looking at the tag info using Mp3tag, I can see that it stores "PARTINSET = 01/06". I can't see any meta tag called "TPOS", so no I believe PARTINSET is another tag variation. I tried removing the "-" from my display format, but it still doesn't display the disc number anywhere in the web UI (fishbone skin) or on the squeezebox. I have raised bug 2242.