Icecast - Nov 2004 - Prevent client disconnecting fallen-too-far-behind

Hello,

Does anybody know how I can configure icecast so it doesn't disconnect a
client which "has fallen too far behind".

We are using icecast2.01 streaming software for our church home-listening
system.
Our client we use a netgem-netbox.
We are streaming 25kbps MP3 on V90-56kbps modem connection

After around 45 minutes after starting the cleint the icecast error.log
reports:
[2004-11-27  20:25:58] DBUG format-mp3/format_mp3_write_buf_to_client Client
had recoverable error -1.

But the client still goes on playing for about 1 hour. Then it suddenly
stops the music.

The icecast errorlog reports:
[2004-11-27  21:33:18] DBUG format-mp3/format_mp3_write_buf_to_client Client
had recoverable error -1
[2004-11-27  21:33:18] DBUG source/source_main Client has fallen too far
behind, removing
[2004-11-27  21:33:18] DBUG source/source_main Client removed

I think Icecast masters this proces and removes the client isn't it ?

Many thanks in advance for suggestion which may solve this.

Henk

On Sat, 2004-11-27 at 21:52, Henk van de Ridder wrote:
> Hello,
> 
> Does anybody know how I can configure icecast so it doesn't disconnect
a
> client which "has fallen too far behind".
there isn't anything else icecast can do when that condition is reached
> We are using icecast2.01 streaming software for our church home-listening
> system.
> Our client we use a netgem-netbox.
> We are streaming 25kbps MP3 on V90-56kbps modem connection
a 56kbps modem is not going to have a lot of tolerance.
> After around 45 minutes after starting the cleint the icecast error.log
> reports:
> [2004-11-27  20:25:58] DBUG format-mp3/format_mp3_write_buf_to_client
Client
> had recoverable error -1.
> 
> But the client still goes on playing for about 1 hour. Then it suddenly
> stops the music.
The size of the buffer in the player and the size of the TCP buffers on
the server/client OS will have an effect on the amount of data in-flight
> The icecast errorlog reports:
> [2004-11-27  21:33:18] DBUG format-mp3/format_mp3_write_buf_to_client
Client
> had recoverable error -1
> [2004-11-27  21:33:18] DBUG source/source_main Client has fallen too far
> behind, removing
> [2004-11-27  21:33:18] DBUG source/source_main Client removed
> 
> I think Icecast masters this proces and removes the client isn't it ?
> 
> Many thanks in advance for suggestion which may solve this.
A 56k modem should handle a single 25kbps mp3 stream but the modem

. can get congested with other traffic easily
. could connect at a lower rate than you're expecting
. could retrain to get a better/worse connection.
. could suffer from loss

If any of those occur then latency will be added, and if that keeps
repeating then eventually icecast will close the connection to the
client.

karl.

Hello Karl,

Thank you for your answer.
The problem is the client.

We decided to make a quick&dirty solution:
- The queue-size is enlarged to 512000 byte (our server has enough internal
memory)
- The streaming bitrate is lowered to 16 kbps.

Hopefully this will do for a time, until we'll find the real problem in the
client.

With kind regards.
Henk


----- Original Message ----- 
From: "Karl Heyes" <karl@xiph.org>
To: "Henk van de Ridder" <henk.vande.ridder@solcon.nl>
Cc: "icecast" <icecast@xiph.org>;
Sent: Sunday, November 28, 2004 3:23 AM
Subject: Re: [Icecast] Prevent client disconnecting fallen-too-far-behind

> On Sat, 2004-11-27 at 21:52, Henk van de Ridder wrote:
> > Hello,
> >
> > Does anybody know how I can configure icecast so it doesn't
disconnect a
> > client which "has fallen too far behind".
>
> there isn't anything else icecast can do when that condition is reached
>
> > We are using icecast2.01 streaming software for our church
home-listening
> > system.
> > Our client we use a netgem-netbox.
> > We are streaming 25kbps MP3 on V90-56kbps modem connection
>
> a 56kbps modem is not going to have a lot of tolerance.
>
> > After around 45 minutes after starting the cleint the icecast
error.log
> > reports:
> > [2004-11-27  20:25:58] DBUG format-mp3/format_mp3_write_buf_to_client
Client
> > had recoverable error -1.
> >
> > But the client still goes on playing for about 1 hour. Then it
suddenly
> > stops the music.
>
> The size of the buffer in the player and the size of the TCP buffers on
> the server/client OS will have an effect on the amount of data in-flight
>
> > The icecast errorlog reports:
> > [2004-11-27  21:33:18] DBUG format-mp3/format_mp3_write_buf_to_client
Client
> > had recoverable error -1
> > [2004-11-27  21:33:18] DBUG source/source_main Client has fallen too
far
> > behind, removing
> > [2004-11-27  21:33:18] DBUG source/source_main Client removed
> >
> > I think Icecast masters this proces and removes the client isn't
it ?
> >
> > Many thanks in advance for suggestion which may solve this.
>
> A 56k modem should handle a single 25kbps mp3 stream but the modem
>
> . can get congested with other traffic easily
> . could connect at a lower rate than you're expecting
> . could retrain to get a better/worse connection.
> . could suffer from loss
>
> If any of those occur then latency will be added, and if that keeps
> repeating then eventually icecast will close the connection to the
> client.
>
> karl.
>
>
>

Hi:

Sorry, can't remember if you solved this or not.

Henk van de Ridder wrote:
> Does anybody know how I can configure icecast so it doesn't disconnect
a
> client which "has fallen too far behind".
>
> We are using icecast2.01 streaming software for our church home-listening
> system.
> Our client we use a netgem-netbox.
> We are streaming 25kbps MP3 on V90-56kbps modem connection
A likely problem here is that 56K modems can only *upload* at 33.6.  For 
such a connection, a 25kbps stream may be a bit marginal.   Of course, if 
you're using a bigger pipe to send to icecast then ignore this.

Geoff.


-- 
Geoff Shang <geoff@hitsandpieces.net>
Phone: +61-418-96-5590
MSN: geoff@acbradio.org

Make sure your E-mail can be read by everyone!
http://www.betips.net/etc/evilmail.html

Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html