Bugzilla – Bug 1812
Wrong Behavior when Jumping through the Song List with the Remote
Last modified: 2008-09-15 14:37:04 UTC
Sorting in "browse songs" is now perfect with the nightly build of July 12, 2005. But I noticed that jumping through the displayed song list is different than jumping through an album list or an artist list resulting from browse albums or browse artists. In album or artist lists I can jump to the first letter of the album's or artist's name by pressing the corresponding number key on the remote once or several times. In the song list pressing a number key jumps not to the starting letter of the first matching song but jumps to a position which is proportionally reflecting the pressed key. In the remote control reference it is described that in SORTED lists you press the number buttons to jump to the first item that starts with the corresponding letter. In UNSORTED lists (like playlists), you press the number buttons to jump proportionally through the list. Since the song list resulting from browse songs is (now) a SORTED list (once or multiple) pressing a key should jump to the first item starting with the corresponding letter (thus making it much easier to find a desired song).
I know it seems odd, but technically browse songs falls into the category of unsorted. If you look at a browse songs list from the web (new music, all songs), you will see that the list is headed by number, instead of letters. The find used to get the tracklist returns a sorted result, but the list output to the player/web is not sorted alphabetically. the docs are somewhat out of date (pre-6.0 in this case), as all finds have some type of sort. marking as an enhancement, becuase it will probably have to be an alpha sorted list at some point.
Did you use the nightly of July 12 (or later)? When I select "new music, all songs" the listed songs ARE sorted alphabetically by song title not by number. This is also true when I browse for Genre, Artist or Album and (finally) select "all songs" down in the hierarchy. Since I have set display formatting for titles to TITLE (ARTIST) I even see no numbers at all. But even when I change formatting for example to TRACKNUM. TITLE (ARTIST) the list is still sorted alphabetically by song title and not by track numbers. So it seems to me that the song list IS already an alphabetically sorted list and this is what Dean was confirming during the previous bug report [quote] ------- Additional Comments From dean@slimdevices.com 2005-07-11 10:28 ------- I believe that browsing songs when not in an Album context should be sorted alphabetically. Dan, is this a hard thing to do? [/quote] [quote] ------- Additional Comments From dean@slimdevices.com 2005-07-11 11:56 ------- if it's not filtered by album, then they should be in alphabetical order. [/quote] Does this change your mind that items from the song list should be selected according to their start letter? ;)
Yep, now that it's sorted, we should use alphabetical jumping with the buttons...
hmm, looks like this is actually dead easy. for sorting at track level BrowseDB, line585 changes to: if (($descend && !$search) || ($levels[$level] eq 'track' && !$search)) { This only fails in the case of track sorting by track number, which is only in album context. I could add a case for this, but I'm not sure if it is worth it given how likely it is that an album track list could wrap the page. To create the alphabar in the web, we simply add 'alphaPageBar' => 1, to the 'track' section of the %fieldInfo. This, too, might want to have an 'album' check, but its a bit trickier since the findCriteria isn't available there. We could directly check as a special case at the browsedb() level if needed.
deiter...my mind didn't need changing. sheesh
Created attachment 630 [details] sorrect sort order for track/album context should track teh right context in both player and web UI
Will that be in the next nightly build?
maybe. it will be noted here if it gets merged in, an anything in before midnight Pacific time makes it into the nightly build.
committed at change 3700, for July 14, nightly build this should now work as expected. please re-open if there are specific remaining issues.
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.