>Since the web UI is the easiest place to set up (and, now that I
>understand the drag-and-drop in the new Default skin, rearrange the
>order), I think displaying the numbers in the web UI is useful, and
>therefore relevant.
>
The only possible relevant numbers are 1-10, as these map to keys on the remote.
What relevance would favorite number 11 have? You can't press digit 11 on the
remote.
A favorite can actually be a sub-folder containing other favorites. The
sub-folder will get a number; these are not playable as hotkeys from a
SqueezeBox remote.
I have favoruite #1 - Radio Stations, containing a hierarchy of radio stations:
1: Radio Stations
1: Electronic
1: Groove Salad | Ambient Beats and Grooves
1: Stillstream
1.1: DJ Sonix
1.2: Prog Rock
1.2: Aural Moon
1.2: Delicious Agony
1.2: ProgRock.com
1.3: Sport
1.3: Talk Sport
1.3: Radio 5 Live
The number hierarchy is really messy and wrong.
Why isn't sub-folder "Electronic" numbered 1.1, and "Stillstream" 1.1.2? The
numbers here are totally irrelevant anyway, because only the root item "1:
Radio Stations" is associated with the 1 key on the remote, which is not
playable. It is not possible to associate "Aural Moon" for example with a
remote hotkey.
>From a SqueezeBox, it is only possible to add a song as a favorite, not album,
>artist, year, so configuration of favorites really needs to be done from the
>WebUI.
Better in my opinion is to scrap the numbers from the webUI, and allow any
individual favorite item be associated with a hotkey number. I think they are
two separate things, and trying to combine them in an automatic way is always
going to be messy. Could have a separate screen for configuring remote
hotkeys, where you select a favorite item to be associated to a selected key.
>Start filing some bugs.
I was going to, but pointless doing that if functionality has just been added
due to a request. Better to get some feedback to collaboratively decide what
would be better first.
Favorites are definitely much better. They are now partially useful, in that
they support more than individual songs or radio station URLs.
You can now add eg. a favorite year. However, when you do that, you can't
browse to that year from the favorite in the web UI (all it says is
db:year.id=2007). All you can do is play all for that year in the web UI.
From the remote, pressing the hotkey for that favorite will play all for that
year, but it locks up softsqueeze (plays music, but remote becomes
unresponsive).
>Start at the VFD Now Playing screen, right arrow, and up arrow to "Go
>right to add to favorites" -- that should work.
That only adds an individual song. Not very useful.
>> I think it may be a little frustrating that every time the order of
>> favorites changes, the hotkeys for all following favorites changes.
>> eg. delete favorite #1, and favorite #2 becomes #1, etc.
>
>See the ticket listed above --
>http://bugs.slimdevices.com/show_bug.cgi?id=6929 -- adding a new
>favorite should not change the assignments of existing favorites. If
>you've got a test case that's not working as it should, please file a
>bug.
>
Adding a favorite will not change the numbers, but reordering favorites, moving
favorites into sub-folders, or deleting a favorite may cause all remote hotkey
numbers to change. That's not intelligent. I'd never use hotkeys on the
remote, as I wouldn't be confident that I was going to select the correct
thing, so I'd go to the list of favorites and play instead. Unless the hotkeys
are manually assigned/deassigned, there's a certain degree of randomness to the
process.
>My phone defaults to using the next available slot. Actually that does
>bring up a good point. If I have 5 favorites and delete the 3rd, it
>might be nice if, like my cell phone, that wouldn't affect favorites
>number 4 and 5. Feel like filing an enhancement request?
>
That's what I was getting at above.
Phil
_______________________________________________
beta mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/beta
