Bugzilla – Bug 2583
Multi-disc tracks improperly sort in the server/browse pane
Last modified: 2008-09-15 14:37:04 UTC
For a work such as an opera wher there are multiple discs for the work, slimserver makes good use of the multi-disc tag (e.g., 1/4 for the 1st disc of 4) and gives a track number such as "1-4" or 3-2" meaning 4th track of disc 1, and 2nd track of disc 3, such that the tracks are are properly sorted on the right hand or player pane; however, the tracks do NOT get sorted properly on the left hand browse/server pane.
Created attachment 1018 [details] screen shot Here is a screen shot of what I am talking about
I notice another problem which is shown in the attached screen shot. Note that on the left/server pane it says "1 album with 30 songs by 2 artists". It should say "1 album with 30 songs by 1 artist". I guarantee you that there is only one artist used in the tags for all 30 tracks (as can be seen on the player pane). Also for any album that is housed on only 1 disc this "1 album with 30 songs by 2 artists" stmt is correct in that it either says "1 artist" or "13 artists" or whatever the correct number of artists is; however, for multi-disc works the "1 album with 30 songs by 2 artists" stmt *ALWAYS* says "2 artists". I've checked this on 7 or 8 different multi-disc works, and it always says "2 artists" even tho the tags for all tracks all all discs only have 1 artist.
seems that DBI::Album line 28 is the problem here. i think it should be: $class->has_many(tracks => 'Slim::DataStores::DBI::Track', { order_by => 'multialbumsortkey'}); i've tried this with 6.5, but I'm not sure what the implications are for changing the order here with other aspects of the datastore. This probably needs to go through Dan.
As the reporter of this bug, I'd like to remove my additional comment regarding mult-disc works showing 2 artists instead of 1 artist in the browse/server pane. Altho a problem DOES exist in this area, it is unrelated to this bug #2583 reported here (i.e., sort order of tracks in the browse/server pane). I included the 2 artist vs 1 artist info only because the attached screen shot displayed the problem. I wish I hadn't done that but instead reported the 1 vs 2 artist situatiion on a separate bug report (which I will now do). I now have additional info in the 1 vs 2 artist bug which may either help with its fix, or allow me to find that it has already been reported.
That may explain why I was not seeing it, nor was I attempting to fix that part. Thanks for the note. Please feel free to file the information you have as a new bug.
Ok, I have put the sorting fix into 6.5b1 at change 5235, for Nov 18 build. Dan, let me know if this can go into 6.2.2 at any point.
Yes - it should go in the 6.2 branch
committed at change 5250
There are 536 bugs in the database with targets of '---' that were fixed prior to new year 2006. I am setting them to targets of 6.2.1 to keep them from showing up in my queries.