I can't reproduce this...

Steps:
1. Use IR Remote power button to turn fab4 off
- observe the whenOff screensaver kicks in (in my case that's "black clock")
2. Touch the screen.
- observe the screensaver stays activated, with a power button appearing on the screen to indicate it needs to be powered on

1. Use Touch interface power button on home menu to turn fab4 off
- observe the whenOff screensaver kicks in (in my case that's "black clock")
2. Hit a button (not power) on the IR remote
- observe the screensaver stays activated, with a power button appearing on the screen to indicate it needs to be powered on
3. Hit the power button on the IR remote
- observe the main menu appear


This looks all working as designed to me...

> Steps:
> 1. Use IR Remote power button to turn fab4 off
> - observe the whenOff screensaver kicks in (in my case that's "black  
> clock")
> 2. Touch the screen.
> - observe the screensaver stays activated, with a power button appearing  
> on the screen to indicate it needs to be powered on

That's exactly how it does _not_ work here. In that latter case with the  
first touch I'm back in the menu, navigating. Could the hardware revision  
make a difference? This is one of the very early models, with the hand  
soldered pins at the top. Factory reset today.

QA to reproduce?

1) What is the PROPER and expected behavior

2) What firmware did BEN / MICHAEL test with

with the 2 above questions answered, QA will be albe to properly verify this bug is valid or invalid

James, two test cases are described in comment#1. The expected & designed behavior is listed there as well.

I was on r8202

See the same broken behaviour on the fab4 in the office. Tested with  
fab4/classic/boom remotes (in case this made any differenc)

Any news?!?

My fab4 still gets confused about its power states when using touch/IR. When changing to the other input method it would act as if it was in the other power state, but when I then try to change power state, I need to do it twice in order to get the state right.

Can't be that hard to reproduce, can it?

I am unable to reproduce this with r8398.

I am experiencing the same behavior that Ben documented.

Created attachment 6479 [details]
video showing wrong behaviour

Maybe it's just my old hardware, but I see it on both my fab4s I have. I did Ben's second list of instructions, pressing the Down button on the remote - which woke up the screensaver.

Mickey - I'll probably need some new hardware to verify this fixed ;-)

*** Bug 15641 has been marked as a duplicate of this bug. ***

Looking at the code it's quite obvious I'm not dreaming: when skin mode is switched, the screensaver is disabled.

function _disableAnyScreensaver(self)
	if appletManager:callService("isScreensaverActive") then
		appletManager:callService("deactivateScreensaver")
		appletManager:callService("restartScreenSaverTimer")
	end
end

Richard - this code seems to have been there since the initial checkin . Do you remember why you added this? Removing it seems to fix the issue I'm seeing, and I haven't experienced negative side-effects. But I'm sure there's a good reason it's there :-)

Ok, digging deeper I've found the following comment in the private-branch/fab4:

https://svn.slimdevices.com/jive/7.4/private-branches/fab4/squeezeplay/src/squeezeplay_fab4/share/applets/AutoSkin/AutoSkinApplet.lua?revision=5909&view=markup

"- no more double touch to get rid of screensaver. Any SS is disabled when switching skins."

So this seems to be a feature, not a bug. I wonder why. We introduced the double touch to prevent accidental wake up. Why shouldn't this be the case when switching the skin?

Tom - any insight?

Trying to clean up this applet. Fixed bug 15109 left quite a bit of unused code in there.

After a quick chat with Richard (thanks!) it seems that Tom's change mentioned above was to work around a design decision taken in the early days: ignore the event leading to the skin change. That decision imho should be reverted, as it's not only confusing and leading to more issues similar to the one Tom tried to fix (see eg. bug 15624).

Created attachment 6516 [details]
cleaning up the AutoSkinApplet

- remove uncommented/disabled code (following the decision taken in bug 15109)
- don't throw away the event causing the skin switch (fixing bug 15624)
- remove the screensaver wrangling needed to work around side effects of the aforementioned ignoring of the first event

Created attachment 6517 [details]
full applet file

Playing with this a little more I think we'll need some _selective_ ignoring of the event causing the skin switch: while IR remote key presses are clearly defined actions, touching the screen is not. Eg. touching a menu entry shown in IR mode will often trigger some other action, as the same coordinates in the touch skin represent a different menu item.

Therefore I guess there are some conditions where we should indeed ignore those events:

- when switching from remote to touch skin
- and no screensaver is active
- ... (more to come - feel free to add your findings)

 == Auto-comment from SVN commit #8501 to the  repo by mherger ==
 == https://svn.slimdevices.com/?view=revision&revision=8501 ==

Fixed Bug: 15223
Fixed Bug: 15624
Description: AutoSkin refinements

- remove unused proximity sensor code (see bug 15109)

- ignore all touch events leading to a switch from remote to touch UI, unless we're in screensaver mode. All other actions might be surprising, as the layout of the UIs are different, potentially leading to unwanted actions to be triggered

- ignore _some_ IR events leading to a switch from touch to remote UI: play and right might lead to unexpected actions, as the selected item isn't visible in touch UI. All other remote buttons are not/less context sensitive, thus don't need to be ignored (eg. volume, pause, jump keys etc.)

Oops I forgot to remove bug_meeting from these bugs.

This bug has been marked fixed in a released version of Squeezebox Server or the accompanying firmware or mysqueezebox.com release.

If you are still seeing this issue, please let us know!