search

ralph-irving / squeezeos

Source code for the Logitech Controller, Radio and Touch Community Firmware
https://sourceforge.net/projects/lmsclients/files/squeezeos/
22 stars 7 forks source link

Radios may not automatically reconnect to Wifi Router after Router reboot #11

Open mw9 opened 3 years ago

mw9 commented 3 years ago

I have two Radios, both running the latest firmware 8.0.1 r16867.

I noticed, recently, that neither of them would automatically reconnect to my WiFi router after it rebooted itself. Normally the Radios would automatically reconnect to the router after it restarts, so this is quite unexpected behaviour.

Both Radios responded successfully to "Repair network". However one of them displayed the following line in its log: Oct 9 14:39:20 squeezeplay: ERROR net.socket - Networking.lua:1326 if command failed: /sbin/ifdown "eth1=redacted" -f 2>/dev/null 1>/dev/null: Cannot allocate memory

Also apparent was that that particular Radio had much less free memory available.

Thinking that the problem might be related to recent changes, I started rolling back to see if a cause could be identified. Nothing obvious came to light.

Except that, after restarting the Radios, all appears to be back to normal, and they will both now automatically reconnect when the router is rebooted. Both Radios appear to have more free memory that they had before rebooting. Unfortunately I did not take notes.

I think that, in both cases, the issue arose as a result of insufficient available memory. Quiet where and why I do not know.

ralph-irving commented 2 years ago

I'm so sorry I haven't replied to this issue. I haven't experienced this problem, are you still? The one change that could cause this is we enabled the command line editing and history in wpa_cli. https://github.com/ralph-irving/squeezeos/commit/ecd3e1140363fddfb4cde2b5b9e573ef0772d650

mw9 commented 2 years ago

Thanks for the thought. I suspect that this problem, which happens quite rarely, precedes that CL history change, although I shall experiment.

What I shall do, though, is to compare memory usage against stock firmware. I think that is probably where the issue arises. Possibly related to AAC streams, although I am not sure. It would entail plotting usage on, say, an hourly basis to see how things move with time.

ralph-irving commented 2 years ago

I have managed to reduce the memory footprint of the fdk-aac library by 512K by removing the "encoders" from the build. It's not a lot but it might help. I also discovered that logitech used additional compiler optimizations for their closed source aac decoder. I'm hoping this will help with the issues reported around some high bit and sample rate aac streams "stuttering" at the start of playback. I haven't had much time to test the optimizations yet. Even if it doesn't, the memory savings can't hurt. I've attached the new library if you'd like to try it. Extract the tar file in /usr/lib and restart squeezeplay. It's a newer version of fdk-aac so it won't overwrite the original and you just need to change the symbolic link to point back to libfdk-aac.so.2.0.2 to revert it. libfdk-aac-2.0.3.tar.gz

mw9 commented 2 years ago

Well, I recently noticed the same problem, that neither of the Radios would automatically reconnect to my WiFi router after it rebooted itself. My other Squeezebox devices (Classic and a Controller) automatically reconnected just fine.

However the available memory seems to be fine, so perhaps my original association with memory usage was off the mark - just a coincidence. They do both automatically reconnect when I reboot the router manually, so there's something odd going on with router firmware upgrades.

It is probably not just a coincidence that it is the Radios that suffer. Issues with the Radio's wi-fi and perhaps wi-fi 6 have been well noted on the Squeezebox forums. Perhaps I am seeing another manifestation of an underlying issue.

I have been logging the memory usage of one the Radios for the last couple of weeks, when using the newer libfdk-aac.so.2.0.3. It's not obvious that the memory footprint is much lower than it has been, although it might be. It's about due for its three weekly reboot, so I might take the opportunity to records a 'stock firmware' session.

I have not been particularly aware of "high bit and sample rate aac streams stuttering", so I can't comment on whether the newer build helps with that. I haven't become aware of any other issues.

ralph-irving commented 2 years ago

I haven't used the stock firmware on the radio in forever. A memory usage comparison would be useful and interesting.

The BBC Sounds app is a good example of the "high bit and sample rate aac streams stuttering" but you need to change the Stream throttling interval setting to 0 seconds, from the default of 1, which Stuart added to specifically address the problem. Unfortunately as I'm not located in the UK I can't obtain the 48KHz 320bps AAC streams from the BBC that are known to cause it. I have been able create a similiar stream locally that also triggers the problem. It boils down to the aac decode not having enough pcm decoded data to provide the alsa layer with the number of frames it requests that then triggers an alsa buffer underrun error. I have a test patch to Playback.lua that avoids the problem. However, the 40K threshold override does not always work with a wifi radio, but on ethernet I've been unable to reproduce the pause/stuttering using the patch. It's available from patch installer using http://ralph.irving.sdf.org/extensions/aac.xml