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 ?

[gerph]

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.

This depends, partly, on the protocol used to deliver the stream. If the streaming protocol allows for missing sections of data (such as delivery by UDP), or changes its delivery based on performance (such as adaptive rate streaming), then these problems occur less, but this is not usually the case with radio stations. Knowing what station you were having problems with, and therefore what the protocol used for delivery was, would help to identify if either of these are the issue.

However, for HTTP based streaming - which is common, whether it utilises the plain HTTP stream or the ICY variant - this is TCP based, so the former method used to skip data isn't possible. Except by stream reconnection, and that usually results in a greater interruption due to the streams being desynchronised (possibility of repeating or skipping sections), and TCP having a slower start due to its own connection and protocol. Plus, if the problem is at the local end, initiating a secondary connection will slow the first, exacerbating the problem.

You suggest in your first comment that the problem is a corrupt MP3 stream. If the stream were corrupt, then that is an issue for the source to address, and its much less likely that the player is at fault. Corrupt MP3s can produce rebuffering indications and the like, but you are far more likely to hear blips and squeals in the audio than see rebuffering indications.

Your last comment suggests a lack of understanding of the process is used during the playback, and the way that players handle bursty or otherwise bad connections - if its just the phrasing that I've taken the wrong way then I'm sorry. Streaming players are always buffering data as it arrives. There may be multiple layers of buffering taking place which affect the stream. For example, TCP based connections (such as those used by HTTP) have their own internal buffers (so do UDP, but I'm focusing on the TCP as HTTP is more common and it follows to the next point).

The internal TCP buffers can be varying sizes and are there for 2 reasons - firstly they allow the receiving application to do other things whilst blocks of data are received. Secondly, the allow the data to arrive in different orders and be resequenced. This latter part of sometimes a logically separate buffer to the former, as out-of-order data has NOT (from the player's point of view) been received yet (that's just the way that TCP is - you get everything in order, which is why you cannot skip sections, as you might with UDP based protocols).

So, in the case of a 'bad' stream, you might be experiencing packet drop - if connections in between are dropping packets then only some will arrive at the client and those that are not received will be waited for. If they do not arrive then a 'retransmit request' will be sent to ask for that data. This takes a while - depending on the TCP configuration, the retransmit delay might be a few seconds.

At this point it is important to also include the fact that the 'client' in the streaming may not be the server. In some cases, the Squeezebox itself is capable of performing the streaming itself without the interaction of the server - at least that's what I remember from looking into it some time back and I accept that my memory may be flakey. So it might be important to know which Squeezebox model you are streaming to - I don't know whether the Touch will perform streaming directly or not.

Ok, so you've got TCP buffering involved. Then there is the application level buffering which may be in two forms - input data (how much has just been streamed and needs decoding) and output data (how much is available to play). As the buffer size in the server is measured in seconds, it is reasonable to assume that the buffer being configured is the output buffer.

As the data arrives it is buffered (by TCP and then by the application input buffer).
It is then decoded into playable data and buffered in the output buffer for playback.
When the output buffer is full (to your configured level) playback starts.
All the time the output buffer is draining all the time that playback is happening.
As time progresses more data will arrive - maybe in small bursts either because of delays in delivery or packet loss - and all the time the output buffer is being drained of data as it is playing.

*When the output buffer is empty, playback stops* (and you are usually presented with a 'rebuffering' message)

This is why, as you say "replay stops during rebuffering". There is NO data to play, so there is no way to play anything. As data arrives and reaches your configured buffer size, playback will resume. If you want playback to start sooner, you configure the buffer size *down* - this means that as soon as there is that much data available it will play it. However, when that data runs out, playback will stall, so with a poor connection that could not keep up, you will be interrupted more often. Which is just a fact - if the data coming over the network cannot be delivered sufficiently quickly to keep up with realtime it will always drop out.

If you have a *larger* buffer then any temporary delays in the stream (because of packet loss, or slower delivery) will be smoothed out. The streaming server will attempt to keep up to real time, so the data should (if it was only a /temporary/ delay) catch up later in the stream, thus re-filling the buffers. The larger buffer smooths out the temporarily delayed data. If it never does catch up then the output buffer will drain completely and you'll get a 'Rebuffering' message.

If, for example, you have a 3 second buffer configured then it will take 3 seconds for your stream to start, and you will be running 3 seconds behind real time. If you get a 'rebuffering' message, that means that the stream couldn't keep up with realtime and is now running 3 seconds behind.

There may be issues outside of the buffering which are at fault, but without more information on the station you have problems with, suggesting a change of buffer size is the best bet.

There was a way to see the buffering level, but I cannot seem to find it on my player at the moment - maybe someone else can suggest something. Or maybe it only exists on certain configurations or players.

You suggest that there are other players that "do not stop playing when rebuffering occurs", and as you suggest, these may not work the same way. I would suggest that if they keep playing whilst displaying a 'rebuffering' message what they mean is that their output buffer has drained below a limit and they are now *warning* you that you're running out of data and there is data being buffered.

Alternatively they could have a large output buffer /beyond/ that used by the application. For example, DirectSound might be buffering a few seconds of data, so whilst your PC players have no output data to hand off to the DirectSound system (or equivalent, if you're using a non-Windows system) and are therefore in need of rebuffering, there is still sound coming out of the speakers.

So whilst, yes, those application may be working differently to the Squeezebox - they're merely reporting that they are rebuffering when there it still data available to them, whereas the Squeezebox is reporting that it is rebuffering only at the point that it has actually run out of data.

[nicolas75]

...
You suggest that there are other players that "do not stop playing when rebuffering occurs"
...

Well you gave a tremendous amount of technical explanations, very interesting for technical guys and developers.
The problem is not to explain to squeezeboxes users what is the theory of streaming and protocols.
I can easily understand that stuff, but the point is not to explain "WHY" LMS behavior is not user friendly in this particular case (users don't really care), but to understand that there "IS" a problem with squeezeboxes and rebuffering (at least users can hope the problem may be handled, if it is at least acknowledged).

Rebuffering has always been a big problem with squeezeboxes.

I am not "suggesting" anything.
This afternoon, I experienced for several hours a technical problem on a radio stream I listen almost every day, usually without problems.

It gave me time enough to check that this problem

1/ made the stream awfully unlistenable with Squeezebox.
2/ was not such a big problem with every other mean I tried to listen to it.

So that Squeezebox "IS" the problem there, because it cannot handle faults easily handled by other systems.

My question was not really to find the reason for this problem, but to know if there is some testing done as far as LMS reliability against poor streams is concerned.

Most people having rebuffering problems with squeezeboxes usually get advice suggesting that this is more or less normal, and that it is everything but software "bug" or let's say "user highly unfriendly behavior".

Today I unquestionably checked that LMS Squeezebox Touch has a big problem with a "poor" stream, while popular softwares do not.

The first thing to fix this kind of problem, is not to ask people to provide a testcase they cannot provide, but to start to have some in-house testcase generating "poor" streams , and check against those.

I wonder if this is done at Logitech's, because the behavior I experienced today seems to me a common problem, though usually not that dramatic, which appear again and again on various occasions.

[nicolas75]

You can check here

http://bugs.slimdevices.com/show_bug.cgi?id=3161

that it was really hard to convince technical people that squeezebox behavior was a complete nonsense for any normal user for this bug specific problem (not the same than rebuffering) ...

[toby10]

What station is causing this? What is the stream format? Tried connecting directly to MySB (maybe taking LMS and/or other things out of the loop might help)?
Other Touch users can try it to compare results.

[nicolas75]

What station is causing this? What is the stream format? Tried connecting directly to MySB (maybe taking LMS and/or other things out of the loop might help)?
Other Touch users can try it to compare results.

I tried MySB, TinySBS, LMS, same result

Everything is fine now, problems were especially big and lasted for a long time this afternoon.

Anyway, if you really want the streams I tried

http://mp3.live.tv-radio.com/fip/all/fiphautdebit.mp3

http://mp3.live.tv-radio.com/franceculture/all/franceculturehautdebit.mp3

Once again, the problem is not to find out what went wrong this afternoon for those streams, I don't really care, and it won't really help.

The fact is that streaming is poorly handled by Squeezeboxes, and many many people have been complaining for several years about that.
Rebuffering problems occur in various situations, and people are usually given very specific workaround for specific cases, or simply wait for stream problems to be fixed by the sender.

Today I could check for several hours, a very poor behavior regarding rebuffering, very specific to Squeezeboxes.
I am convinced there is something wrong in the way Squeezeboxes handle streams.
(In the same way there was something wrong with dropped streams in http://bugs.slimdevices.com/show_bug.cgi?id=3161 )
It is not the first time, but it was big enough and lasted long enough, so I had time to try several players, and cannot doubt there is a problem specific to squeezeboxes.