Bug 9545 - Pause.Hold (stop) fails in screensaver
: Pause.Hold (stop) fails in screensaver
Status: CLOSED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: IR
: 7.3.0
: All Debian Linux
: -- normal (vote)
: 7.x
Assigned To: Unassigned bug - please assign me!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-19 01:42 UTC by Alan Young
Modified: 2009-07-31 10:30 UTC (History)
2 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alan Young 2008-09-19 01:42:50 UTC
Using press-and-hold of the Pause button on an IR remote while the display is in a screen-saver (even Now Playing) fails to activate the stop function. You first have to wake up the screen-saver.

It seems that it only fails for IR and works ok for TP or Boom front-panel buttons.
Comment 1 Jim McAtee 2008-09-19 01:48:00 UTC
*** Bug 9543 has been marked as a duplicate of this bug. ***
Comment 2 Adrian Smith 2008-09-19 14:41:26 UTC
Hum - this is a problem...

Slim::Hardware::IR::resendButton is called, but it this is flawed in this case - it resends the original IR code, so for .hold events this does not look like it gets passed to the mode once the screensaver is cancelled as a .hold event only occurs one on a timer.  We may want to try to pass back the .hold event not the IR code.  I need to think about this (unless someone else wants to!?)
Comment 3 Adrian Smith 2008-09-19 15:04:05 UTC
Try 23223 - for 7.2.1
Comment 4 Jim McAtee 2008-09-19 15:07:34 UTC
(In reply to comment #3)
> Try 23223 - for 7.2.1

Is this broken in 7.2.1?  I would have thought we'd be seeing more reports of it if so.  I'm running 7.3.
Comment 5 Adrian Smith 2008-09-19 15:14:15 UTC
Well its probably been broken for a long time for non nowplaying screensavers, but the conversion of now playing to act as a screensaver in 7.2 will mean it impacts more people...  (there's nothing much changed in 7.3 from 7.2 in this regard)
Comment 6 Jim McAtee 2008-09-20 14:29:13 UTC
That mostly fixes it.  There still seem to be some issues with player state, and effects on display behavior in reaction to IR, screensavers and stopping.

1. Stop the player.
2. Let the stopped screensaver kick in.
3. Press Fwd.

Playback begins, but the stopped screensaver continues, then the now playing screensaver kicks in.  The display should have gone to now playing info before the now playing screensaver.

4. Press Stop.

Display changes to now playing info.  Music doesn't stop.  Eventually kicks back into now playing screensaver.

5. Press stop again.

Now it stops.

Variations on this show some other odd behavior.  I also see sometimes see corruption of the now playing screensaver (analog vu meters), where it gets mixed with the stopped screensaver (snow).
Comment 7 Adrian Smith 2008-09-20 14:51:50 UTC
Right so this is a different problem - the idle (stop) saver is not cancelling.

Try adding 
fwd = done_passback
rew = done_passback

to the idlesaver portion of IR/Default.map
Comment 8 Jim McAtee 2008-09-20 15:21:42 UTC
That fixes it.  I notice also that Pause doesn't exist the idle screensaver.  Maybe that's intentional (player is already idle), but I would think that it would be desirable to have any IR button press exit the idle screensaver and return to now playing info, even if the music playback state doesn't change.
Comment 9 Adrian Smith 2008-09-20 15:26:15 UTC
added in change 23230
Comment 10 Spies Steven 2008-10-13 16:04:19 UTC
Verified with SqueezeCenter Version: 7.2.1 - 23502
Comment 11 James Richardson 2008-12-15 12:36:01 UTC
This bug has been fixed in the 7.3.0 release version of SqueezeCenter!

Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already.  

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
Comment 12 Chris Owens 2009-07-31 10:30:08 UTC
Reduce number of active targets for SC