bayard1music wrote: > 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/showthread.php?113309-Squeezebox-Radios-Reboots-with-talk-radio-in-the-UK-cable-connected-cable-connect&p=997277&viewfull=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. [3] I reckon each fragment of metadata is about 80 bytes in size, and is delivered every 8,000 bytes. ------------------------------------------------------------------------ mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113309 _______________________________________________ Radio mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/radio
