Since I upgraded from ices-cc and shoutcast v1 last week on 10 radio streams I've had the sources go silent on several occasions accross pretty much every stream at least once if not more. Has anyone else had this problem and if so what have you done about it? I'm running Debian Wheezy 64bit.

Given we're using version 1.1.1 could this be the problem?

https://github.com/savonet/liquidsoap/issues/66

mkonecny commented on 26 Apr 2013

We have two users that have mentioned their stream goes silent during the night.

http://forum.sourcefabric.org/discussion/15111/airtime-audio-fails-daily/p1
http://forum.sourcefabric.org/discussion/15412/unidentified-problem/p1

I've done some extensive analysis into what could be causing this problem - It appears it may be Liquidsoap related because I can see in the logs that Liquidsoap's queue did have tracks in it. It's only after Liquidsoap is restarted that audible output is heard.

Another user has mentioned that connecting to Liquidsoap via input.harbor "awakens" it.

One user gave me ssh access, and I could not get the output started unless restarting liquidsoap. I was able to see that tracks were in the queue, and I tried changing live_slave_enabled and live_master_enabled on/off via telnet to no effect.

The one lead I have right now is the user connecting to input.harbor and disconnecting again - any ideas how I should approach narrowing this down further?

okayawright commented on 17 May

Exact same environment, a 32bit Debian box with Ocaml 4.01.0. when compiling from scratch and running:
-The 1.1.1 full tarball from Sourceforge: bug reproduced
-The de8d49c:20140513:205754 Git commit object: bug NOT reproducible

Thanks!

Party Vibe Radio

<edit>

So I'm still having the same problem with the source going quiet on a at least a couple of my streams daily.

For the record I'm using CentovaCast 3.1.1 and Liquidsoap 1.1.1 of course on Debian Wheezy 64bit.

So stopping and restarting the autodj only appears to fix the problem but log writing appears to go screwy unless you restart the stream too.

Another stream went silent today. Is this where things went wrong?

2014/11/22 15:14:12 [autodj_startup:3] Switch to autodj with transition.
2014/11/22 15:14:12 [switch_5109:4] Activations changed: static=[], dynamic=[autodj_startup:active_sources:all_sources:crossfade].
2014/11/22 15:14:12 [autodj:4] Activations changed: static=[autodj_startup:active_sources:all_sources:crossfade], dynamic=[autodj_startup:active_sources:all_sources:crossfade].
2014/11/22 15:14:17 [shoutcast2_metadata:4] Got metadata at position 0: calling handler...
2014/11/22 15:14:17 [lang:3] #### Updated metadata on
206.190.152.194:8040 SID 1 to Isotroph - Philosophie
2014/11/22 15:14:22 [server:3] Unlink liquidsoap.sock
2014/11/22 15:14:22 [main:3] Shutdown started!
2014/11/22 15:14:22 [main:3] Waiting for threads to terminate...
2014/11/22 15:14:22 [dummy:4] Activations changed: static=[], dynamic=[].
2014/11/22 15:14:22 [source:4] Source dummy gets down.
2014/11/22 15:14:22 [live:4] Activations changed: static=[], dynamic=[priority_sources:live_autodj_switcher:shoutcast2_metadata:output_stream:output_stream].
2014/11/22 15:14:22 [live:4] Disabling caching mode.
2014/11/22 15:14:22 [output_stream:4] Activations changed: static=[], dynamic=[].
2014/11/22 15:14:22 [source:4] Source output_stream gets down.
2014/11/22 15:14:39 >>> LOG START

Your log shows you shutting down liquidsoap so yeah that would make it go silent.   The bug you linked usually only happens on 32bit Linux, have never seen it on 64bit.  Could be that you're "lucky" and it's happening for you on 64bit or could be that it's a different problem.

Your log shows you shutting down liquidsoap so yeah that would make it go silent.   The bug you linked usually only happens on 32bit Linux, have never seen it on 64bit.  Could be that you're "lucky" and it's happening for you on 64bit or could be that it's a different problem.

Thanks for taking the time to reply. I'm grateful to be able to rule that bug out. In the meantime symptoms have changed somewhat as described in the following thread I've just opened on Shoutcast forum...

http://forums.winamp.com/showthread.php?p=3014533

Here's a copy of my post on winamp.com. The attachment shows the DNAS status while no longer accepting connections...

I'm running Centovacast 3.1.1 with SHOUTcast Server v2.4.2.167 posix (linux x64) and Liquidsoap 1.1.1. Having recently upgraded from ices-cc and shoutcast 1.9.x because I was getting very occasional ices-cc crashes my streams have all been very unstable since. The main symptom started with the odd stream going silent daily on Centovacast 3.1 and I'm not exactly sure which version of Shoutcast exactly while still accepting new connections. But it has now shifted to several DNAS' daily no longer accepting connections despite both Shoutcast and Centovacast control panels showing everything is seemingly fine. The streams may also still be going silent but I haven't experienced the problem while connected yet so it's hard to be sure. I should also say that I've run mp3check and mp3val and fixed all errors.

Anyway any help you can offer on this issue would be greatly appreciated because these problems have negatively impacted my station as you can imagine.

DrO's reply...

there's a known issue with the recent DNAS builds since changing over to libcurl that can lock the yp / networking threads and thus make the DNAS not respond but still appear to be up. We've not resolved all of those issues yet (hindered by sys admins refusing to install newer builds because they're not "final") so we don't have a fully patched build we can guarantee fixes said issues.

As for liquidsoap, it seems to be an issue it has and is not related to the DNAS issue and is one to report to Centova/Liquidsoap as its not something we can help with.