[Icecast] Relays Ending With "Disconnecting source due to socket timeout"
jeremiahzrogers at gmail.com
Mon Aug 17 18:54:00 PDT 2015
Hello. Thanks for the excellent help. BTW, what does reflum mean? I
googled it but couldn't find anything conclusive.
I relay several streams from 181.FM, along with WNCW
<http://stream01183.westreamradio.com:80/wsm-am1>, and WAME
<http://crystalout.surfernetwork.com:8001/WAME-AM_MP3>. All relays are
for my own benefit, for example on different devices simultaneously. The
one that was most perplexing me was WNCW, which appears to be an Icecast
2.32 or 2.33 stream. I think the 181.fm streams are all Shoutcast
streams, and I've never looked to see what WAME is.
Since changing source-timeout to 60 instead of 10, I've been able to
relay for much longer periods of time than in the months before. We may
have gotten my trouble fixed. I'll relay hard for a week or two and see
Thanks again for the help and education.
On 8/16/2015 9:51, Philipp Schafft wrote:
> On Sun, 2015-08-16 at 09:34 -0400, Jeremiah Rogers wrote:
>> Sorry to leave that out. My connections typically last 2-6 hours before
>> the socket timeout error. The streams are MP3, either 64KBPS or 128KBPS.
> General remark: MP3 is a non free codec thus not officially supported.
>> Nathan also asked about firewalls. My Windows Firewall is off, and my
>> machine's antivirus doesn't have a firewall feature. I don't think
>> there's any firewall in play here.
>> Before emailing the list, I looked through several months of list
>> archives hoping to find this problem covered.
> That's a good idea. I would like to see more people do it! Thanks a lot.
>> While I didn't find it, I
>> saw reference to setting the log level to 4 and did that with my most
>> recent stream to see what I might learn.
> That's a good idea as well.
>> When the socket timeout is
>> generated, I see the following line.
>> DBUG last 1439707668, timeout 10, now 1439707679
>> With each stream I used in that session, when that line would be
>> generated, the difference between now and last was 11. They lead me to
>> the following questions.
>> What are those numbers?
> Time stamps. last (1439707668) is Sun Aug 16 06:47:48 UTC 2015, and now
> (1439707679) is Sun Aug 16 06:47:59 UTC 2015.
>> Do I correctly presume the allowable difference between them to be
>> controlled by the <source-timeout> setting in the config file?
>> If I change <source-timeout> to 30, 60, 256, or 512, what ramifications
>> might that have on listeners, my machine, or sources from which I relay?
> It will allow stalled connections to be 'hold' for a longer period of
> If you are already waiting for 11 sec for data, especially on a MP3
> stream something is likely (> 80%) wrong.
> If you can I would be pleased to know the URLs you use as source for the
> relay. I suspect this not to be an Icecast problem but something in your
> data source.
> If you can not provide those links or they're network internal you can
> use a tool such as wget (wget -O /dev/null $URL) and see if the data is
> flowing at a constant rate or if it 'modules' in rate and maybe even get
> stalled. The problem is that you say it only happens after several
> hours. But maybe it jumps around with the bitrate so we can notice it
> earlier than this 10 sec timeout.
> Also it would be helpful to know what kind of source you relay from
> (another Icecast or something else?).
> Have a nice day!
>> On 8/16/2015 0:25, Jordan Erickson wrote:
>>> On 08/15/2015 08:10 PM, Jeremiah Rogers wrote:
>>>> When I connect through my relays, eventually the connections are dropped
>>>> with "Disconnecting source due to socket timeout" errors.
>>> What value is "eventually", approximately?
>>> Icecast mailing list
>>> Icecast at xiph.org
> Icecast mailing list
> Icecast at xiph.org
Mobile (Voice/Text): 704-996-5334
Email: jeremiahzrogers at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Icecast