<div dir="auto">If that happen I normaly switch  to another Data Center (with a vpn or a backup icecast with slave/connection to main) to reroute the traffic of my broadcast from home <div dir="auto"><br></div><div dir="auto">This normaly Helps to avoid network botlneks id the outgoing traffic from home use another Patch then default.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Philipp Schafft <<a href="mailto:phschafft@de.loewenfelsen.net">phschafft@de.loewenfelsen.net</a>> schrieb am Di., 22. März 2022, 13:15:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Good afternoon,<br>
<br>
On Tue, 2022-03-22 at 11:45 +0000, Richard Bartholomew wrote:<br>
> Hi,<br>
>  <br>
> We're running V2.4.4 on Ubuntu 21.0.<br>
>  <br>
> Last night, whilst one of our presenters was broadcasting their show,<br>
> they were disconnected and unable to re-connect for around five<br>
> minutes and kept getting the message that they were connected even<br>
> though they weren't but our fallback autodj system was successfully<br>
> playing during that period!<br>
>  <br>
> I found the following message in the error log for the time in<br>
> question and wonder if anyone can advise me, please, on what I need<br>
> to do to prevent this in the future...as far as I'm aware, it's the<br>
> first time it has happened!<br>
>  <br>
> WARN source/get_next_buffer Disconnecting source due to socket<br>
> timeout<br>
>  <br>
> Thanks for any help with this.<br>
<br>
generally speaking the above warning is reported if a source does stop<br>
sending data. Normally this indicates that there is one of a) something<br>
wrong with the source client, b) some network problem.<br>
<br>
Generally speaking if nobody altered the source client it is b). Which<br>
I would also feel like it likely is that because of it taking a few<br>
minutes to recover but not too long.<br>
<br>
<br>
If it does not happen again I would just consider it a random network<br>
hiccup.<br>
<br>
<br>
However if you feel like there really needs to be something done about<br>
it there are a few first things to look at. Order and importance of the<br>
items really depend on your parameters:<br>
 * Network quality (e.g. wired, not wireless), maybe some line provider<br>
   that offers a availability focused SLA<br>
 * Training for all involved admins (e.g. to learn if an software<br>
   update may have an impact or not), keeping all teams informed on<br>
   maintenance, ...<br>
 * Redundancy. Which may include a second source client but also a<br>
   second line.<br>
<br>
<br>
Hope that helps. :)<br>
<br>
With best regards,<br>
<br>
-- <br>
Philipp Schafft (CEO/Geschäftsführer) <br>
Telephon:  +49.3535 490 17 92<br>
Website:   <a href="https://www.loewenfelsen.net/" rel="noreferrer noreferrer" target="_blank">https://www.loewenfelsen.net/</a><br>
Follow us: <a href="https://www.linkedin.com/company/loewenfelsen/" rel="noreferrer noreferrer" target="_blank">https://www.linkedin.com/company/loewenfelsen/</a><br>
<br>
Löwenfelsen UG (haftungsbeschränkt)     Registration number:<br>
Bickinger Straße 21                     HRB 12308 CB<br>
04916 Herzberg (Elster)                 VATIN/USt-ID:<br>
Germany                                 DE305133015<br>
_______________________________________________<br>
Icecast mailing list<br>
<a href="mailto:Icecast@xiph.org" target="_blank" rel="noreferrer">Icecast@xiph.org</a><br>
<a href="http://lists.xiph.org/mailman/listinfo/icecast" rel="noreferrer noreferrer" target="_blank">http://lists.xiph.org/mailman/listinfo/icecast</a><br>
</blockquote></div>