sort order for song is me.disc, me.tracknum, me.titlesort in the player IU

does that seem to fit what you are seeing?

That explains the order. I do not use DISC (what does this tag mean?), but I do use tracknumber. So in the browse songs list there are first listed all songs from A to Z which have no tracknumber, then all songs from A to Z which have tracknumber 1, then 2 and so on. For me that does not make any sense. When I want to browse by track the first sort criteria must be TITLE, otherwise I will never find a song with browse songs.

When I look e.g. for the song "Yesterday" I would go into browse songs and input an "Y" to jump to the first song starting wich "Y" and then scroll down to "Yesterday". That does not work at the moment since pressing "Y" jumps only to the first song starting with "Y" in the first SUBLIST. If "Yesterday" is in a later sublist (having e.g. a high tracknumber) I will never find it. At the moment "browse songs" is useless to me. 

Since my little son often uses "browse songs" instead of "search" (since he does often not know how to spell the song titles) I would it appreciate very much if the sort criteria could be changed to TITLE, ARTIST, ALBUM, TRACKNUMBER. With this order you will find any song, and if there are more versions they will be grouped to list first all versions of the same artist.

disc is a tag used for marking multi-disc sets.

(In reply to comment #3)
> disc is a tag used for marking multi-disc sets.
> 

Thanks, I didn't know that since I don't use it.

That means the actual browse songs list starts with all first CDs of a multi-disc set, therein first all tracks with tracknumber 1, and therein all songs from A-Z, then all tracks with tracknumber 2, and therein all songs from A-Z, and so on. Is that on purpose? I can't see any sense in this kind of sorting at all and in particular when I want to browse by songs.

Will that be changed or is there an option to change it? I assume I cannot simply change the code (if I would know where and how) if I use the precompiled Windows version.

I searched the forum and it seems that there were already previous bug reports regarding sorting when browsing by songs (bug 1797 and bug 2107). In both it was confirmed by Dean that the first sort criterion should be song title ("should be in alphabetical order") and a corresponding fix was filed. 

In bug 2107 the first sort criterion "song title" was confirmed but it was requested that the second, third and fourth sort criteria should be "album title, artist, tracknum". I would prefer "artist, album title, tracknum" but wouldn't mind the first version if at least the first sort criterion is song title.

Bug 1797 was fixed by using song title als first sort criterion but it seems that this has been changed in a later fix.

Bug 2107 was fixed using as sorting criteria "album title, disc, tracknum, song title" (I have no idea why, since in this bug a sort order of "song title, album title, artist, tracknum" was requested).

It seems that everybody agrees that song title should be the first sort criterion when browsing by songs. Maybe it has only be incorrectly implemented? 

Dean, it seems to me like 1) song title 2) album title 3) artist and 4) tracknum makes sense.  Reversing 2-3 might be a popular alternative, I suppose.

If you will give us a ruling I will put it in the spec.

I would prefer 1) song title 2) album title 3) artist and 4) tracknum sinc in this way I see all version of a song from the same artist grouped together. I have a lot of jazz standards so there are a lot of songs which are sung by different artists and even by the same artist in different versions. So having 2) artist and 3) album title would group all versions of a song by artists (and then by album) which makes more sense (to me) then grouping all versions of this song by album first and then by artist.

Oops, my last post started wrong. I would of course prefer 1) song title 2) artist 3) album title and 4) tracknum, otherwise different versions of the same song are not grouped by artist.

The more I think about the less makes 2) album title 3) artist sense. If you have several versions of a song sorting them in second level by album title would almost never lead to a specific grouping since it is very unlikely that these songs are on albums having the same album title. And even if there would exist some albums having the same album title (and same songs on it) grouping the albums for these songs together makes no sense since the albums with the same album titles are usually not related to each other. So grouping identical songs in the second level by artist seems for me to be the only senseful order.

Agreed: title, artist, album, track num seems like the best order when browsing by song. 

Just to be clear: when choosing to PLAY or ADD a genre, artist or album group of songs, the order should be the same as the browse order as a depth-first search, which is typically disk num, track num, album, artist, genre.

Great that you agree with the order for browsing by songs.

Only for completeness. I am not sure if I fully understand your second paragraph but shouldn't be album before track num, i.e. the order for PLAY or ADD a genre, artist or album group of songs be disk num, album, track num, artist, genre?

Further, is disk num the total number of disks of a multi disk set (i.e. 2 for a double CD) or is it 1 for the first and 2 for the second disk of a double CD?

Subject: Re:  Wrong sorting order in "browse songs" list at the player

Thanks, I was thinking backwards.  The point of the second paragraph  
is that the sorting of songs as they go into the playlist should be  
the same as you browse them (i.e.  If you add a whole artist, the  
songs should be sorted first by the album, then by the song number).

one possible method is to change line 68 of Slim/Schema/ResultSet/Track.pm to:
my $sort = shift || 'me.titlesort';

this means any track list not explicitly called with a sort argument will have simple title sort.  I'm not sure if a multi-hierarchy seach will work as easily, as many of those require complicated joins that make my head ache.

As a first solution for me sorting only by song titles would be sufficient. With song title sorting the "browse by songs" could at least again be used (at the moment it cannot). And I am not sure if there are so many identical song titles that it is worth to have a very complicated second, third ... level sorting hirarchy.

Doesn't the simple solution from kdf make it into 6.5.1? Having a sorting order by artists without further sorting hierarchy would at least lead to a correct track browsing list. At the moment the list is totally messed up, so not correcting this for 6.5.1 means keeping an unnecessary bug to me.

QA to see if a change for this ever got checked in

Ahm... did it get checked in?

I'll take a look. Has this been checked against 7.0?

Looks like the change didn't make it, I tested against SC7. I will test against 6.5.4 next, it's slow with a large library. 

Browsing songs goes through A-Z for all the track 1 songs, then A-Z for all the track 2 songs... sounds like the fix didn't make it. 

Behavior appears identical with 6.5.4

KDF: does this patch work on 7.0?  Is this risky?

patch should work, as it's just a change from the existing:
my $sort = shift || 'me.disc, me.tracknum, me.titlesort';

to:
my $sort = shift || 'me.titlesort';

There are only 3 callers to *->browse, one of which is upnp and thus disabled by default.  The others are search results and the resultSet base class.  For browsing, there is the $sortForLevel param which should cover the sort order in all cases.  The search results have no explicit sort and would make sense to have reported in title order for track results anyway. 

Andy: what do you think?

Applied as change 16437 - tested any browse song mode I could find. Couldn't find any side-effect.

Track sorting works now as expected. Thanks a lot!

This bug is being closed since it was resolved for a version which is now released!  Please download the new version of SqueezeCenter (formerly SlimServer) at http://www.slimdevices.com/su_downloads.html

If you are still seeing this bug, please re-open it and we will consider it for a future release.