Icecast Streaming Media Server

[Anonymous]

Hi there,

I have a computer set up with IceS 2.0-kh60a that encodes audio and sends it to a Icecast 2.3-KH7 server in a different location. The IceS computer runs Debian linux and the server is running OpenBSD. The listener count on this stream can hit as high as 800 at times. I've noticed that at least once a day IceS disconnects from Icecast and puts this in the error log file:


[2008-01-24 10:11:40] EROR om_shout/output_ogg_shout Failed to write to XX.XX.XX.XX:80/stream.ogg (Socket is busy)
[2008-01-24 10:11:40] DBUG om_shout/_output_connection_close closed shout connection
[2008-01-24 10:11:42] DBUG om_shout/check_shout_connected Time we started stream on XX.XX.XX.XX:80/stream.ogg
[2008-01-24 10:11:44] EROR om_shout/check_shout_connected Failed to connect to XX.XX.XX.XX:80/stream.ogg (No error)
[2008-01-24 10:11:44] DBUG om_shout/_output_connection_close closed shout connection
[2008-01-24 10:11:46] DBUG om_shout/check_shout_connected Time we started stream on XX.XX.XX.XX:80/stream.ogg
[2008-01-24 10:11:52] INFO om_shout/check_shout_connected Connected to server: 76.76.10.165:80/stream.ogg
[2008-01-24 10:11:52] DBUG om_shout/output_ogg_shout initialising output stream


Any idea what is causing the Socket is Busy error message?

Here are my ices.xml and icecast.xml:

<?xml version="1.0"?>
<ices>
<background>0</background>
<logpath>/var/log</logpath>
<logfile>ices.log</logfile>
<logsize>2048</logsize>
<loglevel>4</loglevel>
<consolelog>0</consolelog>
<pidfile>/var/run/ices.pid</pidfile>

<stream>
<name>Stream</name>
<input>
<module>jack</module>
<param name="channels">2</param>
<param name="clientname">ices</param>
<param name="connect">alsa_pcm:capture_1,alsa_pcm:capture_2</param>
<param name="metadata">1</param>
</input>

<runner>

<instance>
<shout>
<hostname>XX.XX.XX.XX</hostname>
<port>80</port>
<password>password</password>
<mount>/stream.ogg</mount>
<yp>0</yp>
<reconnectdelay>2</reconnectdelay>
<reconnectattempts>-1</reconnectattempts>
</shout>

<encode>
<quality>-1</quality>
</encode>

</instance>

</runner>

</stream>
</ices>

and icecast.xml:

<icecast>
<limits>
<clients>1000000</clients>
<sources>1000000</sources>
<queue-size>524288</queue-size>
<client-timeout>30</client-timeout>
<header-timeout>15</header-timeout>
<source-timeout>60</source-timeout>
<threadpool>50</threadpool>
<!-- same as burst-on-connect, but this allows for being more
specific on how much to burst. Most people won't need to
change from the default 64k. Applies to all mountpoints -->
<burst-size>65535</burst-size>
</limits>
....

<mount>
<mount-name>stream.ogg</mount-name>
<password>password</password>
<max-listener-duration>21600</max-listener-duration>
<burst-size>65536</burst-size>
<hidden>0</hidden>
<no-yp>1</no-yp>
</mount>

[karlH]

The fact that it's busy would indicate that the network link from ices to icecast is full and is ices is not able to send the data it's encoded quickly enough. If there is some sort of hang with icecast or the machine running icecast then that could be the cause or a network failure.

Configuration wise, sources seems high and your mount-name does not begin with a / for stream.ogg. None of those should affect ices in such a way of course but kh7 is very old now, kh30 is the latest on my website.

karl.

[Anonymous]

Is there any way to determine whether the network cut-out is happening on the client side or the server side?

This is what I see in Icecast at the same time the cut-out happened:
[2008-01-24 10:11:44] WARN connection/source_startup Mountpoint /stream.ogg in use

[karlH]

That message occurs when the source client attempts to connect with a mountpoint that is already in use, so icecast has to reject it. You have source-timeout set set 60 seconds which is a long time to wait until icecast will drop the connection, you may be finding that ices is reconnecting before icecast has decided to drop the previous attempt.

karl.