Community Build Radio Firmware

[yosherl]

Yep, that solves the issue, mherger . Great.

I've just commented the lines out in the LMS-docker image, restarted it and enabled community firmware again. Installed 8.0.1-r16916 on one of the "baby" devices.

The only issue is: The first 10-15 seconds are sounding a bit like getting stuck with the pre-buffering. Also on manual title change then when pre-buffering a new title. If you just run a whole album, it does not happen on title change, so pre-buffering seems to work there. weird.
After the first seconds, stream works without a hassle (after playing and testing with the first titles)

[mherger]

Are you saying that the Napster playback is fine with the stock firmware, but not with the community firmware?

[yosherl]

No. Longer answer:

Stock Firmware works without removing https://github.com/Logitech/slimserv...r.pm#L182-L189

community firmware works now after commenting out the Lines 182 to 189 - with the pre-buffering issue, but rest of it is fine.

What was modified within canDecodeRhapsody in community firmware so that it returns false? :-)

[mherger]

I'm still confused: the pre-buffering issue, is it there for both firmware versions or specifically only in the community version of it?

The latter can't "canDecodeRhapsody" because that's a legacy thing which required certificates embedded in to the firmware. Those certs obviously aren't publicly available. But they're no longer needed anyway. Therefore I've removed related code from LMS 8.4 yesterday.

[yosherl]

I've send you a video via the dropbox. That illustrates the issue better I hope.

Yes, the 8.x Community Firmware gets stuck a bit after starting a title.

The Stock Firmware (in this case downgraded to 7.7.3 for the test on the "white" squeezebox) shows no issue.

[mherger]

ralphy - would you have any idea why Napster content would have more buffering issues on the community firmware then they have on official firmware? It's mp4 audio, no more custom encryption stuff involved.

[EdInPa]

Community Firmware won't download.

• Installed community firmware plugin
• Enabled it (check-box)
• Set "automatically check" and "daily"
• Set "automatically download"
• Set firmware logging to debug.

Log shows

Slim::Utils::Firmware::need_upgrade (348) baby doesn't need an upgrade (has: 7.7.3 r16676, server has: 7.7.3 16676)

for each of my radios. There is no reference at all to downloading firmware.

I know that there is a pending LMS update which has been downloaded but not yet installed (Ubuntu host, .deb file staged). Is it possible that the process is not reaching the firmware download because it thinks it's done now that it has the new .deb file?

Here's the log section for the last update check session:

Slim::Utils::Update::getUpdateInstaller (335) Reading update installer path from /var/lib/squeezeboxserver/cache/updates/server.version
Slim::Utils::Update::getUpdateInstaller (357) Found update installer path: ''
Slim::Utils::Update::checkVersion (78) Checking version now.
Slim::Utils::Update::checkVersion (93) Using URL: https://www.mysqueezebox.com/update/?version=8.3.0&revision=1667251155&lang=EN&geturl=1&os=debamd64&uuid=6a33dcf2-731a-4574-8e49-71141614aa04&pcount=5
Slim::Utils::Update::checkVersionCB (154) https://downloads.slimdevices.com/LogitechMediaServer_v8.3.1/logitechmediaserver_8.3.1_amd64.deb
Slim::Utils::Update::checkVersionCB (162) Triggering automatic Logitech Media Server update download...
Slim::Utils::Update::getUpdate (206) URL to download update from: https://downloads.slimdevices.com/LogitechMediaServer_v8.3.1/logitechmediaserver_8.3.1_amd64.deb
Slim::Utils::Update::getUpdate (223) We already have the latest installer file: /var/lib/squeezeboxserver/cache/updates/logitechmediaserver_8.3.1_amd64.deb
Slim::Utils::Update::setUpdateInstaller (300) Setting update version file to: /var/lib/squeezeboxserver/cache/updates/logitechmediaserver_8.3.1_amd64.deb

Might it be enough to delete the downloaded .deb file and let it download again? Would this be enough to force the firmware download? Or will I have to actually install the update for the process to reach the firmware download point? Or is there something else going on??

Thanks.

[yosherl]

Community Firmware won't download.

• Installed community firmware plugin
• Enabled it (check-box)
• Set "automatically check" and "daily"
• Set "automatically download"
• Set firmware logging to debug.

Log shows
for each of my radios. There is no reference at all to downloading firmware.

I know that there is a pending LMS update which has been downloaded but not yet installed (Ubuntu host, .deb file staged). Is it possible that the process is not reaching the firmware download because it thinks it's done now that it has the new .deb file?

Here's the log section for the last update check session:

Might it be enough to delete the downloaded .deb file and let it download again? Would this be enough to force the firmware download? Or will I have to actually install the update for the process to reach the firmware download point? Or is there something else going on??

Thanks.

As I just brought back one Squeezebox Radio yesterday to 8.x community firmware, in general it is working. Enabled the plugin, also for clearing my server log rebooted the server and waited approximately ~1 hour. Afterwards, the firmware update was offered by the server and choosing the firmware update function on the device updated it.

[ralphy]

ralphy - would you have any idea why Napster content would have more buffering issues on the community firmware then they have on official firmware? It's mp4 audio, no more custom encryption stuff involved.

We have a similar issue with BBC sounds plugin which expectingtofly added the Stream throttling interval setting to work around.
The problem is with high bit and sample rate aac streams, like 320Kbps and 48KHz on the radio.
More details can be found in my post https://forums.slimdevices.com/forum...43#post1548143 at this point, I don't have a fix.

[yosherl]

ralphy Regarding the Napster streams - yesterday, I also started a playlist playback. The effect was not happening as the next title was played. So, in this case, it does not restarting the streams as it seems. Even though it is another playback URI.
Maybe this observation helps a bit to narrow down the reasons...

[mherger]

We have a similar issue with BBC sounds plugin which expectingtofly added the Stream throttling interval setting to work around.
The problem is with high bit and sample rate aac streams, like 320Kbps and 48KHz on the radio.
More details can be found in my post https://forums.slimdevices.com/forum...43#post1548143 at this point, I don't have a fix.

Thanks for the link. But can you confirm this is an issue with the community firmware?

[EdInPa]

Community Firmware won't download, continued...

I deleted the pending LMS update file (the .deb file), and the log showed it got re-downloaded, but no evidence of it trying to download firmware. I can see the old firmware in the cache directory, but I don't know why LMS won't get the new files to offer them. My next step will be to upgrade LMS, and see if not having a pending update unblocks the firmware download. (Having that pending update is the only thing I've thought of that makes my situation possibly different from all of those for whom this "just works.")

[EdInPa]

Community Firmware won't download, continued...

I installed the pending 8.3.1 update on the server, confirmed that all the settings were in place, and the radios now offer the community firmware.

So it does appear that a pending update blocks the switchover to the community firmware. Hope this helps someone else.

[ralphy]

Thanks for the link. But can you confirm this is an issue with the community firmware?

For the radio, yes, provided the Napster stream format is the same as the bbc sounds plugin. I don't have access to Napster to confirm.

[yosherl]

Yes, provided the Napster stream format is the same as the bbc sounds plugin. I don't have access to Napster to confirm.

Debug Log for Napster tracks says:

Slim::Plugin::RhapsodyDirect::ProtocolHandler::__A NON__ (344) getTrackInfo ok: {
​... 
trackPlaybackFormat => { bitRate => 320, "format" => "AAC", radVersion => 0 },
​