Bugzilla – Bug 11376
Using the play button to go right is wrong
Last modified: 2009-10-05 14:37:13 UTC
I don't like that the play button is being used for navigation now. I should be able to pick up the Controller and start the music by pressing the play button without looking at the screen or caring where in the menu structure I am. Consider this scenario: Last thing I do at night is put the player into sleep mode, then cradle the Controller. In the morning, I wake up and press play on my way to the bathroom without looking at the screen. Instead of playing, the sleep mode is enabled because that's the screen I left it on. Now I have to pick up the controller, cancel sleep, navigate to the NP screen, and then press play. This is wrong. The play button should always start playback.
I suppose this only applies when the player being controlled is in the "off" or "paused" state.
Dean wanted this some time ago, but in retrospect it does seem insane.
+1
(In reply to comment #3) > +1 Use the vote button above
Moving to the product SqueezePlay because this bug appears to apply to any player based on that application code. Feel free to move it back if it's specific to the original product.
Yes, we should make this change. Tom, can you think of any functionality that might break if we make this switch (in terms of navigation on obscure screens etc)? If not, do it ASAP.
I just wanted to note that this behavior is not limited to SqueezePlay based players but ip3k as well when using the ir remote.
Oh, and the front panel controls on Boom.
Yes, thanks for adding that, Steven. I lost a playlist due to this behavior on the Boom more than once.
*** Bug 11963 has been marked as a duplicate of this bug. ***
If something is playable then PLAY should play it. Are there some situations where there's no RIGHT control available, so that PLAY has to become RIGHT?
On the surface there doesn't seem to be any such situations, but if there are situations where no Right control is available, they need to be addressed separately, not by modifying "Play" behavior. Consider: if you pause the currently playing track, you need to be able to "Play" it again. If "Play" gets hijacked due to some corner-case, you'll be stuck with no music and be forced to nav-back anyway to get the music to play again.
(In reply to comment #11) > If something is playable then PLAY should play it. Are there some situations > where there's no RIGHT control available, so that PLAY has to become RIGHT? It's not quite that simple. First, let me state that I generally agree with everyone - having play NOT play something, when it conceivably could, simply sucks. The current implementation happened before I was at Logitech, so I'm just trying to get some background on what the original thinking was. AFAIK it was related to controller, and the fact that people were having trouble with the center button. It was probably a poor decision to have "play" be at the top right of the main navigation control :-). So it was decided to make "play" the equivalent of "right" / "center button" in some cases. So I think we can kill the play control as a navigation shortcut, unless some new info comes along specific to the controller that I wasn't aware of. -------- The REAL problem: what does the "play" button do if I started playing "thing A" 30 minutes ago, then navigate to another app or something, pause "thing A," then select "thing B" and press play? Which item should play? Should "thing A" resume playback, or should "thing B" start playing instead? If both "things" are songs under my music, it's not too bad of a problem. But what if "thing A" was an internet radio station, and "thing B" is a genre type under "My Music?" It starts getting a little weird when you incorporate ANY possible playable item into the discussion. One of the challenges is that we have separate play and pause controls (if music is paused on item A and I hit "play" on item B, am I unpausing item A or playing item B?). Another challenge is that navigation is treated separately from transport controls in our design, even though the same buttons get re-used for certain things. (The iphone, for example, doesn't have this problem, since transport controls only appear on the actual now playing screen. You can't hit "play" while selecting an album, for example. You're either navigating OR using a transport control, never both). I want to get this right for our users, but the needed behavior is not as obvious as it looks.
Matthew, on comment #12, I'm not saying it's intuitive, but what you say in that comment is wrong. Pause button is actually a Play/Pause toggle key and it is dedicated to that function. You can always turn the music on by pressing pause when stuff is paused. It works that way on all of our devices, as well as devices made by other vendors. Again, not trying to say it's intuitive, but it's not as catastrophic as "no way to play music when on item X"
(In reply to comment #14) > Matthew, on comment #12, I'm not saying it's intuitive, but what you say in > that comment is wrong. Pause button is actually a Play/Pause toggle key and it > is dedicated to that function. You can always turn the music on by pressing > pause when stuff is paused. It works that way on all of our devices, as well as > devices made by other vendors. > > Again, not trying to say it's intuitive, but it's not as catastrophic as "no > way to play music when on item X" Ben, Actually back when I filed 11963, Baby "Pause" toggle was broken (would only pause, wouldn't play) so I really COULDN'T play once paused :-) You can imagine my frustration. Toggle on Baby seems fine now, except it makes the wrong noise (makes the "can't do that" tone). Should I file a bug on the wrong nav tone issue?
Reset priority before triage.
I'm looking to work on this (for SP) but I'm not clear on what's being called for. Matt can you clarify? My interpretation of the comments is: 1) Never have play go right (since right can do that in all cases) 2) If the menu selection is something playable, then play should immediately play that. (is current behavior) Correct? What should play do when on a non-playable item? bump? Unpause (if paused)?
(In reply to comment #17) > I'm looking to work on this (for SP) but I'm not clear on what's being called > for. Matt can you clarify? > My interpretation of the comments is: > 1) Never have play go right (since right can do that in all cases) correct > 2) If the menu selection is something playable, then play should immediately > play that. (is current behavior) > > Correct? yes > > What should play do when on a non-playable item? bump? Unpause (if paused)? unpause if paused, otherwise bump...
(In reply to comment #18) > unpause if paused, otherwise bump... it should resume current playlist if stopped or off, yes?
== Auto-comment from SVN commit #28200 to the slim repo by tom == == https://svn.slimdevices.com/slim?view=revision&revision=28200 == Fixed Bug:11376 Description: - play action behavior is now "play a playable item", otherwise (if not a playable item) unpause
== Auto-comment from SVN commit #7126 to the jive repo by tom == == https://svn.slimdevices.com/jive?view=revision&revision=7126 == Fixed Bug:11376 Description: - play action behavior is now "play a playable item", otherwise (if not a playable item) unpause
== Auto-comment from SVN commit #7154 to the jive repo by tom == == https://svn.slimdevices.com/jive?view=revision&revision=7154 == Fixed Bug:11376 Description: - (missed a commit) play action behavior is now "play a playable item", otherwise (if not a playable item) unpause
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.