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

[slartibartfast]

tail -F /var/log/messages

is probably your best bet when logged in. It will give a rolling output. Ctrl C to stop.

But I'm much less sure of my hypothesis, now, see EDIT to earlier post. I may have inadvertently mislead myself, and you might be wasting your time following up. Nevertheless having a bit of a buffer in hand might still be helpful.

SCP should work if you get the command line right. I would do something like:

scp root@myradio:/var/log/messages SBRmessages.txt

to get it into a local file named 'SBRmessages.txt'. It will/should prompt for a password. I don't know about WinSCP.

I just tried an old version of WinSCP from 2013 and that works perfectly.

Sent from my Pixel 3a using Tapatalk

[slartibartfast]

Or perhaps not.

What is easy to overlook is "how stressed" the Radio seems to be when decoding aac streams. I've never looked into it in any detail, but an indication can be obtained by setting the 'audio.decode' logging level on the Radio to debug. You'll see a line, each second, looking like:

Jan  7 15:01:52 squeezeplay: INFO   audio.decode - Playback.lua:447 0.2%/66.0%

The first number is the proportion of the stream buffer available to be filled, i.e. by fetching from the server. The second number is the proportion of the output buffer occupied by decoded samples waiting to be played out.

When playing aac streams, particularly high bit rate streams from the BBC (R3 aac @ 320k), that first number generally seems to stay in the 0%->2% range. This is true both with the 'old/stock' firmware and its 'private' aac decoder, and with the 'new' firmware. SqueezePlay will not fetch any audio stream data from the server (either LMS or a remote server) while the decoder is running.

Compare this with, say, a Touch (I don't have one, so I can't, but would be interested to see the results), or an MP3 stream.

I hypothesize that the fact that the stream buffer is being scarcely filled adversely influences the Radio's resilience to stream interruption and/or temporary glitches.
EDIT: Well, the "low" level of stream buffer fullness also seems to be true for some MP3 streams as well. So perhaps not that much of an issue, really.

It's possible that matters might be improved by increasing the 'decodeThreshold'. At present it seems to be set at 2,048 bytes, meaning that the decoder will start as soon as 2,048 bytes are available. But the stream buffer doesn't really seem have the chance to fill. It might be worth experimenting to see if increasing it (for aac streams) to a substantially larger number might help resilience. I might give that a go at some point.

FWIW these are my figures

Jan  7 17:12:58 squeezeplay: INFO   audio.decode - Playback.lua:448 9.1%/5.6%
Jan  7 17:12:59 squeezeplay: INFO   audio.decode - Playback.lua:448 10.0%/7.5%
Jan  7 17:13:00 squeezeplay: INFO   audio.decode - Playback.lua:448 7.2%/19.7%
Jan  7 17:13:01 squeezeplay: INFO   audio.decode - Playback.lua:448 4.3%/31.4%
Jan  7 17:13:02 squeezeplay: INFO   audio.decode - Playback.lua:448 10.8%/34.8%
Jan  7 17:13:03 squeezeplay: INFO   audio.decode - Playback.lua:448 8.6%/42.4%
Jan  7 17:13:05 squeezeplay: INFO   audio.decode - Playback.lua:448 6.6%/47.0%
Jan  7 17:13:06 squeezeplay: INFO   audio.decode - Playback.lua:448 4.8%/51.4%
Jan  7 17:13:07 squeezeplay: INFO   audio.decode - Playback.lua:448 2.7%/55.9%
Jan  7 17:13:08 squeezeplay: INFO   audio.decode - Playback.lua:448 0.7%/60.9%
Jan  7 17:13:09 squeezeplay: INFO   audio.decode - Playback.lua:448 7.5%/60.5%
Jan  7 17:13:10 squeezeplay: INFO   audio.decode - Playback.lua:448 5.7%/64.8%
Jan  7 17:13:11 squeezeplay: INFO   audio.decode - Playback.lua:448 3.8%/69.1%
Jan  7 17:13:12 squeezeplay: INFO   audio.decode - Playback.lua:448 2.0%/73.3%
Jan  7 17:13:13 squeezeplay: INFO   audio.decode - Playback.lua:448 0.1%/77.2%
Jan  7 17:13:14 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/66.1%
Jan  7 17:13:15 squeezeplay: INFO   audio.decode - Playback.lua:448 7.0%/65.4%
Jan  7 17:13:16 squeezeplay: INFO   audio.decode - Playback.lua:448 5.1%/69.8%
Jan  7 17:13:18 squeezeplay: INFO   audio.decode - Playback.lua:448 3.1%/74.6%
Jan  7 17:13:19 squeezeplay: INFO   audio.decode - Playback.lua:448 1.3%/79.2%
Jan  7 17:13:20 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/78.6%
Jan  7 17:13:21 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/66.0%
Jan  7 17:13:22 squeezeplay: INFO   audio.decode - Playback.lua:448 6.6%/68.3%
Jan  7 17:13:23 squeezeplay: INFO   audio.decode - Playback.lua:448 4.1%/78.9%
Jan  7 17:13:24 squeezeplay: INFO   audio.decode - Playback.lua:448 1.5%/89.3%
Jan  7 17:13:25 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/91.5%
Jan  7 17:13:26 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/79.7%
Jan  7 17:13:27 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/68.7%
Jan  7 17:13:28 squeezeplay: INFO   audio.decode - Playback.lua:448 7.2%/65.7%
Jan  7 17:13:29 squeezeplay: INFO   audio.decode - Playback.lua:448 5.3%/70.1%
Jan  7 17:13:30 squeezeplay: INFO   audio.decode - Playback.lua:448 3.5%/73.8%
Jan  7 17:13:32 squeezeplay: INFO   audio.decode - Playback.lua:448 0.8%/79.4%
Jan  7 17:13:33 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/73.7%
Jan  7 17:13:34 squeezeplay: INFO   audio.decode - Playback.lua:448 5.6%/65.5%
Jan  7 17:13:35 squeezeplay: INFO   audio.decode - Playback.lua:448 5.7%/70.2%
Jan  7 17:13:36 squeezeplay: INFO   audio.decode - Playback.lua:448 3.9%/75.1%
Jan  7 17:13:37 squeezeplay: INFO   audio.decode - Playback.lua:448 2.0%/80.2%
Jan  7 17:13:38 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/84.9%
Jan  7 17:13:39 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/73.1%
Jan  7 17:13:40 squeezeplay: INFO   audio.decode - Playback.lua:448 1.8%/63.1%
Jan  7 17:13:41 squeezeplay: INFO   audio.decode - Playback.lua:448 6.3%/65.6%
Jan  7 17:13:43 squeezeplay: INFO   audio.decode - Playback.lua:448 4.3%/71.0%
Jan  7 17:13:44 squeezeplay: INFO   audio.decode - Playback.lua:448 1.7%/79.5%
Jan  7 17:13:45 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/81.5%
Jan  7 17:13:46 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/69.5%
Jan  7 17:13:47 squeezeplay: INFO   audio.decode - Playback.lua:448 5.4%/62.0%
Jan  7 17:13:48 squeezeplay: INFO   audio.decode - Playback.lua:448 5.9%/65.3%
Jan  7 17:13:49 squeezeplay: INFO   audio.decode - Playback.lua:448 3.9%/70.0%

[mrw]

FWIW these are my figures]

Distinctly "healthier" than what I was seeing. If "health" correlates to >2% stream buffer fullness. You seem to vary from 0% to 6/7%.
What stream is being played ? Presumably this is on a Radio.

[expectingtofly]

Or perhaps not.

What is easy to overlook is "how stressed" the Radio seems to be when decoding aac streams. I've never looked into it in any detail, but an indication can be obtained by setting the 'audio.decode' logging level on the Radio to debug. You'll see a line, each second, looking like:

Jan  7 15:01:52 squeezeplay: INFO   audio.decode - Playback.lua:447 0.2%/66.0%

The first number is the proportion of the stream buffer available to be filled, i.e. by fetching from the server. The second number is the proportion of the output buffer occupied by decoded samples waiting to be played out.

When playing aac streams, particularly high bit rate streams from the BBC (R3 aac @ 320k), that first number generally seems to stay in the 0%->2% range. This is true both with the 'old/stock' firmware and its 'private' aac decoder, and with the 'new' firmware. SqueezePlay will not fetch any audio stream data from the server (either LMS or a remote server) while the decoder is running.

Compare this with, say, a Touch (I don't have one, so I can't, but would be interested to see the results), or an MP3 stream.

I hypothesize that the fact that the stream buffer is being scarcely filled adversely influences the Radio's resilience to stream interruption and/or temporary glitches.
EDIT: Well, the "low" level of stream buffer fullness also seems to be true for some MP3 streams as well. So perhaps not that much of an issue, really.

It's possible that matters might be improved by increasing the 'decodeThreshold'. At present it seems to be set at 2,048 bytes, meaning that the decoder will start as soon as 2,048 bytes are available. But the stream buffer doesn't really seem have the chance to fill. It might be worth experimenting to see if increasing it (for aac streams) to a substantially larger number might help resilience. I might give that a go at some point.

Yes, that is what I am finding. I have had a look at this today. I can make things better by optimising the BBC sounds operation as much as possible (waiting a bit longer before checking for meta data for the first time), but I can't eliminate the buffer underruns all together. Putting extra stress on the radio (for example when the BBC Sounds tells it that the meta data has updated, especially that the track duration has updated) seems to put it in a position where a buffer underrun is likely. It seems to cause a gap where it stops asking the server for more data (even though there is plenty of data available) triggering the underrun. This doesn't happen when a transcoded flac stream is provided.

I do seem to have got to the stage where I can only trigger buffer underruns at the start of a stream though, so its probably only a minor inconvenience to the user. I'll include the changes in the next release. As you say, there may be configurations that can be made to the AAC decoder to make it better also.

[slartibartfast]

Distinctly "healthier" than what I was seeing. If "health" correlates to >2% stream buffer fullness. You seem to vary from 0% to 6/7%.
What stream is being played ? Presumably this is on a Radio.

Radio 2 live on a Radio.

Sent from my Pixel 3a using Tapatalk

[mrw]

Distinctly "healthier" than what I was seeing. If "health" correlates to >2% stream buffer fullness. You seem to vary from 0% to 6/7%.
What stream is being played ? Presumably this is on a Radio.

I will add that when I play out BBC Radio 3 from BBC Sounds app I also see distinctly "healthier" stream buffer fullness. In distinct contrast to playing the BBC Radio 3 stream directly from the BBC. So @expectingtofly's comment about masses of buffering might be in play !

It seems to cause a gap where it stops asking the server for more data (even though there is plenty of data available) triggering the underrun. This doesn't happen when a transcoded flac stream is provided.

I noticed, yesterday, that background images seemed slow to transition. Is there a way to see what metadata is being sent, and figure out how this is impacting the Radio ?

Does this dialogue belong to a different thread ? Perhaps the BBC Sounds App thread. I'm not convinced that this is a "new firmware" issue, but I could easily be wrong.

[ralphy]

Compare this with, say, a Touch (I don't have one, so I can't, but would be interested to see the results), or an MP3 stream.

The only AAC-320 stream I could find was radio paradise. From my touch 8.0.1r16824.

Jan  7 14:34:17 squeezeplay: INFO   audio.decode - Playback.lua:477 connect 23.227.160.206:80 GET /aac-320 HTTP/1.0^M
Jan  7 14:34:17 squeezeplay: INFO   audio.decode - Playback.lua:480 GET /aac-320 HTTP/1.0^M
Jan  7 14:34:17 squeezeplay: Cache-Control: no-cache^M
Jan  7 14:34:17 squeezeplay: Connection: close^M
Jan  7 14:34:17 squeezeplay: Accept: */*^M
Jan  7 14:34:17 squeezeplay: Host: stream.radioparadise.com^M
Jan  7 14:34:17 squeezeplay: Range: bytes=0-^M
Jan  7 14:34:17 squeezeplay: User-Agent: iTunes/4.7.1 (Linux; N; Debian; i686-linux; EN; utf8) SqueezeCenter, Squeezebox Server, Logitech Media Server/8.1.1/git-e64c0e31c^M
Jan  7 14:34:17 squeezeplay: Icy-MetaData: 1^M
Jan  7 14:34:17 squeezeplay: ^M
Jan  7 14:34:17 squeezeplay: DEBUG  audio.decode - Playback.lua:194 source=stream
Jan  7 14:34:17 squeezeplay: DEBUG  audio.decode - stream_connectL:506 streambuf connect 23.227.160.206:80
Jan  7 14:34:17 squeezeplay: DEBUG  audio.decode - Playback.lua:1262 stopping local pause timer
Jan  7 14:34:17 squeezeplay: DEBUG  audio.decode - Playback.lua:1192 gainL, gainR: 555 555
Jan  7 14:34:17 squeezeplay: DEBUG  audio.decode - Playback.lua:1037 cont loop=0 icy=16000
Jan  7 14:34:17 squeezeplay: DEBUG  audio.decode - Playback.lua:397 resume decoder, 5084 bytes buffered, decode threshold 2048
Jan  7 14:34:17 squeezeplay: DEBUG  audio.decode - decode_resume_decoder:580 decode_resume_decoder
Jan  7 14:34:17 squeezeplay: DEBUG  audio.decode - decode_resume_decoder_handler:122 resume_decoder decode state: 1 audio state 0
Jan  7 14:34:17 squeezeplay: DEBUG  audio.decode - debug_fullness:112 fullness: 5084 / 0 | 0.16% / 0.00%
Jan  7 14:34:17 squeezeplay: DEBUG  audio.decode - decode_output_samples:279 first buffer sample_rate=44100
Jan  7 14:34:17 squeezeplay: INFO   audio.decode - Playback.lua:448 0.6%/0.5%
Jan  7 14:34:17 squeezeplay: DEBUG  audio.decode - streambuf_icy_filter:390 got icy metadata: StreamTitle='Leon Russell - Stranger in a Strange Land';StreamUrl='http://img.radioparadise.com/covers/l/B000002TYO.jpg';
Jan  7 14:34:18 squeezeplay: DEBUG  audio.decode - Playback.lua:424 resume audio bytesReceivedL=57212 outputTime=371 threshold=20480
Jan  7 14:34:18 squeezeplay: DEBUG  audio.decode - decode_resume_audio:601 decode_resume_audio start_jiffies=0
Jan  7 14:34:18 squeezeplay: DEBUG  audio.decode - decode_resume_audio_handler:133 decode_resume_audio_handler start_jiffies=0
Jan  7 14:34:18 squeezeplay: DEBUG  audio.decode - debug_fullness:112 fullness: 84557 / 139264 | 2.69% / 3.95%
Jan  7 14:34:18 squeezeplay: DEBUG  audio.decode - decode_resume_audio_handler:146 resume_audio decode state: 1 audio state 40
Jan  7 14:34:18 squeezeplay: DEBUG  audio.decode - Playback.lua:381 status TRACK STARTED (elapsed: 15)
Jan  7 14:34:21 squeezeplay: INFO   applet.NowPlaying - NowPlayingApplet.lua:422 enable volume UI in NP
Jan  7 14:34:22 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/64.3%
Jan  7 14:34:23 squeezeplay: INFO   audio.decode - Playback.lua:448 2.5%/74.2%
Jan  7 14:34:24 squeezeplay: INFO   audio.decode - Playback.lua:448 0.9%/87.5%
Jan  7 14:34:25 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/95.6%
Jan  7 14:34:26 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/94.8%
Jan  7 14:34:27 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/94.6%
Jan  7 14:34:28 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/95.7%
Jan  7 14:34:29 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/96.0%
Jan  7 14:34:30 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/95.2%
Jan  7 14:34:31 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/94.8%
Jan  7 14:34:32 squeezeplay: INFO   audio.decode - Playback.lua:448 0.2%/94.4%
Jan  7 14:34:33 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/95.4%
Jan  7 14:34:34 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/95.3%
Jan  7 14:34:36 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/95.1%
Jan  7 14:34:37 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/95.3%
Jan  7 14:34:38 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/95.2%
Jan  7 14:34:39 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/94.7%
Jan  7 14:34:40 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/95.2%
Jan  7 14:34:41 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/95.5%
Jan  7 14:34:42 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/94.9%
Jan  7 14:34:43 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/95.1%
Jan  7 14:34:44 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/94.6%
Jan  7 14:34:45 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/94.9%
Jan  7 14:34:47 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/94.6%

From Radio 2 Live via BBC Sounds plugin v2.9.1 on the touch

Jan  7 14:39:14 squeezeplay: DEBUG  audio.decode - decode_start:705 decode_start
Jan  7 14:39:14 squeezeplay: INFO   audio.decode - decode_start_handler:281 init decoder aac
Jan  7 14:39:14 squeezeplay: DEBUG  audio.decode - decode_output_set_track_gain:517 Track gain 65536
Jan  7 14:39:14 squeezeplay: DEBUG  audio.decode - decode_output_set_track_gain:521 Track clip range 7fffffff 80000000
Jan  7 14:39:14 squeezeplay: DEBUG  audio.decode - decode_set_track_polarity_inversion:526 Polarity inversion 0
Jan  7 14:39:14 squeezeplay: DEBUG  audio.decode - decode_set_output_channels:534 Output channels left 0, right 0
Jan  7 14:39:14 squeezeplay: INFO   audio.decode - Playback.lua:477 connect 192.168.100.22:9000 GET /stream.mp3?player=00:04:20:xx:xx:xx HTTP/1.0^M
Jan  7 14:39:14 squeezeplay: DEBUG  audio.decode - Playback.lua:194 source=stream
Jan  7 14:39:14 squeezeplay: DEBUG  audio.decode - stream_connectL:506 streambuf connect 192.168.100.22:9000
Jan  7 14:39:14 squeezeplay: DEBUG  audio.decode - Playback.lua:1262 stopping local pause timer
Jan  7 14:39:14 squeezeplay: DEBUG  audio.decode - Playback.lua:1192 gainL, gainR: 555 555
Jan  7 14:39:15 squeezeplay: DEBUG  audio.decode - Playback.lua:397 resume decoder, 77991 bytes buffered, decode threshold 2048
Jan  7 14:39:15 squeezeplay: DEBUG  audio.decode - decode_resume_decoder:580 decode_resume_decoder
Jan  7 14:39:15 squeezeplay: DEBUG  audio.decode - decode_resume_decoder_handler:122 resume_decoder decode state: 1 audio state 0
Jan  7 14:39:15 squeezeplay: DEBUG  audio.decode - debug_fullness:112 fullness: 77991 / 0 | 2.48% / 0.00%
Jan  7 14:39:15 squeezeplay: DEBUG  audio.decode - decode_output_samples:279 first buffer sample_rate=48000
Jan  7 14:39:15 squeezeplay: DEBUG  audio.decode - Playback.lua:424 resume audio bytesReceivedL=77991 outputTime=213 threshold=61440
Jan  7 14:39:15 squeezeplay: DEBUG  audio.decode - decode_resume_audio:601 decode_resume_audio start_jiffies=0
Jan  7 14:39:15 squeezeplay: INFO   audio.decode - Playback.lua:448 1.7%/2.3%
Jan  7 14:39:15 squeezeplay: DEBUG  audio.decode - decode_resume_audio_handler:133 decode_resume_audio_handler start_jiffies=0
Jan  7 14:39:15 squeezeplay: DEBUG  audio.decode - debug_fullness:112 fullness: 53415 / 98304 | 1.70% / 2.79%
Jan  7 14:39:15 squeezeplay: DEBUG  audio.decode - decode_resume_audio_handler:146 resume_audio decode state: 1 audio state 40
Jan  7 14:39:15 squeezeplay: audio_thread_execute:908 xrun (snd_pcm_wait)
Jan  7 14:39:15 squeezeplay: audio_thread_execute:862 underrun!!! (at least -261744117.285 ms long)
Jan  7 14:39:15 squeezeplay: DEBUG  audio.decode - Playback.lua:381 status TRACK STARTED (elapsed: 71)
Jan  7 14:39:16 squeezeplay: INFO   applet.NowPlaying - NowPlayingApplet.lua:422 enable volume UI in NP
Jan  7 14:39:16 squeezeplay: INFO   audio.decode - Playback.lua:448 2.9%/15.3%
Jan  7 14:39:17 squeezeplay: INFO   applet.NowPlaying - NowPlayingApplet.lua:422 enable volume UI in NP
Jan  7 14:39:18 squeezeplay: INFO   audio.decode - Playback.lua:448 2.1%/23.3%
Jan  7 14:39:19 squeezeplay: INFO   audio.decode - Playback.lua:448 1.4%/29.4%
Jan  7 14:39:20 squeezeplay: INFO   audio.decode - Playback.lua:448 0.8%/35.6%
Jan  7 14:39:21 squeezeplay: INFO   audio.decode - Playback.lua:448 0.1%/41.5%
Jan  7 14:39:22 squeezeplay: INFO   audio.decode - Playback.lua:448 2.2%/41.6%
Jan  7 14:39:23 squeezeplay: INFO   audio.decode - Playback.lua:448 1.6%/47.3%
Jan  7 14:39:24 squeezeplay: INFO   audio.decode - Playback.lua:448 0.9%/54.4%
Jan  7 14:39:25 squeezeplay: INFO   audio.decode - Playback.lua:448 0.3%/59.9%
Jan  7 14:39:26 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/54.4%
Jan  7 14:39:27 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/43.3%
Jan  7 14:39:28 squeezeplay: INFO   audio.decode - Playback.lua:448 2.0%/48.6%
Jan  7 14:39:29 squeezeplay: INFO   audio.decode - Playback.lua:448 1.3%/55.0%
Jan  7 14:39:31 squeezeplay: INFO   audio.decode - Playback.lua:448 0.5%/61.1%
Jan  7 14:39:32 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/64.8%
Jan  7 14:39:33 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/53.6%
Jan  7 14:39:34 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/42.3%
Jan  7 14:39:35 squeezeplay: INFO   audio.decode - Playback.lua:448 1.8%/47.9%
Jan  7 14:39:36 squeezeplay: INFO   audio.decode - Playback.lua:448 1.2%/54.7%
Jan  7 14:39:37 squeezeplay: INFO   audio.decode - Playback.lua:448 0.5%/61.1%
Jan  7 14:39:38 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/62.7%
Jan  7 14:39:39 squeezeplay: INFO   audio.decode - Playback.lua:448 0.0%/51.0%

[expectingtofly]

I will add that when I play out BBC Radio 3 from BBC Sounds app I also see distinctly "healthier" stream buffer fullness. In distinct contrast to playing the BBC Radio 3 stream directly from the BBC. So @expectingtofly's comment about masses of buffering might be in play !



I noticed, yesterday, that background images seemed slow to transition. Is there a way to see what metadata is being sent, and figure out how this is impacting the Radio ?

Does this dialogue belong to a different thread ? Perhaps the BBC Sounds App thread. I'm not convinced that this is a "new firmware" issue, but I could easily be wrong.

I've done some further tracing.
Both old and new firmware are getting the data quite happily from the BBC Sounds protocol handler. They both ask for 32768 Bytes at a time. The BBC data is available in 6.4 second chunks and it gets that in a sprightly 0.3 of a second in 8 separate calls.
There is usually 13 seconds of data available within a couple of seconds when it starts streaming, so there is no problem it getting the data to play out.

I just think that 320kbps 48hz aac is on the edge of what these radios can support to decode, in terms of processor power. The old private decoder might have just been slightly more efficient at it. No worries it is still perfectly fine most of the time. If any one mentions it as a problem, I'll just suggest decode to flac, as this BBC streams need to be streamed from a server anyway.



The first number is the amount of data asked for, the second number is the amount of data available. This is a new audio chunk, so 6.4 seconds of audio that it retrieves in 0.3 seconds.
The above trace is from the new firmware, the old firmware behaves identically.

[JJZolx]

Can the firmware be just be downloaded manually into the LMS folder? I'd like to get it upgraded and done with.

[slartibartfast]

I've done some further tracing.
Both old and new firmware are getting the data quite happily from the BBC Sounds protocol handler. They both ask for 32768 Bytes at a time. The BBC data is available in 6.4 second chunks and it gets that in a sprightly 0.3 of a second in 8 separate calls.
There is usually 13 seconds of data available within a couple of seconds when it starts streaming, so there is no problem it getting the data to play out.

I just think that 320kbps 48hz aac is on the edge of what these radios can support to decode, in terms of processor power. The old private decoder might have just been slightly more efficient at it. No worries it is still perfectly fine most of the time. If any one mentions it as a problem, I'll just suggest decode to flac, as this BBC streams need to be streamed from a server anyway.

[ATTACH]32888[/ATTACH]

The first number is the amount of data asked for, the second number is the amount of data available. This is a new audio chunk, so 6.4 seconds of audio that it retrieves in 0.3 seconds.
The above trace is from the new firmware, the old firmware behaves identically.

Any idea why some experience stuttering and others don't?

Sent from my Pixel 3a using Tapatalk

[ralphy]

Can the firmware be just be downloaded manually into the LMS folder? I'd like to get it upgraded and done with.

Yes, the current community firmware 8.0.1r16824 is available at https://sourceforge.net/projects/lms...les/squeezeos/.

[avr300]

Since I followed your instruction to enable the blue icon every time there has been a short disconnection the icon has been red so it probably isn't critical to have. Did blue mean connected to WiFi/network but not connected to LMS?

Sent from my Pixel 3a using Tapatalk

Yes, blue icon means connected to wifi but no connection to the selected LMS.

It works as expected in Version 8.0.1 r16824

[mherger]

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

> Yes, the current community firmware 8.0.1r16824 is available at
> https://sourceforge.net/projects/lms...les/squeezeos/.

Did you release a new build recently? A few of my devices offered
another update today.

--

Michael

[ralphy]

> Yes, the current community firmware 8.0.1r16824 is available at
> https://sourceforge.net/projects/lms...les/squeezeos/.

Did you release a new build recently? A few of my devices offered
another update today.

--

Michael

Yes. Martin and I fixed a few issues with the previous release. The changelog lists what's new.

I've only made the new release available for LMS 8.1.1 (nightly) and 8.2.0 (dev).

LMS 8.0.1 and 8.1.0 are still on the older build. I hope to encourage the community to keep their LMS up to date with at least the stable release of LMS.

I can update the older releases as well, if you'd prefer.

[slartibartfast]

Yes, blue icon means connected to wifi but no connection to the selected LMS.

It works as expected in Version 8.0.1 r16824

You just made me realise there was an update [emoji3]

Sent from my Pixel 3a using Tapatalk