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

[mrw]

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.

Thanks. I won't be offering a custom binary as I think there is an "ordinary user" workaround available.

Nevertheless I think that Squeezeplay does need correcting, and I've satisfied myself that I have an appropriate patch. A second set of eyes is always welcome.

I've attached to this post:

• The patch that I think needs to be in Squeezeplay:
  0001-Bugfix-Incomplete-extraction-of-icy-metadata-causes-.patch.txt
• A debug/verification patch that traces proper operation:
  0002-Bugfix-icy-metadata-for-testing-only-verify-operatio.patch.txt
• A 'pokyized' version of the above that I applied to the existing squeezeos source tree to build the test jive binary:
  00xx-poky-icy-fix-debug-version.patch.txt

I have tested both on desktop Squeezeplay on macOS, and on a Radio with a custom jive binary.

Typical log output from the debug/verification version is as follows:

Dec  8 00:22:22 squeezeplay: INFO   audio.decode - streambuf_icy_filter:393 ICY: Caught defect
Dec  8 00:22:22 squeezeplay: INFO   audio.decode - streambuf_icy_filter:397 ICY: Stream buf read ptr should be 0, it is 0
Dec  8 00:22:22 squeezeplay: INFO   audio.decode - streambuf_icy_filter:401 ICY: Recovered from defect: icy metadata: StreamTitle='Ludwig van Beethoven - Symphony No.6 in F major Opus 68 (2)';StreamUrl='';UTC='20201208T002157.047';
<snip>
Dec  8 04:21:34 squeezeplay: INFO   audio.decode - streambuf_icy_filter:393 ICY: Caught defect
Dec  8 04:21:34 squeezeplay: INFO   audio.decode - streambuf_icy_filter:397 ICY: Stream buf read ptr should be 0, it is 0
Dec  8 04:21:34 squeezeplay: INFO   audio.decode - streambuf_icy_filter:401 ICY: Recovered from defect: icy metadata: StreamTitle='Franz Schubert, Schubert Ensemble - Piano Quintet in A major D.667 (4)';StreamUrl='';UTC='20201208T042107.547';
<snip>
Dec  8 09:12:42 squeezeplay: INFO   audio.decode - streambuf_icy_filter:393 ICY: Caught defect
Dec  8 09:12:42 squeezeplay: INFO   audio.decode - streambuf_icy_filter:397 ICY: Stream buf read ptr should be 0, it is 0
Dec  8 09:12:42 squeezeplay: INFO   audio.decode - streambuf_icy_filter:401 ICY: Recovered from defect: icy metadata: StreamTitle='Gustav Holst - `In the bleak mid-winter.`

This was generated on a Radio, playing out this continuous stream: http://media-ice.musicradio.com/ClassicFMMP3.

I will add that changing STREAMBUF_SIZE in streambuf.c from 3MB to, say, 150k, makes for a much more effective test session, because the incidence rate is increased about 20-fold.

Let me know if you would be interested in a receiving a PR.

[ralphy]

Thanks. I won't be offering a custom binary as I think there is an "ordinary user" workaround available.

Nevertheless I think that Squeezeplay does need correcting, and I've satisfied myself that I have an appropriate patch. A second set of eyes is always welcome.

I've attached to this post:

• The patch that I think needs to be in Squeezeplay:
  0001-Bugfix-Incomplete-extraction-of-icy-metadata-causes-.patch.txt
• A debug/verification patch that traces proper operation:
  0002-Bugfix-icy-metadata-for-testing-only-verify-operatio.patch.txt
• A 'pokyized' version of the above that I applied to the existing squeezeos source tree to build the test jive binary:
  00xx-poky-icy-fix-debug-version.patch.txt

I have tested both on desktop Squeezeplay on macOS, and on a Radio with a custom jive binary.

Typical log output from the debug/verification version is as follows:

Dec  8 00:22:22 squeezeplay: INFO   audio.decode - streambuf_icy_filter:393 ICY: Caught defect
Dec  8 00:22:22 squeezeplay: INFO   audio.decode - streambuf_icy_filter:397 ICY: Stream buf read ptr should be 0, it is 0
Dec  8 00:22:22 squeezeplay: INFO   audio.decode - streambuf_icy_filter:401 ICY: Recovered from defect: icy metadata: StreamTitle='Ludwig van Beethoven - Symphony No.6 in F major Opus 68 (2)';StreamUrl='';UTC='20201208T002157.047';
<snip>
Dec  8 04:21:34 squeezeplay: INFO   audio.decode - streambuf_icy_filter:393 ICY: Caught defect
Dec  8 04:21:34 squeezeplay: INFO   audio.decode - streambuf_icy_filter:397 ICY: Stream buf read ptr should be 0, it is 0
Dec  8 04:21:34 squeezeplay: INFO   audio.decode - streambuf_icy_filter:401 ICY: Recovered from defect: icy metadata: StreamTitle='Franz Schubert, Schubert Ensemble - Piano Quintet in A major D.667 (4)';StreamUrl='';UTC='20201208T042107.547';
<snip>
Dec  8 09:12:42 squeezeplay: INFO   audio.decode - streambuf_icy_filter:393 ICY: Caught defect
Dec  8 09:12:42 squeezeplay: INFO   audio.decode - streambuf_icy_filter:397 ICY: Stream buf read ptr should be 0, it is 0
Dec  8 09:12:42 squeezeplay: INFO   audio.decode - streambuf_icy_filter:401 ICY: Recovered from defect: icy metadata: StreamTitle='Gustav Holst - `In the bleak mid-winter.`

This was generated on a Radio, playing out this continuous stream: http://media-ice.musicradio.com/ClassicFMMP3.

I will add that changing STREAMBUF_SIZE in streambuf.c from 3MB to, say, 150k, makes for a much more effective test session, because the incidence rate is increased about 20-fold.

Let me know if you would be interested in a receiving a PR.

Thanks for offering to create a PR but it's not necessary.

I'll have a play with the patches over the weekend and can just apply the 0001-Bugfix-Incomplete-extraction-of-icy-metadata-causes-.patch file to the squeezeplay sources if everything appears to be okay.

[bayard1music]

Thanks for offering to create a PR but it's not necessary.

I'll have a play with the patches over the weekend and can just apply the 0001-Bugfix-Incomplete-extraction-of-icy-metadata-causes-.patch file to the squeezeplay sources if everything appears to be okay.

Quick update.

Since switching to the LBC radio aac stream we've not experienced a single reboot. I've had a couple of instances of a 'buffering' message following by 'rebuffering failed' . There's typically silence during this period. But at least no reboots so far.

Thanks again.

[mrw]

Quick update.

Since switching to the LBC radio aac stream we've not experienced a single reboot. I've had a couple of instances of a 'buffering' message following by 'rebuffering failed' . There's typically silence during this period. But at least no reboots so far.

I'm glad you've got somewhere. I still think that your success from switching to the aac stream may be a bit of a fluke. If the reboot problem does recur, setting 'Proxied streaming' as outlined in my earlier post should deal with the point.

[bayard1music]

I'm glad you've got somewhere. I still think that your success from switching to the aac stream may be a bit of a fluke. If the reboot problem does recur, setting 'Proxied streaming' as outlined in my earlier post should deal with the point.

Hello,

Thanks for the comment.

Is there no clue as to what is causing these perhaps 'previous reboots' in the messages about buffering ? Why might I see such messages on screen ?

It happens that this unit is connected to my network on a Devolo Ethernet over Mains adaptor (1Gb/s) , with a reported 200Mb/s nominal bit stream at the point of the radio. Always been a bit worried about these devices , but WiFi is weak in the kitchen. I may have also mentioned that I've seen the radio historically reboot in my home office which uses a direct ethernet/router/switch connection.

Things have improved since switching to the aac stream in my view. No other known changes have taken place.

[mrw]

I've got two Squeezebox Radios, although only one use at any one time.

I get occasional reboots whilst listening typically to a National Talk radio station here in the UK. By reboot, the screen reverts to the normal Logitech symbol and the radio starts from fresh. I've caught the radio pausing and seeing the 'buffering' message on screen just prior to a reboot. Just pulling the RJ45 cablel does not produce a reboot.
<snipped>

Is there no clue as to what is causing these perhaps 'previous reboots' in the messages about buffering ? Why might I see such messages on screen ?

The rebuffering and the rebooting are not connected, as far as I can see. As a direct result of your original post, we have identified a hitherto unknown defect in the Radio firmware, (and other Squeezeplay devices), that causes it to mishandle ICY metadata, leading to a reboot of the Radio. And I have offered a work around for that.

The Radio (and other Squeezeplay devices) is also known to spontaneously reboot after about three weeks of being on, due to another issue in the firmware.

Rebuffering will occur if, for whatever reason, the connection is lost/flaky between the Radio and the source of the stream. There could be many reasons for that. One reason is if the remote server simply hangs up on you, perhaps after some hours of service. I did notice this happening on the Classic FM stream, and I imagine the LBC stream would do the same. They are both provided by the same entity (Global Radio).

So, if your rebuffering typically arises after some hours of continuous playback, I would be minded to suspect that the remote server has simply hung up on you. The Radio will, nevertheless, attempt a reconnection, and, in my experience, succeed.

There are always other possibilities.

[ralphy]

We've released updated firmware for the Radio, Touch and Controller along with an LMS plugin to automatically download the new firmware.

The firmware includes the 0001-Bugfix-Incomplete-extraction-of-icy-metadata-causes-.patch discussed in this thread, as well as several other fixes from mrw and others.

Full change details are available in the new firmware thread.