You can subscribe to this list here.
Showing
3
results of 3
Hi,
I was wondering if anyone had any news or any idea regarding this problem.
As of now, we haven't found a solution.
I decided to have a look into one of those 4KB, failed-recording files. An
interesting thing is that the file isn't actually empty.
Here is one of those file if anyone wants to analyse it :
It seems to contain some LAME header, but that's about all. This could
indicate that liquidsoap had no trouble creating the file and lame didn't
have any problem accessing it and writing into it, but that it just doesn't
write **sound** in it.
Any new idea or walkaround is welcome.
Azrael.
On Fri, Jan 31, 2014 at 9:42 AM, Ken Restivo <ken@...> wrote:
> FWIW, we're having this same problem with a very similar kind of script
> (saving an incoming DJ stream). In our case, we're usign an http stream as
> the input, and outputing to vorbis not mp3, but still it'll randomly close
> the file, and reopen it, with about 10 seconds of lost audio (in the saved
> files) while it falls back with transition to the jukebox and then back to
> the live stream again. Listeners to the icecast output likewise hear no
> glitches: only the archives show glitches.
>
> I thought for sure it was because I was doing something dumb that could be
> solved by grounding streams with output.dummy or doing something with the
> clocks or something similar. I'm reading up on it more now. I haven't yet
> really started isolating it and trying to get it to fail in a sandbox
> environment.
>
> -ken
> --
> -------
> On Thu, Jan 30, 2014 at 06:19:16PM +0100, Kerozen wrote:
> > Hi,
> >
> > We're on a 64-bit machine, using Debian 4.6.3-14 with a 3.2.0-4-amd64
> > kernel.
> >
> > Prior to 1.1.1, we were using svn8237. And prior to that I don't remember
> > (it was on another server) but I'm pretty sure the problem was already
> > there.
> >
> > Also worth noting is that besides of this output.file, we're also
> > broadcasting our stream to shoutcast servers using
> > output.icecast(protocol="icy"...), and those are always working as
> expected
> > : we never have any problem with those. Only output.file is affected by
> > this problem. However, this could be because output.icecast is only
> called
> > when the script starts (then it never stops as it's broadcasting 24/7,
> > either live or playlist) whereas output.file is started and stopped "on
> > demand" when a live show occurs.
> >
> >
> > Azrael.
> >
> >
> > On Thu, Jan 30, 2014 at 5:19 PM, Romain Beauxis <toots@...
> >wrote:
> >
> > > Hi,
> > >
> > > 2014-01-29 Kerozen <kerozen@...>:
> > > > I have a pretty weird problem on a pretty complex script. I'm afraid
> this
> > > > one is gonna be tough so brace yourselves, here it comes :
> > > >
> > > > This problem happens with Liquidsoap 1.1.1 as well as every previous
> > > version
> > > > I've tested so far. The problem is related with output.file creating
> new
> > > > files (as expected) but, after a while, stopping recording in it what
> > > should
> > > > be recorded (once the bug occurs, any newly created file remains
> empty).
> > > >
> > > > I have set up a system where liquidsoap automatically creates a new
> mp3
> > > > files each time a DJ connects to one harbor and records the live
> show in
> > > it
> > > > (when nobody is streaming to any harbor, the script falls back to a
> > > > playlist). It's working as follow (only showing here what I thought
> > > might be
> > > > of any interest for our problem, switching all the playlist
> generation
> > > part
> > > > of the script) :
> > > >
> > > > # En début de live (called by harbor)
> > > > def live_start(blah) =
> > > > log("Live démarré")
> > > > ignore(server.execute("archive.start"))
> > > > system("/etc/liquidsoap/scripts/write_status.sh LIVE")
> > > > end
> > > >
> > > > # En fin de live (same)
> > > > def live_stop() =
> > > > log("Live terminé")
> > > > ignore(server.execute("archive.stop"))
> > > > system("/etc/liquidsoap/scripts/write_status.sh PLAYLIST")
> > > > ignore(server.execute("xradio.skip"))
> > > > end
> > > >
> > > > live = input.harbor(id="prelive", port=8018, on_connect=live_start,
> > > > on_disconnect=live_stop, icy=true...)
> > > > live2 = input.harbor(id="live2", port=8020, on_connect=live_start,
> > > > on_disconnect=live_stop, icy=true...)
> > > >
> > > > live = strip_blank(live)
> > > > live2 = strip_blank(live2)
> > > > output.dummy(fallible=true,live2) # Permet d'éviter des buffers
> overrun
> > > > output.dummy(fallible=true,live) # Permet d'éviter des buffers
> overrun
> > > >
> > > > # Fallback pour la sauvegarde : live1 avant traitement et live2
> (jamais
> > > > traité)
> > > > liverec = fallback(track_sensitive=false,[live,live2])
> > > >
> > > > xradio = { a complex playlist generation system written much earlier
> in
> > > the
> > > > script, but no live yet }
> > > >
> > > > # Manual skipping, for when track limit is lost in the playlist
> system
> > > due
> > > > to the use of add() later
> > > > def skip_radio(s) =
> > > > source.skip(s)
> > > > end
> > > >
> > > > server.register(namespace="xradio",
> > > > description = "Skip current song",
> > > > usage = "xradio.skip",
> > > > "skip",
> > > > fun (s) -> begin skip_radio(xradio) "Skipped." end)
> > > > # End manual skipping
> > > >
> > > > ###### Here lies the creation of a new mp3 recording what was
> > > broadcasted to
> > > > any harbor
> > > > liverectitle = '$(if $(title),"%m-%d-%Y-%H:%M:%S -
> > > > $(title)","%m-%d-%Y-%H:%M:%S - Emission Inconnue")'
> > > > output.file(%mp3(bitrate=192, samplerate=44100, stereo=true),
> > > id="archive",
> > > > start=false, "/var/music/archives/d-day/" ^ liverectitle ^ ".mp3",
> > > > mksafe(liverec))
> > > >
> > > > # Adding live and playlist together
> > > > output = fallback(track_sensitive=false,[live, xradio])
> > > > output = sky(output) # this is when we lose our track limits
> > > > # Adding the other harbor, unprocessed
> > > > output = fallback(track_sensitive=false,[live2,output])
> > > >
> > > >
> > > > The problem is as follow : for a random amount of different
> connections
> > > to
> > > > one or the other harbor, things will work as expected : a new mp3
> file is
> > > > created and what's broadcasted to the harbor is recorded in it.
> > > >
> > > > After a random amount of different connections (can happen as fast
> as the
> > > > third time, but can also not happen even after several dozen
> > > connections), a
> > > > new behavior occurs : the mp3 file is indeed created by output.file,
> but
> > > the
> > > > mp3 file remains empty, weighing only 4KB. Once this behavior has
> started
> > > > occuring, it will happen EACH and EVERY time someone connects to a
> harbor
> > > > (there will be NO MORE recording, ever), until liquidsoap is
> restarted.
> > > >
> > > > I couldn't find any error or interesting bit of information in the
> logs.
> > > >
> > > > If this can help in any way finding where the problem lies exactly, I
> > > > noticed that the problematic behavior is much more likely to be
> triggered
> > > > when several connections are done in a very short amount of time.
> > > Typically,
> > > > if a DJ undergoes several buffer underruns in a row, the problematic
> > > > behavior is likely to be triggered. Same thing if a DJ connects RIGHT
> > > after
> > > > the previous one disconnects (like, so fast that liquidsoap is not
> even
> > > > given the time to fall back to playlist).
> > > >
> > > > However, while these situations tend to trigger the problem more
> often,
> > > they
> > > > do NOT trigger it all the time, and they are NOT the only cases
> where the
> > > > problem happens.
> > > >
> > > > Sometimes, even 20 buffer underruns in less than 3 minutes won't
> trigger
> > > the
> > > > behavior. By contrast, tonight, the new behaviour was triggered even
> > > though
> > > > I was connecting more than 20 hours after the last DJ stopped
> > > broadcasting,
> > > > and this was only the third file created since last liquidsoap
> reboot.
> > > >
> > > > Yesterday was 158M /var/music/archives/day2/01-28-2014-21:11:46 -
> > > > Emission Inconnue.mp3
> > > > But today is 4.0K /var/music/archives/d-day/01-29-2014-21:08:17 -
> > > > Emission Inconnue.mp3
> > > > And as explained, once triggered, this is for good. One DJ
> broadcasted
> > > today
> > > > after I ended my show, he was not recorded either : 4.0K
> > > > /var/music/archives/d-day/01-29-2014-23:05:26 - Emission Inconnue.mp3
> > > >
> > > >
> > > >
> > > > Any idea as to what might be the problem ?
> > >
> > > This sounds a lot like the dreaded "Liquidsoap sometimes stream
> > > silence" issue.. Although, the issue has never been present in
> > > liquidsoap version prior to 1.1.1 and also doesn't seem to appear on
> > > 64 bit machines..
> > >
> > > Which version of liquidsoap have you tried for this bug? Can/do you
> > > run on a 64 bit machine?
> > >
> > > Thanks,
> > > Romain
> > >
>
> >
> ------------------------------------------------------------------------------
> > WatchGuard Dimension instantly turns raw network data into actionable
> > security intelligence. It gives you real-time visual feedback on key
> > security issues and trends. Skip the complicated setup - simply import
> > a virtual appliance and go from zero to informed in seconds.
> >
>
>
> > _______________________________________________
> > Savonet-users mailing list
> > Savonet-users@...
> >
>
>
Ok, that bug seems to be known and fixed:
You need to upgrade shine (not ocaml-shine) to that fixed version. I
don't know if Romain and Samuel release new versions of libshine,
apart from the git repo.
Cheers,
David
On Mon, Feb 10, 2014 at 11:22 AM, Pranas Gudaitis <pranza@...> wrote:
> Hi David!
>
> It just crashes with segfault and it's due to nothing to encode for shine:
>
>
> [New Thread 0xb1fc2460 (LWP 19205)]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xb1fc2460 (LWP 19205)]
> shine_BF_freePartHolder (thePH=0x0) at src/lib/formatbits.c:295
> 295 free( thePH->part->element );
> (gdb)
>
> i have some file recordings defined which record to a file when some
> incoming source is active.
> as incoming sources are not active all the time, it crashes instead of just
> doing nothing.
>
>
> thanks,
> p
>
>>
>> Message: 2
>> Date: Mon, 10 Feb 2014 09:07:46 +0100
>> From: David Baelde <david.baelde@...>
>> Subject: Re: [Savonet-users] current git source results in
>> disfunctional liquidsoap on raspbian
>> To: "savonet-users@..."
>> <savonet-users@...>
>> Message-ID:
>> <CAFqqUFHpv-UVg9e_b2LHRzJU1zcqh1BhmQYMXgchJh1RGFe5VQ@...>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> Hi,
>>
>> I do not know of current issues with liquidsoap's git version, but
>> there might be problem with shine. Last time I tried using shine, it
>> was on a pi and it crashed... And I see an unmerged pull request from
>> a contributor to ocaml-shine on github.
>>
>> In any case it would be helpful to say what does not work for you.
>> Perhaps the above proposed fix is relevant.
>>
>> Cheers,
>>
>> David
>>
>> On Thu, Jan 30, 2014 at 6:55 PM, Pranas Gudaitis <pranza@...> wrote:
>>> hi peeps!
>>>
>>> just checking if it's just me or for real the current git source is still
>>> unusable for working build?
>>> i've git-pull`d past weeks but nothing new appeared and the last issue
>>> was
>>> liquidsoap crashing due to shine encoder having nothing to do (let's say
>>> encoding to file is described, but no incoming source is active so
>>> nothing
>>> gets encoded)
>>>
>>> is there a quick way to work around? i'd like to make a challenge for ma
>>> pi
>>> to take over radio from the windows machine which also has problems with
>>> savonet occasionally locking files - unable to delete.
>>>
>>> regards,
>>> p
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
>
> _______________________________________________
> Savonet-users mailing list
> Savonet-users@...
>
--
David
Hi,
You can just send us the fixed configure, or run "diff <fixed
configure> <original one>".
Cheers,
David
On Tue, Feb 11, 2014 at 9:45 PM, Leonard de Ruijter <leesvoer@...> wrote:
> I use the official 1.1.1 full tarball. What's the best way to generate a
> diff?
>
> Regards,
> Leonard
>
> On 2/11/2014 9:15 PM, David Baelde wrote:
>> Yes, this is strange. Where did you get the original configure, one of
>> our tarballs? A diff with the configure generated by bootstrap might
>> be useful.
>>
>> Cheers,
>>
>> David
>>
>> On Tue, Feb 11, 2014 at 12:52 PM, Leonard de Ruijter <leesvoer@...> wrote:
>>> An update:
>>> It seems that the warning disappears and everything works correctly
>>> after bootstrapping ocaml-alsa. I however thought bootstrapping was only
>>> needed for the git source branch?
>>>
>>> Leonard
>>> On 2/11/2014 11:48 AM, Leonard de Ruijter wrote:
>>>> Hello,
>>>>
>>>> I get the following warning when compiling ocaml-alsa on Arch Linux:
>>>> checking caml/threads.h usability... no
>>>> checking caml/threads.h presence... yes
>>>> configure: WARNING: caml/threads.h: present but cannot be compiled
>>>> configure: WARNING: caml/threads.h: check for missing prerequisite
>>>> headers?
>>>> configure: WARNING: caml/threads.h: see the Autoconf documentation
>>>> configure: WARNING: caml/threads.h: section "Present But Cannot Be
>>>> Compiled"
>>>> configure: WARNING: caml/threads.h: proceeding with the compiler's result
>>>> configure: WARNING: ##
>>>> -------------------------------------------------- ##
>>>> configure: WARNING: ## Report this to
>>>> savonet-users@... ##
>>>> configure: WARNING: ##
>>>> -------------------------------------------------- ##
>>>> checking for caml/threads.h... no
>>>>
>>>> Is it a real problem that threads.h isn't usable for alsa in order to
>>>> have liquidsoap to support multiple threads? it seems the other packages
>>>> could use threads.h just fine.
>>>>
>>>> Regards,
>>>> Leonard
>>>>
>>>> ------------------------------------------------------------------------------
>>>>@...
>
--
David