$ egrep "Too many errors" icecast.log | wc -l
975
$ egrep "client not receiving data fast enough" icecast.log
975
$ egrep "Accepted" icecast.log.0 | wc -l
4076
Hmm. I tried a windows laptop box (kinda slow) and indeed after about
30-40 minutes playback starts stuttering and eventually disconnects
from the icecast server.
Nothing else is running on this box. What gives? Why am I losing about
25% of the connections to this error?
------
Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org
>>> The opinions expressed above are entirely my own <<<
Excuses are the tools with which those with no purpose in view build for
themselves great monuments of nothing.
--- >8 ----
List archives: http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-request@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.
> > Hmm. I tried a windows laptop box (kinda slow) and indeed after about > > 30-40 minutes playback starts stuttering and eventually disconnects > > from the icecast server. > > > > Nothing else is running on this box. What gives? Why am I losing about > > 25% of the connections to this error? > > Are you using shout?Let me clarify here with the answer I've given everyone for almost a year now. This error is almost never a bug. It generally means exactly what it says. Your client can't receive data fast enough. It sometimes means the opposite, your client can't handle data this fast. Player have limited buffers. When they get full, they can't store more data. They stop requesting it. Icecast notices they it can't send anymore data, and drops the connection after a period of time. The normal cause is a slow client won't be getting data fast enough. Icecast does the same thing. Now normally you'd think this is the fault of bandwidth. That has something to do with it. In icecast the datarate of the stream is controlled by the source client. If it sends data too slow, clients won't get enough data, and things will sound weird. If it sends data too fast, it will fill up the buffer and missing audio will result. So the two causes are "not enough bandwidth" or "source client has bad timing". Shout has bad timing. That's why I completely rewrote the streaming core in libshout and made the timing pretty damn solid. Ices shouldn't exhibit these problems. Other source clients based on libshout shouldn't exhibit these problems. Liveice doesn't have this problem either, unless your having trouble with encoding too slow. Shoutcast DSP never has this problem for the same reason as liveice. it encodes everything on the fly in realtime, and so there's no need for timing at all. jack. --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> Hmm. I tried a windows laptop box (kinda slow) and indeed after about > 30-40 minutes playback starts stuttering and eventually disconnects > from the icecast server. > > Nothing else is running on this box. What gives? Why am I losing about > 25% of the connections to this error?Are you using shout? jack. --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
I have a patch that will fix your stuttering problem, apply to version
1.3.10.
In src/sock.c line 533, replace the original line (return n;) with
this:
return (t==0) ? n : t;
This will not help you if your client is legitimately not able to
receive data fast enough, but should correct the stuttering.
If you want more information, or a "proper" patch, let me know.
Mark
$ egrep "Too many errors" icecast.log | wc -l
975
$ egrep "client not receiving data fast enough" icecast.log
975
$ egrep "Accepted" icecast.log.0 | wc -l
4076
Hmm. I tried a windows laptop box (kinda slow) and indeed after about
30-40 minutes playback starts stuttering and eventually disconnects
from the icecast server.
Nothing else is running on this box. What gives? Why am I losing about
25% of the connections to this error?
--- >8 ----
List archives: http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-request@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.
> In src/sock.c line 533, replace the original line (return n;) with > this: > > return (t==0) ? n : t; > > This will not help you if your client is legitimately not able to > receive data fast enough, but should correct the stuttering. > > If you want more information, or a "proper" patch, let me know.Didn't I apply this patch to cvs? jack. --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.