[icecast] Error: Client not receiving data fast enough

Justin Zipperle justin at shaggydawg.com
Sat Aug 25 03:25:33 UTC 2001

Hey all,

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
> --
> 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 mailing list