Squeezebox Radios Reboots, with talk radio in the UK, cable connected , cable connect

[mrw]

I started playing Classic FM hours ago and the playing time in the now playing screen is 41 minutes. So I thought it must have rebooted but the Radio uptime is currently over 8 days. What happened there?

Good question, I became aware of something similar, with similar thought.
Could it be that at some point the remote server went away, the Radio attempted rebuffering, but unsuccessfully, and then resumed the stream from scratch ? Which is what it would do. I've never paid attention to the playing time.

[mrw]

The problem with this particular failed assertion is, I suspect, this: streambuf_fast_read will not return all available data if the relevant icy data is wrapped around in the fifo buffer. A second read is required in those circumstances. And the code only attempts one read. That's my 'defect'.

Well, I have now positively confirmed this hypothesis. I have a suitably 'patched' software (Squeezeplay on macOS) running, which makes that vital second read. The icy metadata is now read in full, and it looks just as would be expected. There is no sign of a hiccup.

Next steps are to create a suitably patched version of 'jive' for the Radio, and test under live firing conditions. But it will work...

[bayard1music]

Hello All,

Just to say I've had the radio on days and experienced so far no reboots using the AAC stream URL instead of the MP3. Not conclusive as probably had on less this week due to other domestic issues. I have seen one instance of 'Buffering' message on the screen with a gap in the sound but not a reboot.

I'd be grateful if somebody could summarise the findings of some of the experiments/tests being run by some of the members responding to my original thread as I'm not sure I understand their findings or implications.

Thanks again for all of this effort.

[mrw]

Just to say I've had the radio on days and experienced so far no reboots using the AAC stream URL instead of the MP3. Not conclusive as probably had on less this week due to other domestic issues. I have seen one instance of 'Buffering' message on the screen with a gap in the sound but not a reboot.

I'd be grateful if somebody could summarise the findings of some of the experiments/tests being run by some of the members responding to my original thread as I'm not sure I understand their findings or implications.

I can summarize the results of my experimentation to date:

I first suggested using the AAC stream in preference to the MP3 stream on the premise that may be something afoot with the Radio's MP3 decoder, or with the stream being sent. That no longer seems to be in point, so I think your apparent recent "success" is likely to have been a fluke.

I have located a defect[1] in the firmware (Squeezeplay/Jive) concerning the handling of 'icy metadata' that may be embedded in the transmitted stream. Where present, embedded metadata can supply the currently playing track title, possibly an image, etc. Both LBC & ClassicFM streams provide 'icy metadata', as do many other online streams.

The effect of the defect is that, periodically, and somewhat randomly, mishandling of the metadata results in a reboot. In the case of both the LBC MP3 and AAC streams, the opportunity for mishandling happens about once in every nine minutes[2]. The odds of that mishandling actually happening probably are about 1 in 100[3]. Cranking those numbers gives odds for the stream playing continuously for about four hours as 70%. The ClassicFM MP3 stream would be worse, because it has a higher bit rate - the opportunities for mishandling are more frequent, arising about once in every 3.5 minutes.

I am in the process of preparing a patched version of 'jive', the firmware component that runs on the Radio, that corrects this defect. If successful, that would offer one avenue to fix the issue. (I.E. by manually installing a replacement version on the Radio).

This may not suit most 'ordinary' users. I don't know what might be the best approach for them, further investigation is required. @bpa suggests that "proxied" streaming may be effective:
https://forums.slimdevices.com/showt...l=1#post997277

I intend to post a patched version of 'jive' suitable for testing by anyone who wishes to try that route. Hopefully it will nail the point in the real world, and not just on my test-bed. I just need to get my 'build system' running.

Also, it's worth remembering that, if a stream is left running for a long period, it is quite likely that the remote server will simply hang up. This would give rise to a certain amount of 'rebuffering', followed by an attempted reconnect and resumption of the stream. This would not cause the reboot.

With hindsight, this is not much of a summary !

[1] I am 100% confident in this statement. I may yet suffer for this display of hubris.
[2] Each stream reportedly provides a stream rate of 48 kilobits per second, and there's a buffer of size approximately 3.3M bytes. So the buffer 'rolls around' about every 9 minutes, and the 'roll around' is the opportunity for mishandling.
[3] I reckon each fragment of metadata is about 80 bytes in size, and is delivered every 8,000 bytes.

[bayard1music]

I can summarize the results of my experimentation to date:

I first suggested using the AAC stream in preference to the MP3 stream on the premise that may be something afoot with the Radio's MP3 decoder, or with the stream being sent. That no longer seems to be in point, so I think your apparent recent "success" is likely to have been a fluke.

I have located a defect[1] in the firmware (Squeezeplay/Jive) concerning the handling of 'icy metadata' that may be embedded in the transmitted stream. Where present, embedded metadata can supply the currently playing track title, possibly an image, etc. Both LBC & ClassicFM streams provide 'icy metadata', as do many other online streams.

The effect of the defect is that, periodically, and somewhat randomly, mishandling of the metadata results in a reboot. In the case of both the LBC MP3 and AAC streams, the opportunity for mishandling happens about once in every nine minutes[2]. The odds of that mishandling actually happening probably are about 1 in 100[3]. Cranking those numbers gives odds for the stream playing continuously for about four hours as 70%. The ClassicFM MP3 stream would be worse, because it has a higher bit rate - the opportunities for mishandling are more frequent, arising about once in every 3.5 minutes.

I am in the process of preparing a patched version of 'jive', the firmware component that runs on the Radio, that corrects this defect. If successful, that would offer one avenue to fix the issue. (I.E. by manually installing a replacement version on the Radio).

This may not suit most 'ordinary' users. I don't know what might be the best approach for them, further investigation is required. @bpa suggests that "proxied" streaming may be effective:
https://forums.slimdevices.com/showt...l=1#post997277

I intend to post a patched version of 'jive' suitable for testing by anyone who wishes to try that route. Hopefully it will nail the point in the real world, and not just on my test-bed. I just need to get my 'build system' running.

Also, it's worth remembering that, if a stream is left running for a long period, it is quite likely that the remote server will simply hang up. This would give rise to a certain amount of 'rebuffering', followed by an attempted reconnect and resumption of the stream. This would not cause the reboot.

With hindsight, this is not much of a summary !

[1] I am 100% confident in this statement. I may yet suffer for this display of hubris.
[2] Each stream reportedly provides a stream rate of 48 kilobits per second, and there's a buffer of size approximately 3.3M bytes. So the buffer 'rolls around' about every 9 minutes, and the 'roll around' is the opportunity for mishandling.
[3] I reckon each fragment of metadata is about 80 bytes in size, and is delivered every 8,000 bytes.

Hello,

Many thanks for that summary , it's a pretty good start for me today.

i) I'm not sure that there any images on the AAC station (not in front of me now), but there are some on the MP3 stream I'm sure.

ii) Should a modified version of 'jive' become available , might I ask how I would program that on my Squeezebox ? Or is this only something a developer would be skilled enough to do. I obviously don't want to 'brick' the radio beyond recovery due to my errors. Plus how might I know that the code is available if its something I could attempt. (I'm an electronics eng. but whilst having some Rasberry Pi/Arduino experience today I couldn't call myself a programmer.)

Thanks once more.

Thanks.

[mrw]

i) I'm not sure that there any images on the AAC station (not in front of me now), but there are some on the MP3 stream I'm sure.

As it happens, Global Radio does not provide images in their icy metadata offering. Any images that you may see probably stem from how the stream has been started - if from the 'Radio' menu on the Radio then probably TuneIn (the underlying driver of that menu) is providing them.

ii) Should a modified version of 'jive' become available , might I ask how I would program that on my Squeezebox ? Or is this only something a developer would be skilled enough to do. I obviously don't want to 'brick' the radio beyond recovery due to my errors. Plus how might I know that the code is available if its something I could attempt. (I'm an electronics eng. but whilst having some Rasberry Pi/Arduino experience today I couldn't call myself a programmer.)

I inadvertently overstated the capabilities of the replacement 'jive' that I have built and am currently running as a test. There are some closed source/private elements that don't go in. Notably no native AAC or WMA decoding. That's not necessarily a show stopper, because LMS will step in and transcode any AAC or WMA stream. But WMA (Windows media) requires, I believe, an additional plugin to be installed. I don't recall ever needing it, frankly. Helpful overview of the LMS transcoding process: https://forums.slimdevices.com/showt...l=1#post997751

That said, there is a project to keep the Radio's firmware updated, initiated by forum member @ralphy: Community Build Radio Firmware: https://forums.slimdevices.com/showt...l=1#post995413
That does have native AAC support (kudos to @ralphy), although some other limitations remain. I suspect that the absence of a native WMA decoder is the only item of any significance, and then only if you find yourself needing that format.

I am intending to offer up this particular 'patch' for inclusion in a future release, if it passes muster.

'Bricking' is a distinctly relative term. Given that you have Rasberry Pi experience, I imagine that you are content with using the command line to copy, move, unzip, delete files, etc. Were you to choose to install the 'jive' that I am making, it would be a simple upload together with a sequence of simple copy/move steps to put it in place *correctly*, followed by a *careful* check that all is as it should be before restarting the Radio.

At worse, a factory reset would remove the change and revert to the 'vanilla' system. It would also remove any saved settings, Wi-fi password, etc...

A different approach may yet be found that requires no firmware tinkering. As usual, it will become a matter of figuring out the various pros/cons.

[slartibartfast]

As it happens, Global Radio does not provide images in their icy metadata offering. Any images that you may see probably stem from how the stream has been started - if from the 'Radio' menu on the Radio then probably TuneIn (the underlying driver of that menu) is providing them.


I inadvertently overstated the capabilities of the replacement 'jive' that I have built and am currently running as a test. There are some closed source/private elements that don't go in. Notably no native AAC or WMA decoding. That's not necessarily a show stopper, because LMS will step in and transcode any AAC or WMA stream. But WMA (Windows media) requires, I believe, an additional plugin to be installed. I don't recall ever needing it, frankly. Helpful overview of the LMS transcoding process: https://forums.slimdevices.com/showt...l=1#post997751

That said, there is a project to keep the Radio's firmware updated, initiated by forum member @ralphy: Community Build Radio Firmware: https://forums.slimdevices.com/showt...l=1#post995413
That does have native AAC support (kudos to @ralphy), although some other limitations remain. I suspect that the absence of a native WMA decoder is the only item of any significance, and then only if you find yourself needing that format.

I am intending to offer up this particular 'patch' for inclusion in a future release, if it passes muster.

'Bricking' is a distinctly relative term. Given that you have Rasberry Pi experience, I imagine that you are content with using the command line to copy, move, unzip, delete files, etc. Were you to choose to install the 'jive' that I am making, it would be a simple upload together with a sequence of simple copy/move steps to put it in place *correctly*, followed by a *careful* check that all is as it should be before restarting the Radio.

At worse, a factory reset would remove the change and revert to the 'vanilla' system. It would also remove any saved settings, Wi-fi password, etc...

A different approach may yet be found that requires no firmware tinkering. As usual, it will become a matter of figuring out the various pros/cons.

I am running the jive alsa that you modified to workaround the bass amp issue. I thought that one did support aac but I could be wrong.

Sent from my Pixel 3a using Tapatalk

[mrw]

I am running the jive alsa that you modified to workaround the bass amp issue. I thought that one did support aac but I could be wrong.

AAC decoding is carried out in the 'jive' binary. The modified 'jive_alsa' binary that you are running is not involved, it only receives decoded PCM.

[ralphy]

That said, there is a project to keep the Radio's firmware updated, initiated by forum member @ralphy: Community Build Radio Firmware: https://forums.slimdevices.com/showt...l=1#post995413
That does have native AAC support (kudos to @ralphy), although some other limitations remain. I suspect that the absence of a native WMA decoder is the only item of any significance, and then only if you find yourself needing that format.

I am intending to offer up this particular 'patch' for inclusion in a future release, if it passes muster.

Thanks. The AAC decoder was the only private feature from the official firmware that I felt was a must have for the community firmware project.

In addition to the community radio firmware, I now have replacement firmware for the controller being tested and have almost completed new firmware for the touch.

I can build a radio firmware with your patch for test proposes if you'd prefer that to having to create an installer for the custom jive binary. The patch could be kept private until you're statisfied the issue has been fixed.

[mrw]

I'm not sure what the best approach for an ordinary user would be.

IIRC When a stream is proxied, icy metatada is filtered by LMS - so that maybe the workaround

Well, I think that that is the workaround for the "ordinary user". Having reminded myself of where in the settings one sets streams to be proxied, I can confirm that LMS handles the icy metadata, and the Radio doesn't see it. So the defect in the firmware is not triggered.

This is only effective when using a local LMS server, it will not influence matters if using mysqueezebox.com.