On 20.04.2012 07:50, Romain Beauxis wrote: > Hi Alexandru, > > 2012/4/18 Alexandru Matei<[email protected]>: >> I'm connecting using liquidsoap to a remote location. I would like to be >> connected 99.99%. But I noticed that it disconnects 2 times a day, or >> even more. What's strange is that stays disconnected only for 5-7 seconds. >> >> I usually get two types of messages: Broken pipe in write()! >> >> 2012/04/12 15:38:43 [airtime_1500_1700(dot)txt:3] Finished with >> "/store/........mp3". >> 2012/04/12 15:38:43 [airtime_1500_1700(dot)txt:3] Prepared >> "/store/......mp3" (RID 15). >> 2012/04/12 15:38:43 [lang:3] Using stream_format 0 >> 2012/04/12 15:38:59 [beta_playlist:2] Error while sending data: could >> not write data to host: Broken pipe in write()! >> 2012/04/12 15:39:00 [lang:3] >> /usr/lib/airtime/pypo/bin/liquidsoap_scripts/notify.sh --error='could >> not write data to host: Broken pipe in write()' --stream-id=1 >> --time=1334187040.91 >> 2012/04/12 15:39:00 [beta_playlist:3] Closing connection... >> 2012/04/12 15:39:00 [beta_playlist:3] Will try to reconnect in 5.00 seconds. >> 2012/04/12 15:39:00 [clock.wallclock_main:2] We must catchup 10.32 seconds! >> 2012/04/12 15:39:06 [beta_playlist:3] Connecting mount beta_playlist for >> [email protected]... >> 2012/04/12 15:39:06 [beta_playlist:3] Connection setup was successful. >> 2012/04/12 15:39:06 [lang:3] >> /usr/lib/airtime/pypo/bin/liquidsoap_scripts/notify.sh --connect >> --stream-id=1 --time=1334187040.91 >> 2012/04/12 15:39:52 [decoder:3] Method "MP3" accepted "/store/.........mp3". >> >> and this one: connection timeout! >> >> 2012/04/08 13:53:07 [beta_playlist:2] Error while sending data: could >> not write data to host: connection timeout! >> 2012/04/08 13:53:08 [lang:3] >> /usr/lib/airtime/pypo/bin/liquidsoap_scripts/notify.sh --error='could >> not write data to host: connection timeout' --stream-id=1 >> --time=1332753803.67 >> 2012/04/08 13:53:08 [beta_playlist:3] Closing connection... >> 2012/04/08 13:53:08 [beta_playlist:3] Will try to reconnect in 5.00 seconds. >> 2012/04/08 13:53:08 [clock.wallclock_main:2] We must catchup 30.37 seconds! >> 2012/04/08 13:53:14 [beta_playlist:3] Connecting mount beta_playlist for >> [email protected]... >> 2012/04/08 13:53:14 [beta_playlist:3] Connection setup was successful. >> 2012/04/08 13:53:14 [lang:3] >> /usr/lib/airtime/pypo/bin/liquidsoap_scripts/notify.sh --connect >> --stream-id=1 --time=1332753803.67 >> 2012/04/08 15:04:51 [decoder:3] Method "MP3" accepted "/store/......mp3". >> >> Just a few time a saw this kind if mesages: Not_found >> 2012/04/16 21:04:34 [beta_playlist:3] Will try again in 5.00 sec. >> 2012/04/16 21:04:34 [clock.wallclock_main:2] We must catchup 20.36 seconds! >> 2012/04/16 21:04:40 [beta_playlist:3] Connecting mount beta_playlist for >> [email protected]... >> 2012/04/16 21:05:00 [beta_playlist:2] Connection failed: could not >> connect to host: Not_found >> 2012/04/16 21:05:00 [lang:3] >> /usr/lib/airtime/pypo/bin/liquidsoap_scripts/notify.sh --error='could >> not connect to host: Not_found' --stream-id=1 --time=1334187040.91 >> >> I'm sure it's not airtime ( on a local stream it stays connected). The >> load on the machines is low. >> >> Any ideas? > The exception given after each disconnection might be irrelevant. I > think I remember seeing different exceptions for the same network > issue in the past. > > Thus, you should focus on the network disconnection. > > I'd also suggest also to investigate on the "catchup" messages that I > see in the logs. 20s is a long lag and it may very well be > disconnecting you from a distant server.. Catchups can happen when > your script is too cpu-intensive for your box. > > Another possible cause for the catchup, though, is that an icecast > output is blocking the main clock trying to write data during a > network failure, which could explain why you see a "catchup" message > immediately followed by a timeout one. Another indication that it must > be a network issue.. > > Romain
Hi! I think it's a network failure. I saw the catchup message in two situations: on load (when it starts form 1 sec ... and grows as the load stays high) and in the case described above. If icecast's buffers could be tuned... it would be great...but it's not possible. So, I made another scenario. I connected using airtime(liquidsoap) to an harbor.input(liquidsoap) an then to icecast. So liquidsoap to liquidsoap it's remote ( but I can tune buffers), and liquidsoap to icecast (local). This way I got NO disconnections in six days. The only disadvantage is that the music played is reencoded two times. Alexandru. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Savonet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-users
