Bugzilla – Bug 10826
Pressing PLAY on an item should push you into Now Playing immediately
Last modified: 2009-10-05 14:26:58 UTC
Per the recommendation from Brian, pressing Play to start playback on any track should push you into the now playing screen immediately. Pushing back/left should take you back to the item you pressed play on. Michael: can you take a crack at this. I'd also like an option to revert to the previous behavior, so we can a/b test, though this option may be removed (or hidden). Opening a similar bug against Controller/SqueezePlay/etc.
see also bug 10827
Matt - before we implement this, could you please come up with a specification for all the screensaver and jumping behaviour when playing? Should this jump to NP be hardcoded or should whatever screensaver is configured for NP be used? I think we should define this in the bigger picture, with a good plan.
Ahm... what target? 8.0 is gone?
Sorry if I wasn't clear, but the NP screen should be pushed on to the stack from the current location. Left/Back should take you back to the screen that you were on when you pushed play, go/forward should push you into the song info for the current screen. Also, the NP screen should also be pushed on when playing from a preset. This should not affect the screensaver behavior at all. And 7.4 is probably going to be renamed 8.0 before launch, but since the branches and builds are all marked 7.4 we decided at the last sw team meeting to keep calling it 7.4 until then.
So... in case this option is set, the "Now playing" screensaver should be disabled (as it would display the same thing again, but add one mode level), but the others should still be valid?
We have two now playing screensavers: - Jump back on wake - This one should not be invoked, since the new behavior is basically a modification to this one. - Jump to NP - This one should be invoked
change 25020 - push into Now Playing mode. Please note that it's doing this only on PLAY, but not on add, insert etc. Is this what you had in mind?
That's right! Thanks. Will give it a spin.
Afraid I don't like this: 1) For transporter if we have now playing on the second screen we should leave that to show the now playing state - this results in now playing flitting back and forth between the two screens 2) If you go straight to now playing as we do now then pressing another immediately cancels this which looks odd. 3) I think there are a couple of issues with the implementation: 1) if the now playing saver is jump to now playing, I don't think this will do it - it will always jump back on wake, 2) If the now playing saver is something different there is a possibility that on wake you remove the top saver and expose this one rather than returning to the original menu level. [need to test these] 4) If you play a single track it does not happen! 5) There is already a show briefly "now playing from" - the mode changes as soon as this completes - is it needed if the new mechanism is kept?
So current implementation definately breaks "jump to now playing" as you always get the jump back on wake behaviour. In addition it does not work when another screensaver is set as the now playing saver as S:B:Screensaver will view this as a changed saver and so pop the mode before you see it.
The idea here is to push in to the NP screen immediately on pressing play on something, not to kick in a screensaver. This was a recommended change from the user testing, and clearly needs to be tested before we ship it, but I'm optimistic. Hm, I couldn't get it to work by playing a song from browse by artist->album->song by hitting play.
Well it has to operate as screensaver.. As if you press play you would still want to continue to navigate in the same list - you don't want to be a long way down the menu structure, press play and get sent to now playing and have to navigate back to the same point as you wanted to play something else? At present its implemented as if it pushes the now playing screensaver. I think this is ok iff this is the selected screensaver. We need to do something different if is now the the selected saver. I also don't think you want to do it if you already have now playing on the second screen of transporter.
I'm a little confused. It should behave as if you pushed right into Now Playing from home, but if you pop left it should take you back to the context in which you just pressed play. It's not a Screensaver, per se, but having Navigated into Now Playing, if you have a Now Playing screensaver set, it wouldn't kick in. If you had another screensaver set, then that one would kick in if you walked away from the device. Am I missing something?
Its currently implemented as using the screensaver mode.
Ah, so is it as simple as pushing into the "playlist" mode instead of the "screensaver" mode?
(In reply to comment #15) > Ah, so is it as simple as pushing into the "playlist" mode instead of the > "screensaver" mode? No. "playlist" is the other screensaver, which wouldn't return to the position you left on...
Ok - thought about this a bit more. Assuming the purpose is to go into the now playing display with the knob on boom controlling volume, its necessary to push the 'screensaver' mode. However the current implementation is broken for a few cases - doesn't happen in all cases when play is pressed - already in screensaver (it gets pushed again) - if the screensaver setting is not 'screensaver' as this will be nullify this change (we need to change the screensaver code to account for this) I also don't like it doing it on transporter with the extended text showing. Are we happy to disable in this case? I'm happy to look at assuming the above and this is planned to stay - i.e. its already been tested and liked?
Thanks, Triode. Actually, the purpose is not really to affect the Boom knob volume behavior, but rather to give the user some more immediate and lasting feedback when they choose something to play. Again, this isn't about the screensaver, rather it's about pushing them into the NP playlist mode. It hasn't been tested, this is a speculative change, but it's driven by the user testing that showed that new users got confused and really expected to be pushed into the now playing screen when they hit play. (probably because that's what iPod has taught them.) I can't promise it will stay, or that what I'm suggesting is what we'll end up shipping in the final release but it's definitely worth trying on both classic and SqueezePlay based UIs.
So I suggest getting user feedback on the current implementation (pushing into screensaver which means the knob will do volume), vs pushing into playlist (where the knob will do navigation in the list). Once you have that it needs tidying up to avoid the issues I raised.
Well, my feedback on the current behavior is that it's not right, or at least not what I expected. :) (i.e. it kicks in the screensaver and not pushes into NP). The NP info goes away when you hit an arrow key, feels fragile to me. Your point about the Boom knob being volume is a good one, but not the point of filing this bug. How hard would it be to try it the other way?
It would be trivial to push into playlist mode rather than screensaver - suggest we try this, but it will have a bunch of side effects similar to now which will need to be handled assuming it gives the right effect.
Created attachment 4857 [details] alternative approach Dean - proposed alternative patch for this. Note it only implements it for BrowseDB mode. (Other modes could also be done if this is the desired approach) - don't do showbriefly on play, push into now playing (playist) using a pushLeft - remove the code from Now Playing so that on left it always goes back to the home menu (so doing the above does not loose your position in the browseDB hierachy. I think the second one is a necessary consequence of the first as I found it very annoying to loose my position in the browse hierachy if I played the wrong album. But you may think different...
bump - do we want to apply this patch and people try it out. I think we ought to remove what is currently there as it will keep pushing modes if you play things from the web interface etc.
Yes, please! Let's get some eyes on this.
added in change 25425 - note this is only for BrowseDB for the moment to see if people like it
Any feedback? I'd expect some as play from BrowseDB works differently from other browse modes at present....
> Any feedback? I like it. And no complaints so far? Good work!
Which means we ought to add it to the other playback cases - xmlbrowser and BMF at least. It means redoing the "buffering" part of the feedback for remote streams, but this is probably worth it as long as everyone likes it... Any more confirmation?
Yes, please. We'll be doing this on Controller UIs as well, so it'll be a consistent improvement all around.
Adrian - you've implemented this, right?
I've implemented it but there are some side effects which I had expected feedback on. In the three relavent button modes it should push into Now Playing when you press play. It also didn't work with Alien which I have just fixed.
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.