[Icecast] Keeping icecast + ices 2.X running on a strict schedule?

Mon May 26 14:50:22 UTC 2014

I misunderstood, I thought you were measuring time in whole seconds.

If you use sc_trans with Icecast, I am sure that you will see that the
problem then lies on the source with Ices.

Brad Isbell
brad at musatcha.com
http://www.musatcha.com

On Sun, May 25, 2014 at 11:00 PM, Jordan Verner <jv_erner at hotmail.com>wrote:

> Hello,
> Are you saying I should be rounding to the nearest second rather than
> measuring in milliseconds?
> My current approach is to calculate the track lengths by dividing the
> number of samples by the samplerate, resulting in a value measured in
> seconds with at least 8 decimal places.
> Nevertheless, for some reason a shoutcast + sc_trans setup handles this
> flawlessly. With Icecast + Ices, data is sent a good bit faster than it can
> be played. Even if the listener doesn't buffer and fall behind, refreshing
> after a couple of hours results in a pretty significant jump forward.
> ------------------------------
> From: brad at musatcha.com
> Date: Sun, 25 May 2014 22:48:49 -0500
>
> To: icecast at xiph.org
> Subject: Re: [Icecast] Keeping icecast + ices 2.X running on a strict
> schedule?
>
> The server doesn't control the rate, the source does.  Provided you aren't
> getting corrupt stream data (and it doesn't sound like you are), you don't
> have a server bug in this case.  At a basic level, the server level takes
> the data that comes in from the source, buffers it, and sends it right back
> out the door at the rate at which it came in.
>
> It isn't entirely clear to me where you're seeing the timing issue and
> what your setup is, but there are a couple other things to think about:
>
>    - Clock drift happens.  It's pretty severe but not unheard of for a
>    sound card to play back +/- 1% or so of the rate.  In your case, you're
>    looking at a 0.28% difference.  Perhaps there is a problem on the playback
>    end?  Are you sure your users are having this trouble?  Even if they all
>    aren't, some inevitably will on any station.
>    - Measurement in time of lossy audio files is usually not very exact.
>     MP3 files in particular have no track length header.
>    - Timing tracks down to the second will throw you off by 10 seconds at
>    the end of a playlist anyway, due to rounding up/down to the nearest second.
>    - If you can, don't plan out your perfect playlist by time.  You need
>    something that will automatically adjust things for you as you go.  It's
>    unrealistic to assume that you will be able to come up with a playlist
>    timed perfectly when dealing with a variety of formats and codecs with an
>    encoder that has an artificial clock sending audio to remotes that have
>    completely separate clocks.
>
> I don't know what the core of the problem is that you're having, so
> hopefully this is helpful.
>
> Brad Isbell
> brad at musatcha.com
> http://www.musatcha.com
>
>
> On Sun, May 25, 2014 at 9:23 PM, Jordan Verner <jv_erner at hotmail.com>wrote:
>
> Hello,
> In conclusion I'm pretty sure this issue is the symptom of a bug, either
> within Ices or Icecast itself. I decided to try running the same setup on
> Shoutcast today, and it's working perfectly. An hour of streaming at the
> time of this message, and absolutely no schedule deviation.
> It appears as though Shoutcast has better rate control than Icecast does
> at the moment or something.
> Thanks,
>
> Jordan.
>
> ------------------------------
> From: jv_erner at hotmail.com
> To: icecast at xiph.org
> Date: Sun, 25 May 2014 10:03:10 -0400
>
> Subject: Re: [Icecast] Keeping icecast + ices 2.X running on a strict
> schedule?
>
> Hello,
> Regarding accounting for track lengths, could sox (soxi) be getting it
> wrong?
> Here's my approach atm:
> $lengths = array();
> foreach($files as $val)
> {
> //Note that $files has already been populated by glob()
> $temp = explode(":", shell_exec('soxi -d "'.$val.'"'));
> $length = $temp[0] * 60 * 60;//convert the hours to seconds.
> $length += ($temp[1] * 60);//convert minutes to seconds
> $length += $temp[2];//add the seconds
> $length *= 1000;//convert to milliseconds.
>
> $lengths[$val] = $length;
> }
> With that done, I can retrieve lengths like this:
> $test = $lengths["/home/caturria/songs/etc.ogg"];
> I'm going to try subtracting a tenth of a second or so from these values
> just to see if I can get slightly more sane results.
> Thanks,
>
> Jordan.
>
> ------------------------------
> Date: Sun, 25 May 2014 13:23:09 +0000
> From: thomas at ruecker.fi
> To: icecast at xiph.org
> Subject: Re: [Icecast] Keeping icecast + ices 2.X running on a strict
> schedule?
>
> On 05/25/2014 01:13 PM, Jordan Verner wrote:
>
> 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'm going to revise my guess. It's probably inaccuracies in how you
> account for track length in your system. But ultimately it's irrelevant.
> I'd suggest to explore the idea of a filler jingle, as pointed out
> earlier. If you want to get fancy, you can even have several to dynamically
> chose to adjust for the offset more accurately. Although, I'm going to say
> that this is overkill and a 10s jingle/sound file should be just fine, also
> most listener software will have a buffer of 10-60s anyway, so being "on
> the dot" doesn't really come out right anyway. If you want silence, then
> please note that you should use very low level noise instead of digital
> silence. For the listener it will be indistinguishable, as the noise will
> probably be below the noise floor of their sound card, but for the vorbis
> encoder this makes a crucial difference. Digital silence compresses down to
> single bits per second and will lead to source timeouts and ill effects in
> listener software and should be avoided at all cost when streaming.
>
>
>  I haven't experienced any other timing oddities on the machine.
>
>
> If you can live with the above, then I'd suggest to take that route.
>
> Cheers
>
> TBR
>
>
>
> > 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
>
>
> _______________________________________________
> Icecast mailing listIcecast at xiph.orghttp://lists.xiph.org/mailman/listinfo/icecast
>
>
>
> _______________________________________________ Icecast mailing list
> Icecast at xiph.org http://lists.xiph.org/mailman/listinfo/icecast
>
> _______________________________________________ Icecast mailing list
> Icecast at xiph.org http://lists.xiph.org/mailman/listinfo/icecast
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>
>
>
> _______________________________________________ Icecast mailing list
> Icecast at xiph.org http://lists.xiph.org/mailman/listinfo/icecast
>
> _______________________________________________
> 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/20140526/82e87080/attachment.htm>