[Icecast] ices2 routinely abandons one of its streams

[Frederic Briere]

Hi everybody,

I'm in charge of an ices2 setup that's broadcasting a local radio
station on the Net, and I'm currently under fire because one of our
streams has been down twice in two days, forcing me to restart ices2 on
each occasion.  Our client is understandably unhappy about this.

OUR SETUP: I've got ices2 installed on a local machine, broadcasting to
an icecast server across the continent.  (So, yes, connections get
dropped and picked up regularly.)  There are two streams: high-quality
(/cigr.ogg) and low-quality (/cigr-low.ogg).  So far, it's the
high-quality stream that has gone down on both occasions.

WHAT HAPPENS: According to the icecast logs, the connection goes down as
usual; the client eventually resumes the connection, which gets dropped
down again almost immediately for some reason:

<skipping earlier disconnection>
[2004-07-13  13:15:00] INFO connection/_handle_source_request Source logging in at mountpoint "/cigr-low.ogg"
[2004-07-13  13:15:01] INFO connection/_handle_source_request Source logging in at mountpoint "/cigr.ogg"
[2004-07-13  13:15:11] WARN source/source_main Disconnecting source: socket time out (10 s) expired
[2004-07-13  13:15:11] INFO source/source_main Removing source following disconnection
[2004-07-13  13:15:11] INFO source/source_main Source "/cigr.ogg" exiting

(The icecast log times are in GMT.)

However, the client does *not* notice the latest disconnection:

[2004-07-13  09:13:00] WARN stream/ices_instance_stream Trying reconnect after server socket error
[2004-07-13  09:14:59] INFO stream/ices_instance_stream Connected to server: ice.imars.net:8000/cigr-low.ogg
[2004-07-13  09:14:59] DBUG input/input_flush_queue Input queue flush requested
[2004-07-13  09:14:59] DBUG input/input_flush_queue Input queue flush requested
[2004-07-13  09:14:59] DBUG input/input_flush_queue Input queue flush requested
[2004-07-13  09:14:59] DBUG encode/encode_clear Clearing encoder engine
[2004-07-13  09:14:59] INFO encode/encode_initialise Encoder initialising in VBR mode: 2 channel(s), 44100 Hz, quality 0.000000
[2004-07-13  09:14:59] INFO audio/resample_initialise Initialised resampler for 1 channels, from 44100 Hz to 22050 Hz
[2004-07-13  09:14:59] DBUG encode/encode_clear Clearing encoder engine
[2004-07-13  09:14:59] INFO encode/encode_initialise Encoder initialising in VBR mode: 1 channel(s), 22050 Hz, quality -0.500000
[2004-07-13  09:14:59] EROR stream/ices_instance_stream Send error: Socket error (Broken pipe)
[2004-07-13  09:14:59] DBUG input/input_flush_queue Input queue flush requested
[2004-07-13  09:14:59] WARN stream/ices_instance_stream Trying reconnect after server socket error
[2004-07-13  09:15:00] INFO stream/ices_instance_stream Connected to server: ice.imars.net:8000/cigr.ogg
[2004-07-13  09:15:00] DBUG input/input_flush_queue Input queue flush requested

(The ices2 logs are in EDT.)


netstat shows that the connection lingers in the CLOSE_WAIT state; the
server has closed its end, but the client doesn't pick it up.

tcpdump doesn't show any traffic on what remains of the connection, so
the client doesn't appear to be broadcasting.  Yet it's not closing the
connection either.

I'm attaching ices2's config file.  Any help or pointers would be
appreciated; otherwise I'll have to sprinkle some fprintfs everywhere
and hope for the best. :(


--
Frederic Briere    <*>    fbriere at fbriere.net

=>  <fbriere at abacom.com> IS NO MORE:  <http://www.abacomsucks.com>  <=
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ices2.xml
Type: text/xml
Size: 2145 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/icecast/attachments/20040714/32285b69/ices2.xml