<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hello. Thanks for the excellent help. BTW, what does reflum mean? I
googled it but couldn't find anything conclusive.<br>
<br>
I relay several streams from 181.FM, along with <a
href="http://audio-mp3.ibiblio.org:8000/wncw-128k">WNCW</a>, <a
href="http://stream01183.westreamradio.com:80/wsm-am1">WSM</a>,
and <a href="http://crystalout.surfernetwork.com:8001/WAME-AM_MP3">WAME</a>.
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.<br>
<br>
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.<br>
<br>
Thanks again for the help and education.<br>
<pre wrap="">
</pre>
<br>
<div class="moz-cite-prefix">On 8/16/2015 9:51, Philipp Schafft
wrote:<br>
</div>
<blockquote
cite="mid:20150816135116.E235C12BB3@grassland.keep-cool.org"
type="cite">
<pre wrap="">reflum,
On Sun, 2015-08-16 at 09:34 -0400, Jeremiah Rogers wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
General remark: MP3 is a non free codec thus not officially supported.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
ok.
</pre>
<blockquote type="cite">
<pre wrap="">Before emailing the list, I looked through several months of list
archives hoping to find this problem covered.
</pre>
</blockquote>
<pre wrap="">
That's a good idea. I would like to see more people do it! Thanks a lot.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
That's a good idea as well.
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">Do I correctly presume the allowable difference between them to be
controlled by the <source-timeout> setting in the config file?
</pre>
</blockquote>
<pre wrap="">
Yes.
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">
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!
</pre>
<blockquote type="cite">
<pre wrap="">Thanks!
On 8/16/2015 0:25, Jordan Erickson wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 08/15/2015 08:10 PM, Jeremiah Rogers wrote:
*snip*
</pre>
<blockquote type="cite">
<pre wrap="">When I connect through my relays, eventually the connections are dropped
with "Disconnecting source due to socket timeout" errors.
</pre>
</blockquote>
<pre wrap="">*snip*
What value is "eventually", approximately?
Cheers,
Jordan
_______________________________________________
Icecast mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Icecast@xiph.org">Icecast@xiph.org</a>
<a class="moz-txt-link-freetext" href="http://lists.xiph.org/mailman/listinfo/icecast">http://lists.xiph.org/mailman/listinfo/icecast</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Icecast mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Icecast@xiph.org">Icecast@xiph.org</a>
<a class="moz-txt-link-freetext" href="http://lists.xiph.org/mailman/listinfo/icecast">http://lists.xiph.org/mailman/listinfo/icecast</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Jeremiah Rogers
Mobile (Voice/Text): 704-996-5334
Email: <a class="moz-txt-link-abbreviated" href="mailto:jeremiahzrogers@gmail.com">jeremiahzrogers@gmail.com</a>
Facebook/Twitter: /jzrogers
</pre>
</body>
</html>