Icecast - Aug 2005 - restarting streamtranscoder w/ out killing listeners

Hi folks

I'm running streamtranscoder on my icecast server.  Unfortunately,
after 5-15 minutes of transcoding, it sometimes produces jumpy/skippy
audio or drops the stream altogether.  What I'd like to do is restart
streamtranscoder every 5 minutes.  However, when I kill
streamtranscoder and bring it back, all listeners on the stream get
killed.  How can I prevent this?  In other words, how can I get
icecast to keep publishing the mount point when streamtranscoder is
killed and started again?

Also, are there any stable alternatives to streamtranscoder?

thanks!!
-josh whiting

On Sun, 7 Aug 2005, Josh Whiting wrote:
> I'm running streamtranscoder on my icecast server.  Unfortunately,
> after 5-15 minutes of transcoding, it sometimes produces jumpy/skippy
> audio or drops the stream altogether.  What I'd like to do is restart
> streamtranscoder every 5 minutes.  However, when I kill
> streamtranscoder and bring it back, all listeners on the stream get
> killed.  How can I prevent this?  In other words, how can I get
> icecast to keep publishing the mount point when streamtranscoder is
> killed and started again?
You could set up a fallback stream, redirecting people to a static file or
a stream streamed by ezstream (for example) when the transcoder goes down.
Obviously this will still interrupt the listeners, but it will not
disconnect them and will automatically move them back to the main stream
once it's up and running again.

BTW, we also use the streamTranscoder, and I found that increasing the
internal buffer size greatly increased the stability (at the cost of
slightly higher latency, but this was not an issue for us).

If you open transcurl.cpp and look for the comment "JCMOD, made this a lot
larger" (should be in three places), you'll see a value defined as
something multiplied by 20. I (rather arbitrarily) changed it to "*60"
and
recompiled and it worked so well I haven't felt the need to try other
values :-)


Regards,

Laust

> You could set up a fallback stream, redirecting people to a static file or
> a stream streamed by ezstream (for example) when the transcoder goes down.
> Obviously this will still interrupt the listeners, but it will not
> disconnect them and will automatically move them back to the main stream
> once it's up and running again.
Interestingly enough yesterday my friend & I devised a similar idea
where we setup two ST instances per format, (call them A and B,) each
set as a fallback for the other.  We then setup a cronjob to restart
A, then B, then A etc on an alternating schedule, so our listeners get
moved from A->B->A on a regular interval.  Quite a hack but at least
our stream is usable for now.
> BTW, we also use the streamTranscoder, and I found that increasing the
> internal buffer size greatly increased the stability (at the cost of
> slightly higher latency, but this was not an issue for us).
> 
> If you open transcurl.cpp and look for the comment "JCMOD, made this a
lot
> larger" (should be in three places), you'll see a value defined as
> something multiplied by 20. I (rather arbitrarily) changed it to
"*60" and
> recompiled and it worked so well I haven't felt the need to try other
> values :-)
Good tip there, I'll give that a try, thanks!

-jw