Unbearable rebuffering with poor quality internet radio streams (7.7.1)

[nicolas75]

Squeezeboxes have always had a lot of problems with bad quality radio streams.
However it seems worse with 7.7.1 than with previous versions.

There was this bug http://bugs.slimdevices.com/show_bug.cgi?id=3161 , now closed, which was about replay simply stopping when there is a problem.

During last days, I was listening to some internet radio streams with temporarily bad quality.
Those were almost impossible to listen with Squeezebox Touch.
You get several seconds rebuffering about every minute or so.

I was curious to try to listen to the same stream with PC players (MediaMonkey, Foobar, etc ...)
With those softwares, you can hear some artefacts sometimes, but you can really listen to the stream without real annoyance.
At the same time, I could see the rebuffering messages on the Touch screen, showing that you cannot listen to the stream with the Touch without getting mad ...

Is there some testing done from Logitech development, as far as radio streams stability is concerned ?

It should not be that hard to generate on purpose a not perfect mp3 stream, and see if squeezeboxes behavior is acceptable.

(Touch is wired, internet connection excellent, this is the stream which is sometimes unstable).

[bpa]

Have you tried increasing the "Radio Station Buffer Seconds" ? It increases startup time but it may help smooth over a lumpy internet streams.

[nicolas75]

Have you tried increasing the "Radio Station Buffer Seconds" ? It increases startup time but it may help smooth over a lumpy internet streams.

No, but the behavior is so bad compared to PC players replay that it cannot be only a matter of LMS settings.
Since replay is stopped during rebuffering, I would even think that increasing this number should make things even worse.

[aubuti]

No, but the behavior is so bad compared to PC players replay that it cannot be only a matter of LMS settings.
Since replay is stopped during rebuffering, I would even think that increasing this number should make things even worse.

The setting specifies the number of seconds of audio held in the buffer. So increasing the number of seconds increases the size of the buffer, and therefore decreases the interruptions. That is, if the stream is interrupted, there is more audio in the buffer to keep playing until the stream resumes.

The default setting in LMS is 3 seconds. If MM, foobar2K or others have larger buffers that would easily explain the different behavior.

[nicolas75]

That is, if the stream is interrupted, there is more audio in the buffer to keep playing until the stream resumes.

This is exactly why I said that I expect that increasing this number will make things even worse ...
[Edit : more audio in the buffer means more seconds needed to rebuffer, and since replay is stopped while rebuffering ...]

[nicolas75]

If MM, foobar2K or others have larger buffers that would easily explain the different behavior.

Those softwares obviously don't work in the exact same way (which cannot give good results).
They do not stop replay while rebuffering occurs.

[aubuti]

This is exactly why I said that I expect that increasing this number will make things even worse ...
[Edit : more audio in the buffer means more seconds needed to rebuffer, and since replay is stopped while rebuffering ...]

Replay stops when the buffer is empty. If you have a bigger buffer, there is less chance of the buffer becoming empty.

Have you tried increasing the internet radio buffer size? What stream is it that is giving you problems?

[nicolas75]

Replay stops when the buffer is empty. If you have a bigger buffer, there is less chance of the buffer becoming empty.

Have you tried increasing the internet radio buffer size? What stream is it that is giving you problems?

When the stream is bad, you will necesseraly experience rebuffering.
Increase the buffer, and you well get rebuffering every 3 (or whatever figure depending of the size increase) minutes instead of every minute, and each rebuffering will be awfully long (3 seconds is not acceptable user experience, it is too long).


The problem is not the size of the buffer, the problem is that replay stops during rebuffering.
This is a well known problem for streaming software developpers.

[bpa]

When the stream is bad, you will necesseraly experience rebuffering.
Increase the buffer, and you well get rebuffering every 3 (or whatever figure depending of the size increase) minutes instead of every minute, and each rebuffering will be awfully long (3 seconds is not acceptable user experience, it is too long).


The problem is not the size of the buffer, the problem is that replay stops during rebuffering.
This is a well known problem for streaming software developpers.

Not necessarily - if the source is overloaded and it gives bursts of audio say of about 10 secs burst once every 8-10 secs, if your buffer setting is 15 secs it will play smoothly but if your buffer setting is 5 secs it will stop.

Stations which play in realtime (i.e. live broadcast) will always give problems as they have to resync with realtime every so often. For example, if stream gets behind realtime by say 10 secs due to network load and stations has to give a time signal at x O'clock for news, the station will drop packets in the audio stream.

[nicolas75]

Well, Foobar buffer length is 1000 ms on my computer.
I can't remember having ever heard 1 second abrupt silence while listening radio stream with Foobar, and I guess you can hardly miss it if it happens.

Today I listened to the same stream, switching between Foobar, MediaMonkey and Squeezebox Touch.

the result was

- some audio artefacts showing poor stream with Foobar and MediaMonkey, but nothing really preventing you from acceptable listening, and no abrupt silence whatsoever.

- Unbearable rebuffering, lasting several seconds (replay completely stops meanwhile), at least once a minute, often even more frequent, with the Touch.

I have been using Squeezeboxes for several years, and started before Logitech aquired Slimdevices.
The 2 main problems with squeezeboxes have always been

1/ scanning reliability
2/ rebuffering problems


I can hardly imagine LMS is tested against poor streams in order to check its reliability.
Is there really some basic testing done concerning rebuffering before public release ?