Bugzilla – Bug 509
More consistent behaviour of 'Play' button; particularly when using "jumpback on wake"
Last modified: 2011-11-06 23:25:20 UTC
This enhancement is related to the same annoyance that spawned https://bugs-archive.lyrion.org/show_bug.cgi?id=507 . Now 507 serves other purposes but the same IMHO slightly inconsistent behaviour of the 'play' button is one of the major causes. All of the other, what you could call actions on the currently playing playlist, do the same thing whether you are on "Now Playing" or somewhere else. To wit: 'skip fwd', 'skip rev', 'pause', and 'stop'. 'Play' is the exception. If you are in "Now Playing" then it plays the current song if you are stopped. If you are browsing material it replaces the current playlist and starts playing that selection. This is particularly problematic with "jumpback on wake" enabled. If you pause or stop then hit play again you often end up nuking your playlist. Now one quick hack to at least mitigate the "jumpback on wake" effect would be to ignore the first press that wakes up the display. At least then the user has a chance to realize that he has done something wrong. Another obvious option is a confirmation dialog; basically the bug 507 but all the time when you are going to replace a current playlist. This could also be coupled with my final, and favorite, selection below. Probably the best solution would be for a press of 'play' to always act on the current playlist no matter where you are. If you wish to replace the current playlist and start playing your new selection immediatly you can press and hold 'play'. This would lead to a more consistenr behaviour as compared to the other buttons that action on the currently playing playlist and also be quire similar to the way pause and ff/rew have multiple uses if held.
The 'jump back on wake' issue is perhaps a simple mapping problem. default screensaver mappings have most functions simply mapped to 'done'. However, stop, pause, fwd and rew have an added passback which resends that button to the mode after jump back. mapping all keys to 'done' should avoid this one problem.
I assume that the "Play" button is on that list (stop, pause, fwd and rew) too which causes the problem. If so then setting all to done would solve it as well. Of course I still think I like idea of "Play" being added to that univeral action list of stop, pause, fwd and rew. The very fact that it has this passback and resend suggest an initial intention of having it behave universally as play on the current playlist. Of course it would probably be relatively simple to have a preference selecting either mode of behaviour (ie. current with the 'done' fix or new with play always restarting playback of current playlist and held play, with a confirmation, replacing the playlist).
if you look at Default map, you can see the fucntions for each button. Play shouldn't cause anything but a 'done' function. Perhaps the server is getting a repeat code and thinking its a single button. Still, this can all be tested by setting the entire range of buttons to 'done' in the screensaver section of the Default map, should anyone have the time in the near term to test that theory :)
OK looking at default.map "play" does indeed = done in the screen saver section. On a hunch I put: "play.* = done" instead but it did not seem to help. I still think, though, that the slimserver function play should behave like the "stop", "pause", etc. The existing play function could probably be split into play_current and play_replace (and possibly even play_add that starts playing the selection but does it by adding to the list and then immediatly starting to play it) and then everyone could chose what they want in the .map file. The existing behaviour could remain the default while anyone who want it different can edit the file. I still think that the play_replace that nukes your current playlist should have a confirmation (or at the very least the warning suggested in 507 if the new playlist is really large). If play_add existed it could be a choice; replace and play, add and play, or cancel. I know serveral times I have hit play and accidentally killed a playlist I would have rather kept listening to after hearing the selection.
Routine bug db maintenance; removing old versions which cause confusion. I apologize for the inconvenience.
Dean doesn't work here any more :)
Unassigned bugs cannot have a priority.