Brad Isbell
2014-May-26 03:48 UTC
[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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/icecast/attachments/20140525/89e61583/attachment.htm
Jordan Verner
2014-May-26 04:00 UTC
[Icecast] Keeping icecast + ices 2.X running on a strict schedule?
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 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/99d65eeb/attachment-0001.htm
Brad Isbell
2014-May-26 14:50 UTC
[Icecast] Keeping icecast + ices 2.X running on a strict schedule?
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
Reasonably Related Threads
- Keeping icecast + ices 2.X running on a strict schedule?
- Keeping icecast + ices 2.X running on a strict schedule?
- Keeping icecast + ices 2.X running on a strict schedule?
- Keeping icecast + ices 2.X running on a strict schedule?
- Keeping icecast + ices 2.X running on a strict schedule?