Icecast - Feb 2005 - Severe problem with Icecast2 and streamTranscoder

I have a setup where Icecast 2.2.0 is serving a single Vorbis stream.
The source is either a local ices2 or a remote Winamp/Oddcast.  I'm then
running a streamTranscoder 1.2.8 instance on the server to transcode the
Vorbis stream to MP3 on the fly and send it back to Icecast, to be
served at a different mountpoint.  My config files are very basic with
most settings at their defaults.

The problem is that whenever enough listeners (usually more than 10 is
needed) connect to the transcoded MP3 stream at Icecast,
streamTranscoder seems to go crazy after a while.  When you're listening
to it on a client, it seems to skip forward (kinda like fast forwarding
on a CD player) for a few seconds, then buffer for a few seconds, then
skip forward again, etc.  The only way to fix this seems to be killing
streamTranscoder and starting it again.

I don't know how it's possible that the number of listeners connected to
the Icecast server can affect streamTranscoder like that, but after
rigorous testing I'm positive about the relation!  At first I was sure
that this was a bug in sT, but I have now tried the same setup with
Shoutcast and the problem did *not* appear.  So it seems to have
something to do with Icecast after all.

The Icecast logs don't show anything significant.  My original
streamTranscoder bug report (with log snippets) is available here:
http://www.oddsock.org/openbb/read.php?TID=1640

-- 
Antti N?yh?                 "Ich bin der Zorn Gottes;
http://www.sairwas.org/         wer sonst ist mit mir?"

Antti N?yh? wrote:
> I have a setup where Icecast 2.2.0 is serving a single Vorbis stream.
> The source is either a local ices2 or a remote Winamp/Oddcast.  I'm
then
> running a streamTranscoder 1.2.8 instance on the server to transcode the
> Vorbis stream to MP3 on the fly and send it back to Icecast, to be
> served at a different mountpoint.  My config files are very basic with
> most settings at their defaults.
>
> The problem is that whenever enough listeners (usually more than 10 is
> needed) connect to the transcoded MP3 stream at Icecast,
> streamTranscoder seems to go crazy after a while.  When you're
listening
> to it on a client, it seems to skip forward (kinda like fast forwarding
> on a CD player) for a few seconds, then buffer for a few seconds, then
> skip forward again, etc.  The only way to fix this seems to be killing
> streamTranscoder and starting it again.
>
> I don't know how it's possible that the number of listeners
connected to
> the Icecast server can affect streamTranscoder like that, but after
> rigorous testing I'm positive about the relation!  At first I was sure
> that this was a bug in sT, but I have now tried the same setup with
> Shoutcast and the problem did *not* appear.  So it seems to have
> something to do with Icecast after all.
>
> The Icecast logs don't show anything significant.  My original
> streamTranscoder bug report (with log snippets) is available here:
> http://www.oddsock.org/openbb/read.php?TID=1640
>
My first thought is that the amount of listeners is reaching your 
bandwith limit.
Does your server have enough continuous throughput to keep up?
(the buffering / burst settings might produce the skipping output)
(note: if the Shoutcast setup uses the same bandwith and users, then 
this is not the problem)

Try lowering quality and/or bitrate to reduce the amount of data it has 
to send and see wether you can connect more listeners.

Also, is the CPU able to handle it all?

Dennis