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

[AlecSp]

For a while, I'd noticed the thread about the community firmware and always assumed it would be too flakey for general use.

Noticed again yesterday that it sounded more ready for general consumption. All went swimmingly from my piCorePlayer LMS environment onto two SB Radios. No problems. No obvious improvements other than the blue "no LMS" indicator, knowing that the bass loss problem is addressed, and the absolute joy of knowing that my 11 year old devices have just received a firmware update !!!

Thanks to all for your hard work

[madpatrick]

>> Michael
> Tried to upgrade the IO::Socket::SSL version and it upgrade nicely to
> v2.068
>
>
> But when I restart Squeezeboxserver, it still says i'm running on a old
> version v1.94

You might have different versions of Perl installed? What does the
following tell you?

`which perl` -v

And what about

/usr/bin/perl -v

?

--

Michael

/usr/bin/perl -v

This is perl 5, version 16, subversion 3 (v5.16.3) built for x86_64-linux-thread-multi

I've found out that the update is stored in

/root/perl5/lib/perl5/IO/Socket

Instead of

/usr/share/perl5/vendor_perl/IO/Socket

[P Nelson]

I was reading through the thread to find what improvements or issues are resolved by installing the community firmware update. It was not until post#130 that I found a link to a list:
https://ralph_irving.gitlab.io/lms-c...changelog.html

I recommend the first post be edited to include this link, or if I missed it, please make it more obvious.

I am a basic user and I tend to believe in “if it isn’t broke, don’t try and fix it.” I admit I struggle with that because with technology things become outdated quickly, like internet security. However, I have been subject to installing updates (not squeezebox related) that ending up breaking functions instead of fixing or improving function which is really frustrating. My worst fear would be bricking the unit with a failed firmware update.

The biggest issue I have right now with several of my SB radios is it drops the Wifi connection. This is being caused by a new neighbor’s Wifi extender causing some type of interference. (The problem disappears if I move the SB Radio to my office.) The only way to get the Radio to connect to wifi again is to reboot, as trying to connect to a second wifi access point will not work until after a reboot.

I see some references to Wifi and wireless modules in the new firmware. Any chance the firmware update might fix the wifi problem?

Thank you to everyone that has been working very hard to keep this great product functioning!!!!!

Paul

[mherger]

>> `which perl` -v
>>
>> And what about
>>
>> /usr/bin/perl -v
>
> /usr/bin/perl -v
>
> Code:
> --------------------
> This is perl 5, version 16, subversion 3 (v5.16.3) built for x86_64-linux-thread-multi
> --------------------

What about the "which perl" version?

[mrw]

The biggest issue I have right now with several of my SB radios is it drops the Wifi connection. This is being caused by a new neighbor’s Wifi extender causing some type of interference. (The problem disappears if I move the SB Radio to my office.) The only way to get the Radio to connect to wifi again is to reboot, as trying to connect to a second wifi access point will not work until after a reboot.

I see some references to Wifi and wireless modules in the new firmware. Any chance the firmware update might fix the wifi problem?

At the risk of teaching grandmothers to suck eggs, have you tried manually setting your router/access point to use a channel that differs from your neighbour's choice of channel ? This is something I have had to do in a similar circumstance, because my access point seemed to "autochoose" a sub-optimal channel. That impacted use of a printer, etc., in a room furthest from my access point, but quite close to my neighbour's wi-fi extender.

It never impacted my Radios, though (different rooms). So I have never had the opportunity to investigate the effect on a Radio, in particular why rebooting seems to be the only option, at least in some cases.

There's quite a long thread on the subject, WiFi connection unstable/lost on three Radios: https://forums.slimdevices.com/showt...n-three-Radios. I don't know if any firm conclusions have been drawn.

I don't know if the updated wpa_supplicant would help or not. I don't think the firmware on the wi-fi chip has changed.

[jeroen2]

At the risk of teaching grandmothers to suck eggs, have you tried manually setting your router/access point to use a channel that differs from your neighbour's choice of channel ? This is something I have had to do in a similar circumstance, because my access point seemed to "autochoose" a sub-optimal channel. That impacted use of a printer, etc., in a room furthest from my access point, but quite close to my neighbour's wi-fi extender.

Especially in urban environments Wifi is increasingly becoming an issue. There's some useful advice here:
https://arstechnica.com/gadgets/2020...int-placement/

[mrw]

Especially in urban environments Wifi is increasingly becoming an issue. There's some useful advice here:
https://arstechnica.com/gadgets/2020...int-placement/

Very good article, thank you.

I can relate to the comment: Note: some RF engineers recommend -65dBm as the lowest signal level for maximum performance.. My ad-hoc experiences suggest that signal levels at, say, -70dBm may give acceptable performance if a connection can be established in the first place, but actually establishing the connection can be irritatingly flaky. Very noticeable when printing to a bonjour/zero-config printer, but not exclusively so. Possibly related to the amount of broadcast traffic that is required to "discover" whatever needs to be discovered - I believe that an AP will not apply any ACK/NAK procedure to this traffic, so if it's not heard then it's just lost for good.

[P Nelson]

At the risk of teaching grandmothers to suck eggs, have you tried manually setting your router/access point to use a channel that differs from your neighbour's choice of channel ? This is something I have had to do in a similar circumstance, because my access point seemed to "autochoose" a sub-optimal channel. That impacted use of a printer, etc., in a room furthest from my access point, but quite close to my neighbour's wi-fi extender.

It never impacted my Radios, though (different rooms). So I have never had the opportunity to investigate the effect on a Radio, in particular why rebooting seems to be the only option, at least in some cases.

There's quite a long thread on the subject, WiFi connection unstable/lost on three Radios: https://forums.slimdevices.com/showt...n-three-Radios. I don't know if any firm conclusions have been drawn.

I don't know if the updated wpa_supplicant would help or not. I don't think the firmware on the wi-fi chip has changed.

I did a Wi-Fi channel reconfiguration which did help a little as the frequency of the disconnect diminished. I suspect these Wi-Fi extenders are using a separate channel which cannot be adjusted. Using a Wi-Fi analyzer, I see an unnamed channel spike and then disappear.
I have looked at: https://forums.slimdevices.com/showt...n-three-Radios

The link provided by jeroen2 is also helpful.

I suspect Radio Wi-fi problem is due to some type of wi-fi extender or mesh network causing interference and the Radios are very sensitive to the issue.
The good news my neighbor is willing to coordinate Wi-Fi channels. I may have to run a Cat5 for him and put in a second access point to eliminate his Wi-Fi extender. However, if the community firmware update is know to fix it, then that would be easier. I will try it with one of the Radios and see what happens.

Thanks
Paul

[madpatrick]

>> `which perl` -v
>>
>> And what about
>>
>> /usr/bin/perl -v
>
> /usr/bin/perl -v
>
> Code:
> --------------------
> This is perl 5, version 16, subversion 3 (v5.16.3) built for x86_64-linux-thread-multi
> --------------------

What about the "which perl" version?

Sorry

# `which perl` -v

This is perl 5, version 16, subversion 3 (v5.16.3) built for x86_64-linux-thread-multi
(with 40 registered patches, see perl -V for more detail)

[mherger]

> I've found out that the update is stored in
>
>
> Code:
> --------------------
> /root/perl5/lib/perl5/IO/Socket
> --------------------
>
>
> Instead of
>
>
> Code:
> --------------------
> /usr/share/perl5/vendor_perl/IO/Socket
> --------------------

Ok, so you might need to try to replace the pre-installed version with
yours. Make sure you have a backup before you do so :-)