This will need the updated version of favorites that stores the hotkey on the opml file - let me add this to 7.1 so people can try it out and then we can use it for Boom.

I was thinking that the first 6 favorites would map directly without specific hotkeys

Problem is that they could be folders in the opml structure not individual favorites - I've got the code done for storing hotkeys, its the ui which needs a bit of thinking about.  Let me add it to 6.1 and then we can integrate it here.

Ok.  Is it possible for the hotkeys to default to the first 6 items in favorites?

Its definately possible to default things - bug 7292 has the current state of discussion on it + the patch I want to commit.

What I was thinking was new favorites are added to the end of the opml list.  If they are added via the player interface then we assign a hot key to them which is the button used on boom or the next available otherwise.  If added via the web interface there is a drop down list to set the hot key which can then be used to edit them.

The complexity comes from there being two sets of uses for favorites now - as a hierachical list of urls and as a set of urls mapped to specific keys.  The plan was to maintain the ordering as a hierachical opml file, but allow any entry to be flagged as a hotkey and assign it to a button.

added initial support for this in change 18478

This should act as a radio - setting a favorite if you press and hold the button and play it if you just press it quickly.

I've not added support for defaulting the first 6 entries yet as I wanted some feedback on it first - will be trivial to add though.

This should also default to the first 6 entries now too.

I don't understand... First six favorites entries or first six favorites numbered hot keys?  I'd _greatly_ prefer the latter.  It's very confusing otherwise.

My favorites right now (all Slacker stations):

Classic Jazz [1]
Comedy [Explicity] [5]
Vocal Standards [2]

When I press button #2 I get Vocal Standards, and when I press button #3 I get the same thing.  Which is odd.  If I delete that favorite, then I get Comedy on both buttons #2 and #5.

What happens if you have, say, 20 favorites, but no hot keys designated, then you set one with the Boom button #1?  Does it get inserted into position 1?  (I would hope so, rather than overwriting the favorite that was previously in position 1).  But that would shift all the others down one, thereby reassigning buttons 2-6 on the Boom.  Not good.

I think you should keep it simple and just tie the buttons to the numbered hot keys.  I think it's fine to "take" a hotkey away from another favorite by using the press/hold on the Boom.

Any chance of getting a 'beep' from the Boom, as I get from my car stereo when I set a radio preset?

So at present it each button maps to the entry with the matching hotkey defined.  The added bit is that if there is no matching hotkey defined it will fallback to the entry at that index in the favorites list - this is the addition Dean asked for.

I'm not sure about this myself as it gives the effect you are seeing that two buttons can map to the same thing.  I think it may be better to just say that the hotkey is not defined.  Given that we will always assign a hotkey if you use the front panel buttons to set a favorite I think this exactly matches what a car radio would do.

[It's a one line change to remove the fallback if we don't want it...]

Dean, that's an interesting suggestion (mimicking car radio presets even more then before!), but I think I'd rather have the front panel buttons behave more like those on the "big" IR remote control, where a short press helps navigate a list and a long, more deliberate press is required to play a favorite. 

In this "more consistent" approach I'm advocating, pressing a button briefly would advance you to N/6 of the way through the INPUT.list options and holding a button would play that numbered favorite. This isn't 100% consistent with the big IR remote, but without A-Z lettering on the Boom controls (4 or 5 letters per button?), it's as close as I think you can get. (I think you probably could make the buttons look nice and add letters, but I don't know if that presents localization problems... )

I know I'm probably not a typical user, but as someone who's used Squeezeboxes for years, I expect to use a "big" remote most of the time with my Boom, and I'd prefer the front panel buttons' behavior to match the big remote more closely.

And in this case, mimicking the old IR behavior makes it less likely for SC7 to do the wrong thing -- requiring a .hold to change the playlist makes it less likely that a user would trash a playlist accidentally; requiring a more deliberate set of actions to map a URL to a Favorites number makes it less likely that a user would munge their Favorites  number mappings. To use the car radio analogy, I remember re-mapping the old analog preset buttons (push to tune, pull to set), but only when we'd driven to another city on vacation. Those buttons were pushed hundreds of times more than they were pulled. And there is no real "location" for a Boom -- they're all online. I'm just as likely to listen to a French radio station in  Paris, TX as in Paris, France. 

Another suggestion that's mostly based on the current "big IR" remote control behavior:
 - press and hold button N to play favorite number N
 - briefly press button N and the Boom display shows the name of favorite number N
   - after the brief press, pressing N again or Play or the knob will play that favorite

Why? I was thinking about how the Boom might be a good gift for a relative, but would need to be quite simple to use. Allowing users to "look at" their favorites by briefly presing a fave button on the Boom would make the device more usable for her. More usable for me, too. Since recreating my favorites after upgrading to SC7, I no longer remember my favorite button mappings. It's too easy just to press the Favorites button and scroll (and Home > Favorites > scroll is the only choice with the SBC). 

On the topic of making it harder for Boom users to mess up their current playlist of favorites number mappings, I was thinking of a number of threads in the forums about "party mode" behavior and new users' confusion about how the Play button can so easily wipe out a playlist. Requiring holding the button or pressing it again or pressing a second button would not only be more consistent with SB3 but also reduce user frustration.

I think that default behavior should be simple and intuitive for folks.  

The instructions should be like this:

When you see something on the screen that you want to be able to play later, press and hold one of the numbered buttons to save it.   Tap that button again to play that item later.

Now, if folks want to use the web UI to go in and manage their favorites, create folders, renumber their favorites, that's great and we should give them that power.  But the simple case of saving a favorite and then playing it back later should "just work".

So your description of the default Dean is what happens now - I assume it is working for you?

Yes, sorry, I was just trying to clarify for Peter...

I'm going to mark this closed.  Peter, please feel free to open another bug/thread to track improvements.

So the behavior mentioned in #8 is going to stay just as confusing as it is now?

Preset will only play if the type is "audio" in the OPML. This prevent playlist being played as a preset.

If when listening to an item (e.g. a BBC Listen Again) which is not type "audio", you press a preset to save the URL, the entry will be saved correctly.  But with the "Listen Again"  example you cannot play the program again just by pressing the preset as the saved type is "playlist".  

There may be other associated in Favorites as the created preset entry is not shown as playable in  Favorites but can be played by drilling down on the entry.






       

Bryan - please try change 19848.

This should play alien entries via the button interface.  It should also show correct entries on the web interface, but they don't play directly in Default skin  (do in Classsic).  I believe this is a javascript problem.

Button interface now works OK but I'll do more testing. Also Web interface seems to be OK now as well. 
You also fixed an associated issue that different favorite URLs were saved when using button press and when saved by Going Right on a playing item and then selecting save as Favorites. 

The press and hold a preset button to save as a Favorites no longer works - at least when playing an streaming URL.

I am testing with new-streaming but I think it also failed before I swithed to new-streaming.

Has this functionality been removed or is just broken ?  

Broken...  I'd like to understand whether NS is here to stay before fixing though.