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

Mon May 26 02:23:35 UTC 2014

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 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/20140525/f349af48/attachment.htm>