Simplified instructions for Squeezebox Radio Wi-Fi fix (wlanpoke)

[POMdev]

I have a similar gap/reset profile as this (not quite as bad), where [0,1] ping gaps are common, with the occasional [6] ping gap which causes a full reset (Fr). I'm thinking of enabling the quick resets as suggested here, to when [3,4] ping gaps occur... can you describe further what the difference is between a quick and full reset (Qr vs Fr, functional differences, time it takes each to execute, etc.)? Also, if using Ping 2s3q6f, then will a Fr (full reset) never occur (because a Qr always executes first)?

If you want to play with the quick reset, download the script from the development branch. It has the most recent quick reset methods implemented. These have not been moved to the release branch because their overall effectiveness has not been sufficiently established, but one of them may work perfectly in your environment. This version supports a command line argument to select one of so-far three implemented "quick" methods. The manual.txt file describes them here:

-Qm Specify a quick reset method: one of 'power', 'wpa', or 'ifdnup76'. All methods reassociate with the access point. None of them are fully effective, instead, they delay "the inevitable" repeatedly for a few seconds each time until the next full reset, which restores the connection for a much longer time. Still, the methods recover some connectivity quickly, perhaps quickly enough to avoid gaps in the music, while "warning" the radio that the connection is becoming unreliable (so it could buffer more data for a shorter outage during a full reset). Experiment with this. The default is 'power', short for power nap. It turns off the radio [chip stack] entirely to save power [about which we don't care], [and has the desirable side effect of] requiring a sort of [chip] internal reboot to restart. Too bad it is not fully effective. Stay tuned, improvements may be forthcoming.

The script's ResetQuick() function on line 249 or so implements and describes the methods. They are all pretty quick, on the order of 1 or more seconds, not tens of (e.g., 40) seconds. The script measures and reports the shorter outages.

When (or if) the quick reset fails, the number of failed pings continues to increment until the full reset occurs.

[SAL9K]

If you want to play with the quick reset, download the script from the development branch. It has the most recent quick reset methods implemented. These have not been moved to the release branch because their overall effectiveness has not been sufficiently established, but one of them may work perfectly in your environment. This version supports a command line argument to select one of so-far three implemented "quick" methods. The manual.txt file describes them here:

-Qm Specify a quick reset method: one of 'power', 'wpa', or 'ifdnup76'. All methods reassociate with the access point. None of them are fully effective, instead, they delay "the inevitable" repeatedly for a few seconds each time until the next full reset, which restores the connection for a much longer time. Still, the methods recover some connectivity quickly, perhaps quickly enough to avoid gaps in the music, while "warning" the radio that the connection is becoming unreliable (so it could buffer more data for a shorter outage during a full reset). Experiment with this. The default is 'power', short for power nap. It turns off the radio [chip stack] entirely to save power [about which we don't care], [and has the desirable side effect of] requiring a sort of [chip] internal reboot to restart. Too bad it is not fully effective. Stay tuned, improvements may be forthcoming.

The script's ResetQuick() function on line 249 or so implements and describes the methods. They are all pretty quick, on the order of 1 or more seconds, not tens of (e.g., 40) seconds. The script measures and reports the shorter outages.

When (or if) the quick reset fails, the number of failed pings continues to increment until the full reset occurs.

Ah, of course, a Qr does not clear the failed ping count, and therefore a Fr will be handled after a failed Qr. Excellent information, thank you. As an alternative to experimenting with the Qr, I may back the Fr off to a lower ping count of [3,4].

Further, about the Wr values... I'm seeing these occur regularly, and can artificially force wlanpoke to do a Wr by simply changing the routers 2.4G control channel. Why is Wr incrementing, I.e. why is the wpa_cli crashing and not restarting on its own (perhaps this is a very complex question, and the inherent Radio problem)? Also, if a router is configured with "auto" control channel, then it is likely to be changing the WiFi control channel regularly, and therefore wlanpoke is likely to be restarting wpa_cli (and thus, incrementing Wr) with each control channel change... Does this imply that every time the router changes it's control channel, the Radio's wpa_cli is "dying" (and therefore wlanpoke is restarting it)? Or, is wpa_cli dying a natural process that the Radio needs to perform during a router WiFi control channel change, and therefore wlanpoke is "interfering" with a natural restart of the Radio's wpa_cli? Further, does wlanpoke assume that the WiFi router's control channel does not change, I.e. the user needs to fix their router's 2.4G WiFi channel. Yes, I understand that best practice is to fix the 2.4G WiFi channel to one of [1,6,11], I just would like to understand Wr, and wlanpoke's intentions of restarting wpa_cli during a router control channel change??

[POMdev]

... I may back the Fr off to a lower ping count of [3,4].

Yes, several users have done this. It saves about 2.5 seconds for every attempt, so "3" would save about 7.5 seconds, "4" about 5 seconds out of about 40 seconds. Still, a long time out, hence the attempt to find a decent quick reset method.

Further, about the Wr values... I'm seeing these occur regularly, and can artificially force wlanpoke to do a Wr by simply changing the routers 2.4G control channel. Why is Wr incrementing, I.e. why is the wpa_cli crashing and not restarting on its own (perhaps this is a very complex question, and the inherent Radio problem)?

A good question, and a good clue, which could be investigated. My three access points run on fixed channels, and wpa_cli occasionally quits anyway.

Also, if a router is configured with "auto" control channel, then it is likely to be changing the WiFi control channel regularly, and therefore wlanpoke is likely to be restarting wpa_cli (and thus, incrementing Wr) with each control channel change... Does this imply that every time the router changes it's control channel, the Radio's wpa_cli is "dying" (and therefore wlanpoke is restarting it)? Or, is wpa_cli dying a natural process that the Radio needs to perform during a router WiFi control channel change, and therefore wlanpoke is "interfering" with a natural restart of the Radio's wpa_cli?

An earlier version of the script did not have the wpc_cli check or restart, wpa_cli would occasionally quit, and (I remember) the radio would eventually fail because of that. So I do not believe the script is interfering with some other existing process that would restart wpa_cli. Also, we would not expect an essential service dying to be an embedded linux system feature, instead, wpa_cli should just not fail.

Further, does wlanpoke assume that the WiFi router's control channel does not change, I.e. the user needs to fix their router's 2.4G WiFi channel. Yes, I understand that best practice is to fix the 2.4G WiFi channel to one of [1,6,11], I just would like to understand Wr, and wlanpoke's intentions of restarting wpa_cli during a router control channel change??

The script does know about the WiFi channel. It just measures the number of failed ping attempts. Changing a channel should be pretty quick, but with interference, it could cause extended loss of connectivity as the radio searches, gets hung, and the script intervenes.

[SAL9K]

Yes, several users have done this. It saves about 2.5 seconds for every attempt, so "3" would save about 7.5 seconds, "4" about 5 seconds out of about 40 seconds. Still, a long time out, hence the attempt to find a decent quick reset method.

A good question, and a good clue, which could be investigated. My three access points run on fixed channels, and wpa_cli occasionally quits anyway.

An earlier version of the script did not have the wpc_cli check or restart, wpa_cli would occasionally quit, and (I remember) the radio would eventually fail because of that. So I do not believe the script is interfering with some other existing process that would restart wpa_cli. Also, we would not expect an essential service dying to be an embedded linux system feature, instead, wpa_cli should just not fail.

The script does know about the WiFi channel. It just measures the number of failed ping attempts. Changing a channel should be pretty quick, but with interference, it could cause extended loss of connectivity as the radio searches, gets hung, and the script intervenes.

Well, I haven't gotten the red-wifi-icon-of-death on any of my 4xRadio's for 3 days now, so wlanpoke is helping tremendously. I did however experience a stuck-at-end song during a sync'd continuous mix, with wlanpoke reporting no Wr's or Fr's in that time window, so I think there is a compounding number of things happening with that particular problem (seems like an inherent LMS sync problem that is not completely caused by, but exacerbated by WiFi issues). Thank you very much for all of the info, and for developing wlanpoke, it's really making the Radio's much more reliable for me!

[cramcram]

Internet Radio station stuttering since installation of wlanpoke

I installed wlanpoke on my radios. It works fine, I had no more disconnects. But since I installed wlanpoke one of my radio stations is stuttering, this is reproducible and happens every time. Here are the URL's of the station:

http://stream.srg-ssr.ch/drs3/aacp_96.m3u

http://opml.radiotime.com/Tune.ashx?id=s24862&formats=aac,ogg,mp3&partnerId=16&serial=67ca881ba465d209ec35162e6fcf7861

What can I do?

[ralphy]

I installed wlanpoke on my radios. It works fine, I had no more disconnects. But since I installed wlanpoke one of my radio stations is stuttering, this is reproducible and happens every time. Here are the URL's of the station:

http://stream.srg-ssr.ch/drs3/aacp_96.m3u

http://opml.radiotime.com/Tune.ashx?id=s24862&formats=aac,ogg,mp3&partnerId=16&serial=67ca881ba465d209ec35162e6fcf7861

What can I do?

Are you running the Community Firmware?

[P Nelson]

I installed wlanpoke on my radios. It works fine, I had no more disconnects. But since I installed wlanpoke one of my radio stations is stuttering, this is reproducible and happens every time. Here are the URL's of the station:

http://stream.srg-ssr.ch/drs3/aacp_96.m3u

http://opml.radiotime.com/Tune.ashx?id=s24862&formats=aac,ogg,mp3&partnerId=16&serial=67ca881ba465d209ec35162e6fcf7861

What can I do?

First, check the signal strength to make sure you have good signal.

The stuttering might be related wlanpoke resetting the Wifi. Perhaps try to increase the buffer.

[cramcram]

Are you running the Community Firmware?

Yes, I do. Latest version. Also thought it might be related to the latest community firmware that I installed just a few days prior to wlanpoke.

[cramcram]

First, check the signal strength to make sure you have good signal.

The stuttering might be related wlanpoke resetting the Wifi. Perhaps try to increase the buffer.

Signal strength hasn’t changed. Router / Radio position stayed the same. Has always worked for a long time.

[cramcram]

First, check the signal strength to make sure you have good signal.

The stuttering might be related wlanpoke resetting the Wifi. Perhaps try to increase the buffer.

Interesting also that Flac and Spotify which is more data than the radio stream don’t stutter… Thx for your helpful suggestions!

[ralphy]

Interesting also that Flac and Spotify which is more data than the radio stream don’t stutter… Thx for your helpful suggestions!

It's the AAC decoder that's the problem. Which the stream is using http://stream.srg-ssr.ch/drs3/aacp_96.m3u

I have been testing a change to mitigate the issue, would you be willing to try it to see if it helps?

It can be installed using the Patch Installer applet on the radio. You can also remove the change with Patch Installer if it doesn't work.

[cramcram]

It's the AAC decoder that's the problem. Which the stream is using http://stream.srg-ssr.ch/drs3/aacp_96.m3u

I have been testing a change to mitigate the issue, would you be willing to try it to see if it helps?

It can be installed using the Patch Installer applet on the radio. You can also remove the change with Patch Installer if it doesn't work.

Wow, of course I‘m happy to help with testing. I’ll be away for a couple of days, so I don’t have time before Monday.

[pablolie]

Great to have the WiFi working again on the Radio -thanks for the workaround! Only issue I see since doing it is when synching the Radio with my main player, I get intermittent 3-4 seconds of silence here and there. Anyone else observed it?

[Tony T]

Great to have the WiFi working again on the Radio -thanks for the workaround! Only issue I see since doing it is when synching the Radio with my main player, I get intermittent 3-4 seconds of silence here and there. Anyone else observed it?

I get silence when the WiFi drops out, and wlanpoke restarts it. Check the logs (there is a wlanpoke setting that allows you to see the info in a browser)

[ralphy]

Wow, of course I‘m happy to help with testing. I’ll be away for a couple of days, so I don’t have time before Monday.

Thanks. I've sent you a PM with the details.