karl wrote:> from the description, it sounds like it is doing what it's supposed to be > doing, but the listening client is buffering a large amount of the sent > stream data. The player will have a buffer, verify what setting that is > at and what the stream stream bitrate is.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. Is there anything server side that I can change to make the time gap shorter? Regards, Andy ----- Original Message ----- From: "Karl Heyes" <karl@xiph.org> To: "Andy Woolley" <andy@milonic.com> Cc: <icecast@xiph.org> Sent: Tuesday, January 17, 2006 11:11 PM Subject: Re: [Icecast] [Icecast-dev] metadata fallback mounts> Andy Woolley wrote: >> Have now set the log to level 4 and viewed the output when the stream >> stops/starts. >> >> Can't see any errors though. I'm getting: >> >> source/source_move_clients passing 1 listeners to "/fallback.mp3" >> >> on stream stop and: >> >> source/source_move_clients passing 1 listeners to "/studio" >> >> when the stream starts again, so looks like it's working. >> >> Could it be the client at fault? >> >> Also, I did notice that sometimes (very occasionally) it will actually >> work but takes about 3 to 4 minutes to action. I tried the test again but >> it doesn't work every time only works occasionally. > > from the description, it sounds like it is doing what it's supposed to be > doing, but the listening client is buffering a large amount of the sent > stream data. The player will have a buffer, verify what setting that is > at and what the stream stream bitrate is. > > karl.
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.
> 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