[Announce] Community Firmware for Squeezebox Radio/Touch/Controller and LMS 8

[staresy]

An update to my test.

The radio running the latest dev FW was still successfully streaming FLAC after 16hrs and hadn't appeared to put a foot wrong. I left it running and returned after a further 8 hrs (so a total run of 24hrs) and the radio was still connected to WIFI and fully responsive, it was still "playing" tracks however there was no audio and there was a warning message on the screen, something along the lines of "connection reset by local host" (I can't quite remember what it said).

Anyway, I didn't reboot anything, I just stopped it "playing" and lined up a new playlist and set it going again and it started playing just fine, so I'll leave it running again.

This doesn't feel like a WIFI failure to me, more likely an error caused by me simply streaming for such a long time?

Anyway, that's it for now, hope it's of some use.

[dzenc]

there was a warning message on the screen, something along the lines of "connection reset by local host" (I can't quite remember what it said).

Anyway, I didn't reboot anything, I just stopped it "playing" and lined up a new playlist and set it going again and it started playing just fine, so I'll leave it running again.

This doesn't feel like a WIFI failure to me, more likely an error caused by me simply streaming for such a long time?.

Here's what I found with a quick search: https://forums.slimdevices.com/forum...313#post385313

Definitely sounds like a network message. I'm not sure if it's wifi related or not. Is it possible your Radio picked up a new IP address from DHCP? (and had to restart network connections) or your router picked up a new IP address from your ISP? Were you listening to music from your local network or from the internet?

Anyway, it’s a message for other testers to be on the lookout for, to see if it repeats…

[staresy]

I was playing music on my local network. I don't think there were any NW changes (ie IP re-assignments).

For info, my LMS runs on a Win10 machine, with all the usual in built windows firewall/security etc.

[dzenc]

Can you try playing again for more than 24 hours and see if it stops at the same time again?

[staresy]

Can you try playing again for more than 24 hours and see if it stops at the same time again?

Will do, I'll report back how it goes.

[dzenc]

Thanks

[dzenc]

And... I just had one go RED. With no obvious cause.

Sigh... So frustrating.

[dzenc]

What's interesting is that with the additional driver debugging turned on, I can see that the wifi driver was still receiving (at least some, if not all) packets even when the app was displaying RED. But DHCP was simultaneously repeatedly reporting failure...

More threads to pull on here... More layers of the onion left to peel...

[dzenc]

I caught it in the act! And this time both me and the radio were well prepared to debug this type of issue (said issue which feels different than e.g. the kernel crash, assert, or wifi drops I had observed on previous builds).

The good news is that THIS bug, that I am still observing, is NOT a wifi disconnect. I can say that with confidence because I can see the following things occurring:

1. The radio is RED, however it reports that it still has good signal strength, but the ip address is a "LINK LOCAL" address (169.254.210.235)
2. iwconfig logging concurs that there is signal strength the entire time and there is no wifi disconnect mentioned in any logs.
3. And here's the smoking gun: The ipconfig statistics for the wireless interface continue to climb -- both RX and TX -- even after it has switched to this new/incorrect IP address. So the wifi interface is still working, both sending and receiving traffic!
4. From another node on the network, I can SEE that the Radio is still sending traffic, and receiving responses. From another device, I can observe the radio continuing to send DHCP requests and observe the responses it is receiving but seemingly ignoring.

So both from inside the radio and outside on the network, I can see that traffic is flowing across the radio's wifi interface. For this bug, WIFI is still working.

An additional interesting tidbit is that - strangely - the traffic on the radio's loopback adapter starts to flow about an hour prior to the failure. Again, I can tell this because I was tracking ipconfig statistics for both the wireless and loopback interface and I can see the traffic count (which was sitting steady at 1 beforehand), anyway I can see the traffic count on the loopback interface climb at a regular pace (about 30 packets per minute) for about an hour before the IP address changes to a bad address. And then once it changes to a bad address, things never recover. (Although traffic continues to flow over the wifi interface, because of the bad IP address, the system is now unable to communicate with the rest of the world).

Conclusion: This one is some kind of bug regarding DHCP and/or Zero Config or similarly related part of the network stack. It is not a WIFI disconnect. (whew!)

More work tomorrow.

[staresy]

Will do, I'll report back how it goes.

OK, I restarted my radio playing a playlist of 2500 FLAC songs from my local server.

The radio has not been re-booted at all since the "connection reset by local host" issue, it has just been lined up with a new playlist and play pressed.

It chugged through the playlist for 124 songs (6 hrs 47 minutes) and then got stuck at the end of track 124, the radio just keeps cycling the last few seconds of this track, but never moves onto track 125. No audio is played.

No red/blue WIFI icon, radio is fully responsive, and fully visible/controllable via web controller's (material etc). Nothing obvious to me in the standard logs.

Radio not rebooted yet, awaiting further instructions....

[dzenc]

Can you ssh into it? Please copy off /var/log/messages and /var/log/messages.0

please type ‘dmesg’ on the radio via ssh and capture and save the output

please type ‘iwconfig’ on the radio and capture and save the output

please type “ifconfig” on the radio and capture and save the output

please type “route” on the radio and capture and save the output

thank you

[dzenc]

Please also make note of exactly which track it is stuck on.

[slartibartfast]

OK, I restarted my radio playing a playlist of 2500 FLAC songs from my local server.

The radio has not been re-booted at all since the "connection reset by local host" issue, it has just been lined up with a new playlist and play pressed.

It chugged through the playlist for 124 songs (6 hrs 47 minutes) and then got stuck at the end of track 124, the radio just keeps cycling the last few seconds of this track, but never moves onto track 125. No audio is played.

No red/blue WIFI icon, radio is fully responsive, and fully visible/controllable via web controller's (material etc). Nothing obvious to me in the standard logs.

Radio not rebooted yet, awaiting further instructions....

This kind of thing has been reported quite often I think. Presumably skipping to the next track works. I have seen it happen on various players. It could be a red herring.

[staresy]

Can't SSH to the radio. I tried to SSH over WIFI as it appeared all to be working but it wouldn't connect, so I hard wired it, again no joy, no IP address being allocated. Tried manually configuring IP settings via the SBR, but nothing.

Unfortunately it's now stuck unable to connect anything either via WIFI (can't detect any WIFI NWs) or Ethernet. I feel the only option now is a reboot, but that will lose any log data.

I've not rebooted yet, let me know if there's anything you want me to try.

[staresy]

This kind of thing has been reported quite often I think. Presumably skipping to the next track works. I have seen it happen on various players. It could be a red herring.

Yes, I think I've seen it before on standard firmwares, so you could well be right.