Icecast - May 2014 - Keeping icecast + ices 2.X running on a strict schedule?

Hello,
I'm using Icecast, Ices, and the script module configuration to serve the
playlist to the server. Playlists are scheduled once per day with regularely
placed events (like spots) which run at specific times.
Unfortunately it's being served too fast, so it's always getting ahead
of schedule (gaining about 10 seconds on every hour).
I have tried adjusting the flush-samples setting in ices.xml and the queue size
in the icecast.xml file to no avail.
I've had to resort to implementing a forced delay into the php script which
feeds the filenames to ices, so that if ices calls it significantly early
it'll wait to issue the next filename until it's closer to it's
scheduled start time. This was causing disconnects whenever it became deviated
beyond 10 seconds. Disabling source timeout fixed this, but still it tries to
get as far ahead as physically possible and takes as much wiggle room as I give
it plus more.
Is there any fix for this? Streaming for 24 hours would have it calling the
script as much as 4 minutes ahead of schedule, forcing my script to hang for all
that time before issuing each and every filename.
This is way too much deviation for streams which stick to a schedule. Two weeks
of streaming would have everything an hour early.
Thanks,
 
Jordan.
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/icecast/attachments/20140524/e989b522/attachment.htm

Hi,

On 05/24/2014 11:29 PM, Jordan Verner wrote:
> I'm using Icecast, Ices, and the script module configuration to serve
> the playlist to the server. Playlists are scheduled once per day with
> regularely placed events (like spots) which run at specific times.
> Unfortunately it's being served too fast, so it's always getting
ahead
> of schedule (gaining about 10 seconds on every hour).
Sounds like the clocking is faster for some reason.
> I have tried adjusting the flush-samples setting in ices.xml and the
> queue size in the icecast.xml file to no avail.
> I've had to resort to implementing a forced delay into the php script
> which feeds the filenames to ices, so that if ices calls it
> significantly early it'll wait to issue the next filename until
it's
> closer to it's scheduled start time. This was causing disconnects
> whenever it became deviated beyond 10 seconds. Disabling source
> timeout fixed this, but still it tries to get as far ahead as
> physically possible and takes as much wiggle room as I give it plus more.
That won't fix it. You're inserting gaps into the stream and that's
a
bad thing for your listeners too.
> Is there any fix for this? Streaming for 24 hours would have it
> calling the script as much as 4 minutes ahead of schedule, forcing my
> script to hang for all that time before issuing each and every filename.
> This is way too much deviation for streams which stick to a schedule.
> Two weeks of streaming would have everything an hour early.
So for some reason on your system Ices is running 0.28% faster. I'm not
sure what causes this and where those samples go. Is it by chance a
virtual machine?

You can try to fiddle further with ices settings. If that doesn't fix it
then you could always have your script insert a 10s filler jingle if it
detects that you're out of the timeframe.

Other options would be to explore different automation solutions, but
they might suffer the same problem if it's some underlying clock oddity
on your system.

Cheers

Thomas

Hello,
Icecast and Ices are running on the same machine and it is a dedicated server.
It is a Xeon 1270 V2 CPU with 16 GB ram running Centos 64-bit.
Any thoughts on which settings I could try next? I have tried everything that
appears to relate to the speed at which the stream occurs to no avail.
One point I forgot to mention is that some tracks bring on more deviation than
others. Shorter tracks, like spots, through it off more than longer tracks (I
think). There are definitely tracks that inflict this effect more than others.
I haven't experienced any other timing oddities on the machine.
Thanks,
 
Jordan.
 
> Date: Sun, 25 May 2014 07:05:42 +0000
> From: thomas at ruecker.fi
> To: icecast at xiph.org
> Subject: Re: [Icecast] Keeping icecast + ices 2.X running on a strict
schedule?
> 
> Hi,
> 
> On 05/24/2014 11:29 PM, Jordan Verner wrote:
> > I'm using Icecast, Ices, and the script module configuration to
serve
> > the playlist to the server. Playlists are scheduled once per day with
> > regularely placed events (like spots) which run at specific times.
> > Unfortunately it's being served too fast, so it's always
getting ahead
> > of schedule (gaining about 10 seconds on every hour).
> 
> Sounds like the clocking is faster for some reason.
> 
> > I have tried adjusting the flush-samples setting in ices.xml and the
> > queue size in the icecast.xml file to no avail.
> > I've had to resort to implementing a forced delay into the php
script
> > which feeds the filenames to ices, so that if ices calls it
> > significantly early it'll wait to issue the next filename until
it's
> > closer to it's scheduled start time. This was causing disconnects
> > whenever it became deviated beyond 10 seconds. Disabling source
> > timeout fixed this, but still it tries to get as far ahead as
> > physically possible and takes as much wiggle room as I give it plus
more.
> 
> That won't fix it. You're inserting gaps into the stream and
that's a
> bad thing for your listeners too.
> 
> > Is there any fix for this? Streaming for 24 hours would have it
> > calling the script as much as 4 minutes ahead of schedule, forcing my
> > script to hang for all that time before issuing each and every
filename.
> > This is way too much deviation for streams which stick to a schedule.
> > Two weeks of streaming would have everything an hour early.
> 
> So for some reason on your system Ices is running 0.28% faster. I'm not
> sure what causes this and where those samples go. Is it by chance a
> virtual machine?
> 
> You can try to fiddle further with ices settings. If that doesn't fix
it
> then you could always have your script insert a 10s filler jingle if it
> detects that you're out of the timeframe.
> 
> Other options would be to explore different automation solutions, but
> they might suffer the same problem if it's some underlying clock oddity
> on your system.
> 
> Cheers
> 
> Thomas
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/icecast/attachments/20140525/a482f64b/attachment.htm