[icecast] Error: Client not receiving data fast enough
justin at shaggydawg.com
Fri Aug 24 20:25:33 PDT 2001
I've been having the same "Client not receiving data fast enough" errors.
I've got icecast configured so as not to send info to ANY yp directories.
Even on a quiet 100MB connection between client and server, I can stay
connected for only about 5 minutes at a shot if I'm lucky. I'm using
Icecast 1.3.11, and Shout 0.8.0. The files I'm streaming are all 22kHz,
64kbps, mono. A 6 minute file will go through Shout in roughly 5 minutes
and 15 seconds. If I watch the stats in WinAMP, I can see that the buffer
is just being filled up and maintained between 95-100% until the stream
If I request a file through Icecast without calling on Shout to broadcast it
(i.e., http://server:8000/file/filename.mp3), I have no problems, even with
a 75 minute file. So it seems to me that the problem is somewhere either in
Shout's stream, or Icecast's handling of that stream - one is pushing too
fast, or the other is pulling too fast.
I'm not sure if any of this is helpful, but I figure it doesn't hurt to
bring it up.
> Actually, I have seen this problem quite a bit as you all will
> remember. It isn't ices (I don't think) rather it seems to be
> something wrong in icecast. More specifically with the yp server
> section of code. The more yp directories you have listed the higher
> the chance of getting the not streaming fast enough error. I have
> trimmed all my directory servers back to just yp.icecast.org and for
> the most part the problem has vanished. Now there is one odd caveat,
> last week at some point our internal network was disconnected from the
> outside world. I could still stream internally. I had removed all of
> the yp directory server entries so icecast shouldn't have been trying
> to leave the internal network. I could not stay connected for more
> than 50-80 seconds. The error was always the same not streaming fast
> enough error but obviously it has nothing to do with the client at
> all. So as far as that goes it is a very misleading error message and
> probably one of the reasons we haven't been able to hunt it down. So
> there is some food for thought. Jack Brendan got any ideas? I've
> been taking the long term approach to hunting this one down. I have
> set the debug level up to four but the problem code seems to sneak
> between the debug code bits.
> Kirk Reiser The Computer Braille Facility
> e-mail: kirk at braille.uwo.ca University of Western Ontario
> phone: (519) 661-3061
--- >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 at xiph.org'
containing only the word 'unsubscribe' in the body. No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.
More information about the Icecast