Bugzilla – Bug 16023
Screensaver prevents sleep from turning off SB Radio (7.5.0)
Last modified: 2010-05-06 06:22:03 UTC
Select any screensaver for "When Playing" other then "Now Playing" and other than what you use for "When Off" (i.e. select Digital clock) Select "Sleep" when songs ends. When the song ends, the player will "Stop", but not "Turn Off". Now try with Screensaver "Now Playing" for "When Playing" and the SB Radio should turn off when the song ends.
I can confirm that my SB Radio behaves in same way. When sleep mode ends the screen saver remains the same. On previous version it would switch to the off screen saver. I also note that on power up it now goes to the menu instead of clock display.
This bug started with the 7.5.0 FW
There's no need for this to be in QA's hands, I can easily reproduce.
I have determined that the fix for bug 14986 caused this regression. Felix, cc:ing you. I think the fix for 14986 is in conflict with what's required for this bug. Here is the relevant code: -- In some situations the timer restart below tries to activate an SS when one is already running. -- Example: Blank SS for soft power off while in Diagnostics (i.e. an applet not allowing SS). -- This causes the backlight to turn on again after 10 seconds. #14986 if self:isScreensaverActive() then log:warn("A screensaver is already active - ignoring activate request.") return end
Ok, I see, there actually is a valid situation where a screensaver is already running and another (or the same) is activated. I guess we need to allow for exceptions here then, maybe it would be enough to allow an activation of a screensaver (when one is already running) but only when the new screensaver is different from what is already showing? The issue I tried to solve with the backlight was an activation of the _same_ screensaver (blank) twice which caused the backlight to turn on again. What I do not understand though is why self.active is a table? Does that mean more than one screensaver can be active at a given time?
>There's no need for this to be in QA's hands, I can easily reproduce. THANK YOU!!!
== Auto-comment from SVN commit #8726 to the jive repo by bklaas == == http://svn.slimdevices.com/jive?view=revision&revision=8726 == Fixed Bug: 16023 Bug: 14986 Description: only ignore the _activate() screensaver method to fulfill bug 14986 if the_screensaver is the same as the currently running screensaver I've tested this as correctly fixing bug 16023, and attempted to test that 14986 still works as desired. AFAICT, bug 14986 is still fixed, but I could use some independent verification of that one.
== Auto-comment from SVN commit #8727 to the jive repo by bklaas == == http://svn.slimdevices.com/jive?view=revision&revision=8727 == Bug: 16023 Bug: 14986 Description: checkin r8726 fixed 16023 but regressed the fix for 14986 I've adopted a new approach, which is to allow a ssName to come in with the service method screensaverWindow(), and that name is attached to self.current when that ss window comes to screen Then in _activate(), the check is for whether a screensaver is active and whether self.current == 'BlankScreen'. If those conditions are met, don't do anything (this fixes bug 14986). If those conditions are not met, go ahead and activate the SS (this fixes 16023). note that in most cases, by the time _activate() is called, self.current will have been set to nil because the ss from the previous mode (e.g., going from when playing->when stopped) will already have been popped from the stack. That's fine, as in this case we'd want _activate() to continue going about its business.
If the radio tries to go to sleep after the SQBX Server becomes unavailable, the sleep session never ends and the radio does not shut down. Is this the same problem as the one that has been stated here? I first saw this with 7.5.1 r30720, but I may have just not run into it before then.