Icecast - Jan 2006 - [Icecast-dev] metadata fallback mounts

> So when you're listening before the fallback, it's not anywhere
near this
> far behind?
Just tested it all so here's what is happening.

Stream is up and all is well. Then I take the stream down and after about 14 
seconds the fallback starts, that's great and exactly what I want.

However, I start the stream again and have to wait about 5 minutes for the 
fallback to stop and the stream to resume on the client. Also, if I stop the 
stream again, there is a 5 minute delay until the fallback restarts so 
something is buffering about 5 minutes worth of data.

Any ideas on how I can reduce this lag, I've not got much control over the 
clients but have full control of the server so if there is any setting I can 
try, that would be great.

Cheers,
Andy



----- Original Message ----- 
From: "Geoff Shang" <geoff@hitsandpieces.net>
To: <icecast@xiph.org>
Sent: Thursday, January 19, 2006 11:17 AM
Subject: Re: [Icecast] [Icecast-dev] metadata fallback mounts

> Andy Woolley wrote:
>
>> Seems this is the answer, it's working but there is a 4-5 minute
delay
>> caused by a buffer once the fallback returns to the stream
>>
>> This then puts the stream 4-5 minutes behind when it finally starts up.
>
> So when you're listening before the fallback, it's not anywhere
near this
> far behind?
>
> I'm guessing that maybe Icecast is not sending the stream at the 
> approximate bitrate, but is pushing it as quickly as it can down the pipe. 
> Either that or Icecast is filling some internal queue with the MP3 data 
> from the file.  I guess it'd be easy enough to check which this is.
>
> Geoff.
>
> _______________________________________________
> Icecast mailing list
> Icecast@xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast

Andy Woolley wrote:
>> So when you're listening before the fallback, it's not anywhere
near
>> this far behind?
> 
> 
> Just tested it all so here's what is happening.
> 
> Stream is up and all is well. Then I take the stream down and after 
> about 14 seconds the fallback starts, that's great and exactly what I
want.
> 
> However, I start the stream again and have to wait about 5 minutes for 
> the fallback to stop and the stream to resume on the client. Also, if I 
> stop the stream again, there is a 5 minute delay until the fallback 
> restarts so something is buffering about 5 minutes worth of data.
> 
> Any ideas on how I can reduce this lag, I've not got much control over 
> the clients but have full control of the server so if there is any 
> setting I can try, that would be great.
If you want a time regulated fallback then use a source client like 
ezstream. To maintain consistency, no timing occurs on the fallback to 
file as that requires parsing of all formats.

karl.

Karl Heyes wrote:
> To maintain consistency, no timing occurs on the fallback to file as that 
> requires parsing of all formats.
hmmm, good point, but it obviously breaks fallback-override (as far as it's 
useful), and also could cause your outgoing bandwidth to be swamped.

Suggestion: How about allowing the admin to configure a bitrate for the 
fallback file.  This would make it their responsibility to get it right, 
but would solve both of the above.

Geoff.