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" ? 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]

Post by nicolas75
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 ...

[aubuti]

Post by nicolas75
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]

Post by aubuti
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]

Post by nicolas75
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]

Post by nicolas75
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]

Post by gerph
...
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 ...

[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]

Post by 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.

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 )

[toby10]

Yeah, neither will play at all for me on WinAmp or LMS. Might be GeoIP
restricted.

[nicolas75]

Post by toby10
Yeah, neither will play at all for me on WinAmp or LMS. Might be GeoIP
restricted.

I don't think so.
The server is probably down, I cannot access them now.

[mike_zandvliet]

I am experiencing the same problems with 7.7.1 and 7.7.2, against a
SqueezeBox2. A lot of radio streams I am using are cutting out
frequently - every few minutes. I don't think it's a local problem, as
I have a good wifi and good ISP connectivity.

I've listened to the same stations in the past (several months ago) and
had no real issues - maybe one dropout every 3 or 4 days at most.
That's understandable - but not if it's every few minutes.

I've increased the buffer time to 30 seconds - but it didn't seem to
help.

For now I've had to stop listening to radio steams and just go with
local music.

Cheers,
Mike


------------------------------------------------------------------------
mike_zandvliet's Profile: http://forums.slimdevices.com/member.php?userid=852
View this thread: http://forums.slimdevices.com/showthread.php?t=92738

[toby10]

Mike,
Try connecting the player to MySB.com and play those same stations. Is
the result the same drop outs?


------------------------------------------------------------------------
toby10's Profile: http://forums.slimdevices.com/member.php?userid=12553
View this thread: http://forums.slimdevices.com/showthread.php?t=92738

[nicolas75]

Post by mike_zandvliet
I am experiencing the same problems with 7.7.1 and 7.7.2, against a
SqueezeBox2. A lot of radio streams I am using are cutting out
frequently - every few minutes. I don't think it's a local problem, as
I have a good wifi and good ISP connectivity.
I've listened to the same stations in the past (several months ago) and
had no real issues - maybe one dropout every 3 or 4 days at most.
That's understandable - but not if it's every few minutes.
I've increased the buffer time to 30 seconds - but it didn't seem to
help.
For now I've had to stop listening to radio steams and just go with
local music.
Cheers,
Mike

Nothing has changed for me either.
When the stream is bad I get several seconds rebuffering with the
Touch.
When it happens, I switch to whatever other software on the PC (usually
Foobar or MediaMonkey), and everything is fine.


------------------------------------------------------------------------
nicolas75's Profile: http://forums.slimdevices.com/member.php?userid=15823
View this thread: http://forums.slimdevices.com/showthread.php?t=92738

[bpa]

Hav you tried enabling LMS "proxied streaming" for the problemplayers
?

This requires the player to be connect to a local LMS. Web UI
Settings/Player/Audio - set MP3 streaming to "Proxied streaming". This
is a per player setting.

The radio stream will first be handled by LMS server and then sent onto
to player. It is similar to when when two players are synced with a
local LMS.


------------------------------------------------------------------------
bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806
View this thread: http://forums.slimdevices.com/showthread.php?t=92738

[Yves K]

It's an interesting topic, one I know from other buffers, namely
read/write buffers in CD/DVD equipment.

There is no magic: if there are gaps in the REALTIME stream, you can
either acknowledge it or muddy the waters. In clear terms, either you
hear the dropouts or you hear the dithering/interpolation done by the
equipment that is trying hard as hell to provide "something" to the
listener. Nicolas75 prefers to hear the interpolated data, accepting the
lower quality, instead of hearing dropouts. Most people would do, too.
But at the same time, the same people also want the highest quality
output in normal conditions. And that is a design contradiction for
which manufacturers have to make a conscious design choice:
Choice 1: favor the highest possible quality output
Choice 2: favor the best overall behaviour.

For choice 1, you take for granted that your input is of good quality
and your equipment is then there to translate that input into the best
possible output quality, possily at a ridiculously high cost. Typical
example: most high-end expensive hi-fi equipment including valve
amplifiers, speakers and speaker cables (!), interconnect cables, CD
players, fancy DAC's...
For choice 2, you assume that the input can be wide-ranging and your
equipment is then there to find the best way to produce an overall good
output (at a reasonale cost). Typical example: TV sets, mainstream CD
players

So, it looks like Mr Logitech has opted more for a hi-fi approach to the
SBTouch, which implies that the device is going to behave poorly with
poor inputs in order to favor superior results for decent inputs. It is
not realisticly possible to design a one-size fits all. For CD players,
the best quality is obtained by the devices that have minimal error
recovery! All the design effort is put on the engineering of the best
possible read capability on the first pass. For a CD with errors, the
result is atrocious but for the 99 other CD's out of 100, the result is
exquisite. It' a design choice to assume that most CD's are OK, and
equipments are designed and tested against their intended capabilities.
Personnally, I have a TP, 2 SBTouch and Slim Device. I avoid a poor
quality stream because I cannot stand the result, it gets on my nerves,
but in fact I enjoy them a lot because I find literally thousands (very
acceptable) quality streams and podcasts...

Voila.


PS: I really liked the post from Gerph but for one quirk: with REALTIME
streaming, if you loose information for x amount of time, you cannot get
that back over time in your buffer. Anything which is not present time,
is strictly past and cannot be called back. If the dropout takes 1
second, your 3 second buffer will be reduced to a 2 second buffer until
the next dropout, eventually until the buffer runs empty at which time
it will rebuffer 3 second (during which your hear nothing). That's the
hard law of real-time streaming. Believe me, I can tell you a lot about
buffer underruns that plagued so many CD-writers a few years ago...


------------------------------------------------------------------------
Yves K's Profile: http://forums.slimdevices.com/member.php?userid=25597
View this thread: http://forums.slimdevices.com/showthread.php?t=92738

[nicolas75]

Post by Yves K
...
So, it looks like Mr Logitech has opted more for a hi-fi approach to the
SBTouch, which implies that the device is going to behave poorly with
poor inputs in order to favor superior results for decent inputs.
...
From what I experience, I disagree.

Listening with other software, it is clear that dropouts last usually
less than one second.
How could this justify 5 to 10 seconds complete and abrupt silence ?

There is no sound quality problem before and after the dropout (I have
high end gear)

In my opinion the explanation is more the same than for Touch internal
server clock loosing several seconds per month.
Nobody really care about fixing it, and this wrong behaviour was
probably never carefully tested against poor streams generated on
purpose.

Poor streams with short dropouts, generated on purpose, are the only way
to check if what we experience is a bug or not.
More than that, it should be part of basic tests performed before
version release.


------------------------------------------------------------------------
nicolas75's Profile: http://forums.slimdevices.com/member.php?userid=15823
View this thread: http://forums.slimdevices.com/showthread.php?t=92738

[bpa]

Have you tried the "proxied" streaming mode I suggested ?


------------------------------------------------------------------------
bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806
View this thread: http://forums.slimdevices.com/showthread.php?t=92738

[nicolas75]

Post by bpa
Have you tried the "proxied" streaming mode I suggested ?

Most of the time I am using TinySBS (and sometimes mysqueezebox.com) for
streaming.
I only use LMS through MonkeySqueeze for local flac library, not for
streaming.
Library management for local library is (in my opinion and for my use)
far less user friendly compared to popular music softwares, and useless
for streaming.

Have you tested Squeezeboxes against streams with short dropouts, and
compared agaisnt other music software or music systems ?


------------------------------------------------------------------------
nicolas75's Profile: http://forums.slimdevices.com/member.php?userid=15823
View this thread: http://forums.slimdevices.com/showthread.php?t=92738

[bpa]

It is still worthwhile testing the using the LMS "proxied " settng
enabled. If it fixes the problem then the issue will be identified.

Back in 6.5.x I did some testing on this sort of issue relating to
"lumpy" streams which tended to deliver data in bursts. I found that PC
based players could end up buffering far more data compared to SB
players. PC players acked TCP packets as soon as they were received and
so could build up a v. large amount of data ready to be played. SB
player used to buffer only up to the TCP window size and packets would
only be acked when they were decoded ready for playing. The only
siutation where PC and hardware players behaved similarly was when
playing "live" stream as the station could only audio data to the PC
player as soon as it was available.


------------------------------------------------------------------------
bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806
View this thread: http://forums.slimdevices.com/showthread.php?t=92738

[nicolas75]

Post by bpa
It is still worthwhile testing the using the LMS "proxied " settng
enabled. If it fixes the problem then the issue will be identified.

Not for me since I will not use LMS anyway.
Honestly I don't feel like debugging a software I will not use, when it
is so easy for anyone to check Squeezeboxes behavior against almost any
popular music software, and actually hear the problem.
I have done it enough.
Software development is my job, I don't see it as a funny occupation or
a hobby.

Post by bpa
Not sure what you mean by "short drop outs" - only in "Live" stream did
I ever find gaps in audio stream as the station resyncs the broadcasted
stream to make up for network congestion to ensure internet radio stream
matches closely the actual broadcasted FM signal - in this case no TCP
packets are lost but there are audio gaps.

When you experience rebuffering with those streams, try listening to
them with Foobar or MediaMonkey at the same time.
There is no way you can miss the problem, if you test when rebufferings
occur.

I remember endless discussions about TinySBS clock loosing time problem,
with bunch of people trying to find strange explanations without
testing.
When we finally got them actually test TinySBS clock for a few days, in
the end they had to acknowledge the bug, a bug was opened in Bugzilla,
and .... ,
http://bugs.slimdevices.com/show_bug.cgi?id=17164
It is still open and still not corrected ...


------------------------------------------------------------------------
nicolas75's Profile: http://forums.slimdevices.com/member.php?userid=15823
View this thread: http://forums.slimdevices.com/showthread.php?t=92738

[dwc]

Listening to live audio streams is a daily practice for us. It's what we
turn on in the kitchen when we make morning coffee.

I almost never had radio stream buffering issues with server version
5.x.

With 7.7.2 - the issue is so bad it is unlistenable. The station (kalw
91.7 for example) rebuffers so frequently you can't follow the content.

i wonder what changed in live streaming and buffering between those
versions. it was truly better i the previous version.


------------------------------------------------------------------------
dwc's Profile: http://forums.slimdevices.com/member.php?userid=1892
View this thread: http://forums.slimdevices.com/showthread.php?t=92738

[toby10]

Post by dwc
Listening to live audio streams is a daily practice for us. It's what we
turn on in the kitchen when we make morning coffee.
I almost never had radio stream buffering issues with server version
5.x.
With 7.7.2 - the issue is so bad it is unlistenable. The station (kalw
91.7 for example) rebuffers so frequently you can't follow the content.
i wonder what changed in live streaming and buffering between those
versions. it was truly better i the previous version.

Computer? OS? Player? Tried connecting directly to MySB.com for
comparison?

That station played fine for me on 7.7.2 for over an hour, not a single
rebuffer or hiccup, and over two WiFi hops.

5 year old WinXP laptop eunning LMS 7.7.2 over WiFi to a WiFi Radio


------------------------------------------------------------------------
toby10's Profile: http://forums.slimdevices.com/member.php?userid=12553
View this thread: http://forums.slimdevices.com/showthread.php?t=92738

[dwc]

Post by toby10
Computer? OS? Player? Tried connecting directly to MySB.com for
comparison?
That station played fine for me on 7.7.2 for over an hour, not a single
rebuffer or hiccup, and over two WiFi hops.
5 year old WinXP laptop eunning LMS 7.7.2 over WiFi to a WiFi Radio

First off, the architecture was identical pre and post server upgrade.
That's why I didn't initially go into detail on my architecture, as it
worked fine prior to server upgrading. That being said I appreciate any
help and if there's something I can do via config to fix the issue I
will happily do it.

Computer:
There have been two servers, the first one had a mobo failure, and so I
switched boxes. Both old and new servers suffer the buffering issue on
the radio streams.

Current server (likewise an older box):
WinXP SP 3
Pentium 4 2 GHZ
1 GB ram

Player in question: Boom

Yes - the stream buffers via mysqueezebox as well as via my local
server.

No wifi hops, all wired. (Never any buffering issues with local music)

internet: Dual bonded DSL lines, sufficient to stream Netflix in HD. I
get about 50ms ping, 4.6-5.0 Mbps download speed.


------------------------------------------------------------------------
dwc's Profile: http://forums.slimdevices.com/member.php?userid=1892
View this thread: http://forums.slimdevices.com/showthread.php?t=92738

[toby10]

Since you mentioned which player you are using I've been streaming KALW
on a WiFi Boom with the same firmware level as yours. No issues.
Dunno what to tell you. :(


------------------------------------------------------------------------
toby10's Profile: http://forums.slimdevices.com/member.php?userid=12553
View this thread: http://forums.slimdevices.com/showthread.php?t=92738

[bpa]

What is the Radio station buffer setting ?
Have you tried "proxied" streaming ? if it improves thhings then it can
indicate the origin of the problem
Has your ISP introduced some form of traffic management ?


------------------------------------------------------------------------
bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806
View this thread: http://forums.slimdevices.com/showthread.php?t=92738

[toby10]

KALW is 64k mp3, user says same issues when playing from MySB (so
guessing not LMS settings issue), user says can stream HD movies (so
guessing not ISP limits).

Interesting tidbit: Left KALW streaming all night, still playing this
morning. But when I now go to check the More Info from the NP screen
(to verify my memory of 64k mp3) I get an error "Cannot request non-HTTP
URL". Possibly a clue?


------------------------------------------------------------------------
toby10's Profile: http://forums.slimdevices.com/member.php?userid=12553
View this thread: http://forums.slimdevices.com/showthread.php?t=92738

[bpa]

Post by toby10
KALW is 64k mp3, user says same issues when playing from MySB (so
guessing not LMS settings issue), user says can stream HD movies (so
guessing not ISP limits).

AFAICT KALW is available in WMA as well as MP3.

This is my opinion and just one possible explanation. When SB player is
playing direct the TCP window is not moved (i.e. packet acked) until it
is ready to be decoded whereas a HD movies streaming to a PC will move
TCP windows (i.e. ack every packet) into PC memopry well before the
playing applicaiton is ready. This means SB players have more short
burst and when window edge is moved ISP has to react quickly (i./e pass
ack back to station) to ensure packets are sent quickly. If this
doesn't happen quick enough you can get rebuffereing. With HD playing
there is enough data acked and buffered in PC memory that a slight delay
in getting more data does not affect playback.

If user triuews lMS proxied streaming and playtback imporves then the
above is one of the reasons for the problem.

ISP can do traffic management based on source and so data from HD
streaming sources may get priority over "ordinary" traffic.


------------------------------------------------------------------------
bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806
View this thread: http://forums.slimdevices.com/showthread.php?t=92738

[gerph]

Post by nicolas75
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).

My long explanation was to attempt to explain that you statements
belied that fact that you did not understand 'that stuff' - stating
that "The problem is not the size of the buffer, ... This is a well
known problem for streaming software developpers." was not correct, at
least according to my understanding and did not match with the
explanation that I gave.

Similarly your suggestion that /corrupt/ streams be the cause of
rebuffering certainly doesn't match with my own experience with either
Squeezebox or developing streaming software.

Post by nicolas75
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.

If you don't want to find the solution and just want to know the detail
of Logitech's internal QA... you're asking the wrong people. Speak to
Logitech - I would suggest that they do have test suites and that they
use them regularly. I'm sure that I saw a page detailing the many
builds and tests that they ran, but cannot find it now. As you're
interested in the tests being run, I'd also suggest you have a look at
http://wiki.slimdevices.com/index.php/AudioTests which might be a
little more enlightening.

Post by nicolas75
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.

The *first* thing to address this kind of problem is to check the
common causes. Eliminate the things which are commonly a problem,
however stupid they might seem. Otherwise you risk charging down a
route which is not helpful. Assume that the company performs regular
QA, and that you're not in the smaller group that get hit by the less
common problems, and rule these out these. As part of that process,
trying the things that are suggested seems sensible, and providing the
appropriate information would be helpful.

I saw that a couple of people suggested that you change the buffer
size, and asked if you'd tried that. You haven't said that you had
tried that, just repeated that you had bad behaviour and that you
didn't want to wait for the period that the rebuffering takes. As I
hope I've explained in my somewhat dull post previously, the
rebuffering period smooths out the data received by the system.

Similarly, a couple of people have suggested (as have I) that knowing
what the station is and therefore the protocol in use would help to
identify the problem. Other things to find out might include where you
are, a record of the traceroute between yourself and the source
station, and a ping record over the problematic period might all help.

But, if you're not interested in people helping identify the problem
but just want to know what Logitech's internal processes are... well...
good luck with that.

[nicolas75]

Post by gerph
Similarly your suggestion that /corrupt/ streams be the cause of
rebuffering certainly doesn't match with my own experience with either
Squeezebox or developing streaming software.

- The stream was poor I am positive about that.
- I had several seconds rebuffering, stopping replay, at least every
minute.

My experience of software developping (streaming or not) is that poor
data leading to bad user experience, can be called a "cause".
Deeper understanding of what is wrong may arise deeper effects or
"causes", but I still call the poor data a "cause".
(Unless you say that they are not related, and that I would have
experienced rebuffering with perfect stream anyway, and that
rebuffering magically stopped by chance when stream finally got fine
again).

Post by gerph
If you don't want to find the solution and just want to know the detail
of Logitech's internal QA... you're asking the wrong people.
...
But, if you're not interested in people helping identify the problem
but just want to know what Logitech's internal processes are... well...
good luck with that.

As I said in my previous post, my question is not to find out what went
wrong this afternoon for those streams, I don't really care, and it
won't really help.

You may find it useless and hopeless, but I don't completely agree.

It seems to me that in the last monthes, there were more and more users
on this forum who don't buy anymore the geek statement that products are
fine, and users don't know how to use them.

It is not completely useless to me.

[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 gives good results).
They do not stop replay while rebuffering occurs.