How to force Radio to display screensaver?

[RobbH]

I have a situation in which my Radio display never times out, so the screensaver never appears.

Specifics:
The Radio was sold as a UE Smart Radio, but shortly after acquisition it was UPgraded to Squeezebox Radio firmware. Still with firmware 7.7.3-r16676.

I rarely use the Radio as a player. It's my bedside clock, and I use it to control another player in the bedroom, an Airplay speaker connected to LMS through the Airplay bridge, which is usually synchronized with other players using the Group Players plugin.

All three screensavers are set to "Digital Clock (Black)" and the delay is ten seconds.

When the Airplay speaker starts playing, the Radio displays its Now Playing screen, but it never times out and returns to the screensaver until the Airplay speaker stops playing, unless I press the Home button on the Radio or a remote.

Any ideas how I might correct this behavior or automate the button press? I thought about using the cli "button" command, but after some failed experimentation I searched this forum and found that the command is largely incompatible with the Radio.

I have a script running on the Pi running LMS that can detect when music starts playing, and it is communicating with the LMS cli via telnet, so if there is a command that would serve this purpose, it should be a simple matter to implement it. It should also be easy enough to ssh into the Radio, if there is a local command that would do the job.

Suggestions will be appreciated!

[RobbH]

I forgot to mention that the screensaver appears when it's supposed to, if the Radio is set to control itself. It's only when it's controlling another player that the Now Playing display never times out. It's consistent with the Airplay speaker in the bedroom. It has happened when controlling other players, too, but not as consistently.

[RobbH]

I hoped someone would have some ideas about my Radio's reluctant screensaver, but it is such an obscure issue that I'm not surprised that there's been no response. Maybe no one else has experienced this?

I am still trying to think of a way to automate a press of the Home button on the Radio after music starts playing. The cli "button" command does not work on the Radio, but does anyone here know about the "ir" command? And it seems I am not bright enough to understand the documentation of the command, so can anybody explain it?

<playerid> ir <ircode> <time>

The "ir" command simulates an IR code. Valid IR codes are defined in the Default.map file.

Example:

Request: "bd:a5:a9:9b:9d:df ir 768910ef 11073.575<LF>"
Response: "bd:a5:a9:9b:9d:df ir 768910ef 11073.575<LF>"

I understand the playerid/MAC, which needs to be url-encoded, and the IR code, but what is the "time" parameter? Does it determine when the IR code is to be sent? Or maybe the duration of a simulated key press? Or something else? The example doesn't seem to fit either of those scenarios.

I have not found a Default.map file on the Radio, but there is ./usr/share/jive/jive/irMap_default.lua, which contains IR code definitions.

[Paul Webster]

How to force Radio to display screensaver?

I think the time is to tell LMS when the key was pressed.

There are some comments at the start of
Slim/Hardware/IR.pm

I expect the same thing is used elsewhere within LMS ... and perhaps those other places have a better description.

I suspect the player has a notion of "now" and this number is compared against that. "now" probably 0 when a player starts rather than unix time since player need not know the real time (as in the time on your clock).

The map file is in LMS
IR/Default.map

[slartibartfast]

I hoped someone would have some ideas about my Radio's reluctant screensaver, but it is such an obscure issue that I'm not surprised that there's been no response. Maybe no one else has experienced this?

I am still trying to think of a way to automate a press of the Home button on the Radio after music starts playing. The cli "button" command does not work on the Radio, but does anyone here know about the "ir" command? And it seems I am not bright enough to understand the documentation of the command, so can anybody explain it?

<playerid> ir <ircode> <time>

The "ir" command simulates an IR code. Valid IR codes are defined in the Default.map file.

Example:

Request: "bd:a5:a9:9b:9d:df ir 768910ef 11073.575<LF>"
Response: "bd:a5:a9:9b:9d:df ir 768910ef 11073.575<LF>"

I understand the playerid/MAC, which needs to be url-encoded, and the IR code, but what is the "time" parameter? Does it determine when the IR code is to be sent? Or maybe the duration of a simulated key press? Or something else? The example doesn't seem to fit either of those scenarios.

I have not found a Default.map file on the Radio, but there is ./usr/share/jive/jive/irMap_default.lua, which contains IR code definitions.

This doesn't help you but if I set my Radio to control my Touch then it does still enter screensaver mode normally

Sent from my Pixel 3a using Tapatalk

[RobbH]

I think the time is to tell LMS when the key was pressed.

There are some comments at the start of
Slim/Hardware/IR.pm

I expect the same thing is used elsewhere within LMS ... and perhaps those other places have a better description.

I suspect the player has a notion of "now" and this number is compared against that. "now" probably 0 when a player starts rather than unix time since player need not know the real time (as in the time on your clock).

The map file is in LMS
IR/Default.map

Thanks, Paul. That gives me plenty to cogitate over.

[RobbH]

This doesn't help you but if I set my Radio to control my Touch then it does still enter screensaver mode normally

Sent from my Pixel 3a using Tapatalk

Thanks. That's good to know.

So far, the bedroom Airplay (not bluetooth!) speaker (a Jam Symphony) is consistent. If the Radio is set to control it, the Radio screensaver will not appear while it is playing, without intervention. It does not matter if the Airplay speaker is playing as part of a group or by itself. When I have used the Radio to control other players around the house, this has only happened when the other player is part of a group.

[RobbH]

I installed the Community firmware on the Radio. I didn't expect it to solve my odd and obscure problem, so I was not disappointed when it didn't. I hoped there might be a chance that my issue had been part of some larger and more significant issue, which had been fixed; but no.

I do not expect to fix the issue myself or convince anyone else to tackle it. It's very minor, and obviously it has not been a problem for anyone else.

So I am only interested in finding a way to get the screensaver on my Radio working again, after the display has been hijacked by the Now Playing screen from the player controlled by the Radio. I can easily achieve that by pressing the Home button on the Radio itself or on a remote. But I am extraordinarily lazy, so I seek a way to automate that task. As stated earlier, I can easily run a command when the other player starts playing, and that command can send telnet messages to the LMS cli or ssh into the Radio.

So, can anybody think of a way to achieve that? I have found one that works, but it requires brute force and it's not as smooth as I would like. I can set up a script to ssh into the Radio and reboot it. That achieves my goal of getting the clock screensaver back on the Radio's display, after an interval of time that includes playing the Radio startup tones.

I would be very interested in hearing any other ideas about how to get the Radio screensaver to work again in this situation. (In brief: the radio is set to control another player. When that player starts playing, the Now Playing display is shown on the Radio, and it never times out, so the clock screensaver never appears until the other player stops, UNLESS the Home button is pressed on the Radio or a remote. More detail in post #1)

[RobbH]

I installed the Community firmware on the Radio. I didn't expect it to solve my odd and obscure problem, so I was not disappointed when it didn't...

I take it back! After a reboot of the LMS server, the Radio screensavers are now working as expected.

[mrw]

I take it back! After a reboot of the LMS server, the Radio screensavers are now working as expected.

Perhaps a consequence of this change in the Community Firmware:
Detect NowPlaying as screensaver

[RobbH]

Perhaps a consequence of this change in the Community Firmware:
Detect NowPlaying as screensaver

Very interesting! Thanks for that reference.

[JJZolx]

I have a situation in which my Radio display never times out, so the screensaver never appears.

I recently retired my Radio due to the wifi connection issues, but I had this problem all the time, going back years. So it's not a recent issue due to any firmware or server changes. I never used the Radio to control other players, so it would happen happen when controlling itself.

One thing about the way I used the Radio was that to shut off the music, I'd often be sitting at my computer in another room and would do so by clearing the playlist from the LMS web interface. Not sure if that had anything to do with it.

[slartibartfast]

Perhaps a consequence of this change in the Community Firmware:
Detect NowPlaying as screensaver

Probably. I wonder why the "Reduce Brightness" patch related to it was never merged. I wouldn't be without it on my Radios.

Sent from my Pixel 3a using Tapatalk

[RobbH]

I recently retired my Radio due to the wifi connection issues, but I had this problem all the time, going back years. So it's not a recent issue due to any firmware or server changes. I never used the Radio to control other players, so it would happen happen when controlling itself....

Thanks! It's good to know I'm not the only one to encounter this problem. It does seem to be related to the patch that mrw linked, although the problem you and I had seems to me the opposite of the one the patch addressed. It seems to me that the Radio firmware was treating the Now Playing screen as a screensaver, although we were not using it that way. The patch corrected an issue when Now Playing WAS used as a screensaver but was not recognized as such.

[ralphy]

Probably. I wonder why the "Reduce Brightness" patch related to it was never merged. I wouldn't be without it on my Radios.

Sent from my Pixel 3a using Tapatalk

I didn't merge it because I prefer the original firmware behaviour and I don't like forcing interface changes on everyone.

I added the Detect NowPlaying as screensaver support so it could be used by other applets.

Has any one confirmed that reverting the screensaver detection change fixes the original issue?