Bugzilla – Bug 8936
Sort favorites in alarm playlist selection
Last modified: 2009-07-31 10:26:10 UTC
The favorites in the "choose playlist" alarm setup are sorted alphabetically. IMO, they should be sorted in the same order as they appear under "favorites".
Player or web interface? Both?
(In reply to comment #1) > Player or web interface? Both? > Both.
I should add that I haven't tested this with any favorites folders, but I think the alarm webUI and playerUI should honor both the order and hierarchy of the user's favorites.
The alarm code uses a hash to build that list, so it gets sorted.
This also now applies to the SBCUI.
I'm working on this this weekend. The favourites hierarchy won't get displayed by this being fixed, but I'll be able to make it so that playlists are displayed in the order desired by the caller that registers them.
I've reworked things in change 22330. This now preserves the sort order for playlists. The return type for getPlaylists has changed, which will break the new controller ui. I've made the necessary changes to the web ui. See docs in Slim::Utils::Alarm::getPlaylists. This change does not fix this bug yet, as $favsObject->all does not actually return the favourites in the right order. It currently uses a hash internally and so throws away the order. I didn't want to change this as I don't know it well enough to understand any implications. However, I suspect the needed changes are minor, so it would be nice to get this in for 7.2, especially now I've done the hard work...
Max - I'll look at tomorrow evening, should be simple to keep the favorites order, but it will need to flatten the favorite hierachy - at present I think I recurse depth first does this sound ok?
or maybe today - favs is updated in change 22332. The reason for not putting an alarmFavorites function in the favorites code is that I hope the $favs->all method is useful to more functions than just the alarm code. I note there is still a $favs->all call in SN which returns an array - I'll leave Andy to see whether this needs to be updated for alarms.
Andy thinks this is done in SC, and he needs to do it for SN.
Controller UI fixed for change in the Alarm::getPlaylist data structure, Boom branch change 22357
SN fixed in change 22358.
looks like a bunch of fixed 7.2 bugs were erroneously changed to target milestone of '---'. Changing them back, as they should appear in searches as to where they were fixed.
Verified to be fixed in 7.2.1 - 23472, r3080.
This bug has been fixed in the 7.3.0 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
Reduce number of active targets for SC