Bugzilla – Bug 13248
Change presets to be per-player, separate from favorites
Last modified: 2009-10-05 14:29:08 UTC
* Every player gets an initially-empty 10-item list of presets specific only to that player. * Preset buttons on Boom access items 1-6 of this list, IR remotes can access all 10. * The only UI for setting and triggering presets is the device (buttons or remote). Existing SC web UI for presets will be removed. * The current favorites structure remains as-is and is still global to all players. * Presets should be synced with SN. * If SN can't play a preset (i.e. local file, Alien), display an error When migrating from current versions where presets are global and point to favorites: * Existing presets are copied from the global favorites system to all players' individual preset lists. Each preset item stores: * title * URL * type * parser, if any * server UUID (if local content) One UI issue to solve: how to set a preset with IR. I think we'll need a menu when holding a number that lets you choose to play the existing preset or set a new one.
> * If SN can't play a preset (i.e. local file, Alien), display an error Andy, any guidance/thoughts on what could conceivably be contained in this error message? Idea would be to display something like "sorry, we can't access this preset. this preset was added from another library." with options to "switch library" or "cancel?"
No options!! Just an error.
(In reply to comment #2) > No options!! Just an error. Because of the time it would take to build, or because our system isn't smart enough? I'm not trying to knock the proposal, but this is a huge blind spot in the design. People are going to press SC-based presets while connected to SN, I think it will happen quite a lot actually (especially now that we're taking away the user's choice of which service they are connected to, which will make the frequency of the error feel very random). I know time is very limited and auto-syncing would be complicated, so I understand that this work has to wait. But at the very least we need an intelligent error message. In this case we know exactly why the error is happening and what the user could do about it. I'm just pushing for the best short-term help we can give to the user here, balancing that of course against time/development constraints. Would it really be that hard to have an error message with two menu options?
For ip3k it is currently impossible to give the user that option. Perhaps SP could be smart enough and auto-switch.
Ah good point about ip3k. Anyways, would be nice to chat with you in a day or two about constraints surrounding this error messaging when the time comes.
Sounds good, but for the alien/bbc parser presets I think there will be an issue of how you set the preset so that it has the correct url and parser if it does not use the web interface. It probably works today if we bookmark the current xmlbrowser node in SP as it does for the web interface? I would definately want to be able to bookmark favorite radio stations though so we would need a solution to this.
== Auto-comment from SVN commit #7016 to the network repo by andy == == https://svn.slimdevices.com/network?view=revision&revision=7016 == Bug 13248, Some fixes needed for array prefs that contain hashes (for presets)
== Auto-comment from SVN commit #28189 to the slim repo by andy == == https://svn.slimdevices.com/slim?view=revision&revision=28189 == Bug 13248, move presets to be a per-player pref and not part of favorites. Still TODO: sync with SN, errors if trying to playback something that was set on a different server, CLI commands(?)
There are definitely pros and cons to doing this. It's more flexible, but for a single guy like myself with multiple Squeezeboxes in the house, I'd probably want the same presets on all devices. Also, managing them using the web interface for Favorites is much easier. If a radio URL changes, I can currently make the change in just one place. With this change I'd have to change the URL in the favorite, pull up the favorite and preset it again on all players.
Andy, would you consider storing these as N separate preferences per player instead of one preference ("presets") that contains an array of presets? Jim, I'd want all my players to have the same presets, too. My SettingsManager plugin should let you do that if you link the "presets" preferences of multiple players. Change the presets on one player, and SettingsManager would copy all of that player's presets to any other player with which you have linked the "presets" preference. As long as changing a pref on Boom doesn't blow away presets 7-10, this should work pretty well. If the presets were stored as 6-10 different preferences ("presets0", "presets1", etc.), then users could choose to link all presets, or only specific presets. And there would be no risk of Boom code being "too smart" and clobbering the last 4 presets for folks linking player presets with SettingsManager. Changing to N different pref values should involve very little code, changing lines like my $preset = $prefs->client($client)->get('presets')->[ $digit - 1 ]; to my $preset = $prefs->client($client)->get('presets'.($digit - 1)); and better to do that sooner than later, so you don't have to worry about migrating from the "presets" array to "presetsN" model. :-)
Sorry, no, it's one pref.
Andy - I think the new presets are broken on non boom ip3k players... The IR mapping for press and hold 0-9 will play a preset, but there is no UI to allow them to be set? At present the button mode info menus save entries to favorites not the presets.
Yep that is one of the drawbacks of the new design. There was never an IR UI for setting presets so you always had to go to the web UI to do it. I think the right solution is a context menu that appears when you hold a number that lets you choose to set a new preset or play the current one. It would be great if you or someone else wanted to work on this!
Does this mean that _no_ web management of presets is planned?
Presets right now are a device-only operation, so on Boom you set and use presets only from the preset buttons, which is how people expect them to work. An IR UI for presets would be fine, but we've never had one. A web UI for presets could be added but I'm not sure how it would look. Note that presets are separate from favorites, so you can't put a presets UI in the favorites UI.
(In reply to comment #15) > A web UI for presets could be added but I'm not sure how it would > look. Note that presets> are separate from favorites, so you can't > put a presets UI in the favorites UI. Got that. You'd use much the same UI, but I suppose it would have to be in Player Settings. A copy capability could also be placed there, so you could easily copy the presets from another player, and perhaps give the ability to copy them from Favorites. That could help alleviate the complaints that you will get about separating these from Favorites. Low priority, I realize.
What I am going to propose for the moment is a simple UI using the existing press and hold of number buttons on the IR. When hold triggers it will show "Preset #1 (Hold to store)" or something similar and if you release the button then it plays the preset, if you hold for 2 more seconds or something then it stores it. This means there is no menu UI as I think people like me will be used to pressing and holding the button for a short time to play a preset so I want to retain this. Are we still ok to add new strings to 7.4?
> What I am going to propose for the moment is a simple UI using the > existing press and hold of number buttons on the IR. Isn't this the way it is now? > Are we still ok to add new strings to 7.4? Hmm... not really. Feel free to add them if needed. We'll probably translate DE/FR ourselves. This would cover most of our market. Thanks!
== Auto-comment from SVN commit #28372 to the slim repo by adrian == == https://svn.slimdevices.com/slim?view=revision&revision=28372 == Bug: 13248 Description: add ability to set player presets for ir based players. Press and hold for a really long time = save, press and hold for a shorter time = play preset
Michael - this issue was we used to have press and hold = play, but there was no way to actually set the new style presets as the old mechanism relied on favorites. I've added press and hold for a really long time = save. Press and hold will still play the preset as long as you release in less than 3.9 seconds. There are two new strings - please could you localise as appropriate...
Thanks!
> There are two new strings - please could you localise as appropriate... Heh... just realised the other Preset strings aren't available in DE/FR et al. neither. Will see what I can do once I get the second pass of translations back. Thanks!
== Auto-comment from SVN commit #7183 to the network repo by andy == == https://svn.slimdevices.com/network?view=revision&revision=7183 == Bug 13248, sync presets with SN
Another hole that I see with things at the moment is that there's no way to see what presets have been configured. eg, which preset buttons are empty. I know you don't worry too much about third-party plugins, but this change breaks several, so expect some backlash from users of Classic players. eg. TrackStat plugin uses IR 1-5 buttons to set ratings when held on an item, so at the moment when trying to rate a track it can invoke a preset instead. I'm wondering if presets are actually used much for SB2/3 players, seeing that favorites are available fairly easily through the remote. Perhaps presets should just be for hard buttons on Boom/Radio front panel, as it's too confusing with different length of press-and-hold doing different actions? Or make a "Presets" plugin for SB2/3 classic players, so people that might want to use this can install, but most users wouldn't need and would save some memory by disabling the plugin.
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server! * SqueezeCenter: 28672 * Squeezebox 2 and 3: 130 * Transporter: 80 * Receiver: 65 * Boom: 50 * Controller: 7790 * Radio: 7790 Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.