Icecast Streaming Media Server

[Anonymous]

I have a strange error that make the relay server to disconnect from the source, but only one mountpoint. I have a master icecast/win32 2.3.1 with 2 mountpoint. I allow 10 connections on it. I have 4 relay server that connect to that master. I didn't let listeners to connect on the master. One in a while, maybe 5-6 times an hour, any slave server will disconnect and give the followin error:

[2006-04-04 04:10:45] INFO format-mp3/mp3_get_filter_meta Error on connection from source
[2006-04-04 04:10:45] INFO source/source_shutdown Source "/radioxrock" exiting
[2006-04-04 04:10:45] DBUG source/source_clear_source clearing source "/radioxrock"

The other source stay online without any error. In fact, I didn't get any kind of error from the other source.

My slave icecast are running on FreeBSD 5.4 with icecast 2.2.0

[karlH]

That would indicate an error on the read but not one marked as recoverable. If you really want to stick with 2.2.0 then you would need to determine what the errno is at that point. Whether anything can be done about it I'm not sure.

karl.

[Anonymous]

I will upgrade to 2.3.1 this week-end and let you know about it.

[Anonymous]

Now, all my 4 relay server running on FreeBSD are v2.3.1. I still get error about connection from source but the message is different. Now I got these:
[2006-04-26 10:30:07] WARN client/client_read_bytes source connection has died
[2006-04-26 10:30:07] INFO source/get_next_buffer End of Stream /radioxrock
[2006-04-26 10:30:07] INFO source/source_shutdown Source "/radioxrock" exiting
[2006-04-26 10:30:07] DBUG source/source_clear_source clearing source "/radioxrock"
[2006-04-26 10:30:07] DBUG stats/process_source_event delete source node /radioxrock

This happend regulary every 30 minutes or so. I guess it's a network issue but, again, I can't understand why it did this on only one source.

All my relay servers have these settings as limits:
<limits>
<clients>250</clients>
<sources>2</sources>
<threadpool>30</threadpool>
<queue-size>262145</queue-size>
<client-timeout>30</client-timeout>
<header-timeout>15</header-timeout>
<source-timeout>30</source-timeout>
<burst-on-connect>1</burst-on-connect>
<burst-size>131071</burst-size>
</limits>

And my master icecast 2.3.1/win32 have this:
<limits>
<clients>20</clients>
<sources>2</sources>
<threadpool>15</threadpool>
<queue-size>524288</queue-size>
<client-timeout>30</client-timeout>
<header-timeout>15</header-timeout>
<source-timeout>30</source-timeout>
<burst-on-connect>1</burst-on-connect>
<burst-size>262145</burst-size>
</limits>

I changed the burst-size settings because I don't care about the latency.

[Anonymous]

Also, I use Orban Opticodec-1010 SE for 1 mountpoint and Opticodec-1010 PE for the other (the one in trouble)

[karlH]

It's reporting that the incoming connection has failed. It's unusual to catch a problem there but maybe FBSD is sending something else back that isn't handled. You could use truss on the thread or log the errno but if the kernel is failing the socket then there isn't much icecast can do.

karl

[Anonymous]

Sounds like another issue with AAC+

[Anonymous]

I guess it is. I will ask orban to send me the latest version of opticodec-pc pe. It seems that version 2.2 offers:
Highly Optimized TCP/IP for Robust Network Performance
Packet Optimization for More Efficient Streams - PE Only

Also, there is no problems between the codec and the master streamer. The codecs are on my local network and streams through the internet to the master streams on wich the 4 slaves streamers are connected. These 5 machine are on the same network and there is connection trouble between them. It's very weird.