[Icecast] Relays Ending With "Disconnecting source due to socket timeout"

[Philipp Schafft]

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: signature.asc
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.sig>