Icecast - Aug 2015 - Relays Ending With "Disconnecting source due to socket timeout"

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.

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. 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. 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?
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?

Thanks!

On 8/16/2015 0:25, Jordan Erickson wrote:
> On 08/15/2015 08:10 PM, Jeremiah Rogers wrote:
> *snip*
>> When I connect through my relays, eventually the connections are
dropped
>> with "Disconnecting source due to socket timeout" errors.
> *snip*
>
> What value is "eventually", approximately?
>
>
> Cheers,
> Jordan
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
-- 
Jeremiah Rogers
Mobile (Voice/Text): 704-996-5334
Email: jeremiahzrogers at gmail.com
Facebook/Twitter: /jzrogers

reflum,

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.
ok.

> 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?
Yes.

> 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
time.


But:
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!

> Thanks!
> 
> On 8/16/2015 0:25, Jordan Erickson wrote:
> > On 08/15/2015 08:10 PM, Jeremiah Rogers wrote:
> > *snip*
> >> When I connect through my relays, eventually the connections are
dropped
> >> with "Disconnecting source due to socket timeout"
errors.
> > *snip*
> >
> > What value is "eventually", approximately?
> >
> >
> > Cheers,
> > Jordan
> > _______________________________________________
> > Icecast mailing list
> > Icecast at xiph.org
> > http://lists.xiph.org/mailman/listinfo/icecast
> 
-- 
Philipp.
 (Rah of PH2)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
Url :
http://lists.xiph.org/pipermail/icecast/attachments/20150816/f75f7e48/attachment.pgp

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://audio-mp3.ibiblio.org:8000/wncw-128k>, WSM 
<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 
what happens.

Thanks again for the help and education.



On 8/16/2015 9:51, Philipp Schafft wrote:
> reflum,
>
> 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.
> ok.
>
>
>> 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?
> Yes.
>
>
>> 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
> time.
>
>
> But:
> 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!
>
>
>> Thanks!
>>
>> On 8/16/2015 0:25, Jordan Erickson wrote:
>>> On 08/15/2015 08:10 PM, Jeremiah Rogers wrote:
>>> *snip*
>>>> When I connect through my relays, eventually the connections
are dropped
>>>> with "Disconnecting source due to socket timeout"
errors.
>>> *snip*
>>>
>>> What value is "eventually", approximately?
>>>
>>>
>>> Cheers,
>>> Jordan
>>> _______________________________________________
>>> Icecast mailing list
>>> Icecast at xiph.org
>>> http://lists.xiph.org/mailman/listinfo/icecast
>
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
-- 
Jeremiah Rogers
Mobile (Voice/Text): 704-996-5334
Email: jeremiahzrogers at gmail.com
Facebook/Twitter: /jzrogers

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/icecast/attachments/20150817/62544d40/attachment.htm