Good morning Romain,
On Tue, 29 Mar 2022 at 11:42, Romain Beauxis
wrote:
> I was able to fix most of what I could see and add a test. As far as I can
> tell your filters should now work with the `v2.0.4-preview` branch (soon to
> be `2.0.4` release).
>
Thank you for looking into this so careful
On Mon, 21 Mar 2022 at 09:36, Romain Beauxis
wrote:
I'm making the assumption that metadata mostly matters for audio streams
where they may hold track title/artist/album etc.
> Curiously, the metadata sometimes flicks into life, but most of the time
my player reports "Unknown".
> Do you have
On Tue, 24 Aug 2021 at 08:11, Romain Beauxis
wrote:
> Cool! I forgot to add: make sure that you also update ocaml-ffmpeg, there
> was a big there in how we set frame metadata.
> On Tue, Aug 24, 2021, 00:51 John Warburton wrote:
>
>> On Tue, 24 Aug 2021 at 02:35, Romain
On Tue, 24 Aug 2021 at 02:35, Romain Beauxis
wrote:
> Hi John,
>
> I just pushed the fix to pass liquidsoap's metadata down to ffmpeg
> filters! They are passed only when the `pass_metadata` parameter is set to
> `true`. By default, it only passes them to audio streams. I'm making the
> assumptio
On Mon, 23 Aug 2021 at 08:36, Romain Beauxis
wrote:
> Hi John,
>
> Thanks for this report. I actually pushed the changes to decode and pass
> metadata from ffmpeg frames when converting back to liquidsoap frame format
> in this PR: https://github.com/savonet/liquidsoap/pull/1812
>
> In it, I fail
On Mon, 23 Aug 2021 at 08:36, Romain Beauxis
wrote:
> Hi John,
> Thanks for this report. I actually pushed the changes to decode and pass
> metadata from ffmpeg frames when converting back to liquidsoap frame format
> in this PR: https://github.com/savonet/liquidsoap/pull/1812
> In it, I failed t
>
> As I convert to Liquidsoap 2.0.0, I might be losing metadata through an
> FFmpeg filter.
> ...
> Am I losing it because the conversion to 'raw' discards the metadata,
> leaving only the audio?
>
This workaround is doing the job -- but is it correct?
I define a little function to read metadata
Hello,
Thank you for all the work on this project.
As I convert to Liquidsoap 2.0.0, I might be losing metadata through an
FFmpeg filter.
In the script, there is a function to implement some of my FFmpeg loudness
adjustment filters that previously were in the output pipe.
But metadata goes miss
On Sun, 11 Jul 2021 at 22:10, Romain Beauxis
wrote:
>
> Thank you for this report. Both crossfade and cue_cut have been reworked
> recently so this is not entirely surprising. Would you mind starting a
> ticket describing the issue?
>
> Ideally, I'd like to be able to reproduce locally so, a coup
On Tue, 6 Jul 2021 at 20:04, Romain Beauxis
wrote:
> A little over a year after introducing support for abstract internal frame
> content in liquidsoap, we’re happy to announce that the second beta of
> liquidsoap 2.0.0 is now available:
> https://github.com/savonet/liquidsoap/releases/tag/v2.0.0
On Thu, 3 Jun 2021 at 14:16, Romain Beauxis
wrote:
> Happy to announce the first beta release of liquidsoap 2.0 available here:
> https://github.com/savonet/liquidsoap/releases/tag/v2.0.0-beta1
>
Congratulations, one and all.
Very happy to try this as soon as practical. I see you have made many
On Mon, Mar 1, 2021 at 2:49 AM Romain Beauxis
wrote:
> > Also playing more with request queues -- are these likely to change
> enormously in version 2, do you think? If so, I'll pause these experiments.
>
> I think that they will be changed a lot. For one thing, we are moving
> queues to the scri
Congratulations on this new release -- I'll be updating later today.
1.4.3 still very reliable, but will run this new version soon.
Also playing more with request queues -- are these likely to change
enormously in version 2, do you think? If so, I'll pause these experiments.
with best wishes,
Jo
On Thu, Jul 30, 2020 at 3:40 PM Romain Beauxis
wrote:
> Internally, samples are represented by 64 bits floating point numbers.
>
> Thank you, Romain.
This piece of forward planning in the system's underlying structure means I
need never worry about truncating samples!
with best wishes,
John
___
On Fri, Jul 3, 2020 at 10:24 PM Romain Beauxis
wrote:
> Current stable release
>
> Admittedly, there's been a lag in dealing with issues lately with all the
> heavy work being done in the main branch. However, we do plan on catching
> up with pending issues and bugs shortly. To that extend, there
On Sun, Jun 7, 2020 at 8:08 PM mapple wrote:
> hi there i have try all day now to run liquidsoap bt it always fails
>
> %external(ffmpeg libfdk_aac -profile:a aac_he_v2 -b:a 60k),
>
This is an example line using FFmpeg as an external device that is working.
You could use this as a model, obviousl
Further to my note earlier, putting the usual #EXTM3U line at the top of
the playlist restores expected behaviour.
Not sure where it went. Odd.
JW
On Sun, Jan 12, 2020 at 1:02 AM John Warburton
wrote:
> Dear all,
>
> On restarting Liquidsoap tonight, it refused to recognise my .m
Dear all,
On restarting Liquidsoap tonight, it refused to recognise my .m3u8 files,
instead reporting in the logs they were "application/csv".
I'm in the middle of debugging this, but it seems that a change in GNU file
mis-identifies files using the "annotation:" protocol as CSV.
There is appare
On Tue, Oct 1, 2019 at 1:29 AM Romain Beauxis
wrote:
> Hello everyone!
>
> This is with great pleasure (and a bit of relief!) that we can now
> announce that liquidsoap 1.4.0 is out! [image: :tada:]
>
Hello,
Just an update after my flurry of notes about a year ago. Work in a radio
station and t
On Wed, May 29, 2019 at 4:14 PM Romain Beauxis
> wrote:
> Gonna add something in the standard library for this.
Thanks! The telnet/expect system worked for me, though it felt
un-liquidsoap to do it quite like that. Still, mustn't neglect to learn
OCaml properly now.
System still running, weeks
On Fri, 17 May 2019, 09:38 SlvrEagle23, wrote:
> I strongly suspect there's already a Liquidsoapy solution for this
> problem, but I'm not aware of what it is, so I figured I'd ask on here:
>
> Currently, when users indicate that they'd like a song to play once per
> day at a specified time (or o
On Sun, 12 May 2019, 23:00 Romain Beauxis, wrote:
> Hi,
>
> The old cross/crossfade operators are superseeded by smart_cross/
> smart_crossdade. Most of the functionalities of the old operators should
> be replicable with the new one.
>
> In particular, the liq_start_next functionality has been a
On Sun, 28 Apr 2019, 22:37 Samuel Mimram, wrote:
> youtube-dl -g http://youtube/playlist gives a list of urls of the videos
> in the playlist, which you should be able to use as a regular playlist
>
I regularly package youtube-dl; and its authors do a good job of tracking a
moving target. For exa
On Fri, Apr 19, 2019 at 3:38 PM John Warburton
wrote:
> On Fri, Apr 19, 2019 at 3:25 AM Romain Beauxis
> wrote:
>
>> Thanks for the feedback and encouragement on this one! Should I worry
>> about the tightness described above or is that something you are able
>> to ad
On Fri, Apr 19, 2019 at 3:25 AM Romain Beauxis
wrote:
> Thanks for the feedback and encouragement on this one! Should I worry
> about the tightness described above or is that something you are able
> to adjust for? I noticed that in some transitions the buffered data to
> compute the transition w
On Sun, Apr 14, 2019 at 3:18 PM Romain Beauxis
wrote:
>
> Glad to read all that. The operator's logic is quite complex so I
> think it is working but there can be corner cases. One thing that I
> can recommend, however, would be to set conservative to false if you
> start seeing issues.
Good af
On Sat, Apr 13, 2019 at 11:39 PM Romain Beauxis
wrote:
> Hi John,
>
> Indeed, it looks like there was an issue with this part of the code. It
> _should_ be fixed now. Let me know if you get a chance to try it!
>
>
Good morning Romain,
Something is working. And (based on three transitions auditio
On Sat, Apr 13, 2019 at 3:42 PM Romain Beauxis
wrote:
> Hi John,
>
> the parameter in the cross() function is now called "duration_override"
> and the metadata is "liq_cross_duration". It'd be nice if you had a minute
> to confirm that it works as intended for you! The commit should be in the
> `
On Wed, Apr 10, 2019 at 2:05 AM Romain Beauxis
wrote:
> Hi John,
>
> I just pushed the backport of the override metadata. For clarity purposes,
the parameter in the cross() function is now called "duration_override" and
the metadata is "liq_cross_duration". It'd be nice if you had a minute to
con
On Sat, 6 Apr 2019, 14:59 joannahaiden, wrote:
> Have very basic icecast streaming requirement constantly stream a MP3
> playlist, that is it. Nothing else fancy. ezstream has been working well
> for years, but it seems dead development-wise, and is clunky if you want
> several streams.
>
> I hav
On Thu, Mar 21, 2019 at 1:47 AM Romain Beauxis wrote:
>
> Hi,
>
> This is the perfect type of feeback I was looking for! I'm keeping this
> active and will try to resume work on this branch ASAP.
You're most welcome. Experiments always good to try, here. Liquidsoap
sips so gently at the CPU ther
On Thu, Mar 14, 2019 at 2:08 AM Romain Beauxis
wrote:
> The PR for the crossfade rewrite is pending here:
> https://github.com/savonet/liquidsoap/pull/705
>
> Perhaps you could give it a try? Essentially, the only thing you should
> have to change is that the simple `crossfade` is removed and
> `
On Thu, Mar 14, 2019 at 2:08 AM Romain Beauxis
wrote:
> The PR for the crossfade rewrite is pending here:
> https://github.com/savonet/liquidsoap/pull/705
>
> ...
> Perhaps you could give it a try? Essentially, the only thing you should
> have to change is that the simple `crossfade` is removed a
Good morning,
While running the latest dev master, cross-fading using the "crossfade"
operator has stopped after about six days' operation. Now, Romain, I
remember you were re-implementing this operator, and had already changed
something. Should I change one of my commands, also?
A transition nor
On Thu, Feb 28, 2019 at 1:44 AM Romain Beauxis
wrote:
> Thanks for reporting this one guys. That was easy to fix an typically the
> kind of things that's great to find out in early testing phases!
>
Thanks for looking into this—and fixing it!
I'm now on git master and it's been up for about 24 h
On Thu, Feb 21, 2019 at 4:25 PM Romain Beauxis
wrote:
> Hey! Thanks for chiming in. The fade operators are deeply rewritten in
> this alpha branch and I'm suspecting that's where the issue comes from
>
Indeed, the same is still happening (very loud amplification) on the latest
git master (is ther
On Mon, Feb 18, 2019 at 3:01 PM Romain Beauxis wrote:
> Ho I see. I would suggest to first try it with the smart_crossfade instead. I
> am planning on deprecating/retiring the crossfade() operator. In particular,
> I discovered that the code does not properly allow garbage collection of
> trans
On Mon, Feb 18, 2019 at 2:37 PM Romain Beauxis wrote:
> What is your crossfade code? The crossfade transition buffers a limited
> amount of data, 5 seconds by default. If the transition takes longer than
> that to execute, it will stop. You can increase this value via the start_next
> paramete
Hello!
I've noticed that, after a few days' operation, crossfading stops
working. Tracks still play, but they're not blended.
This seems to co-incide with no further appearances in the debug log
of the words "buffer" or "buffering". Here's a complete log from one
particular transition, the last t
On Thu, Feb 7, 2019 at 5:58 PM Romain Beauxis
wrote:
> Hey John,
>
> Do you have any update on that? I can't reproduce locally.
>
> What would help I believe would be to compare the override amplification
> values with both version. Should be logs of the form:
> Overriding amplification: 2.5703
On Sat, Feb 2, 2019 at 9:32 PM Romain Beauxis wrote:
> There shouldn't be any chance on that part of the code. I'm happy to
> investigate anything that looks wrong if you can share some of your script/a
> way to reproduce.
Certainly. Happy to do so.
The difficulty appears when using crossfade
On Sat, Feb 2, 2019 at 3:52 PM Romain Beauxis wrote:
> You're using smart_crossfade, right?
Thank you for asking. I have not experimented with smart_crossfade.
Incidentally, has some code changed regarding "amplify"? My playlist
contains gains (see below) in dB but, as of 1.4.0-alpha1, those
req
On Sat, Feb 2, 2019 at 12:18 PM p g wrote:
> i'm running the new alpha [windows] now. the build date is recent, but
> internal version reads like this:
>
> version
> Liquidsoap 1.3.5+scm
Interesting. I just compiled from git, and it starts up with
2019/02/02 15:16:22 [main:3] Liquidsoap 1.4.0+scm
On Wed, Jan 30, 2019 at 5:09 PM Gilles Pietri wrote:
>
> Le 30/01/2019 à 12:53, Damian a écrit :
> > Hi,
> >
> > I am running liquidsoap 1.3.6 and I have followed the instructions for
> > applying replay_gain in the docs here
> > https://www.liquidsoap.info/doc-1.3.3/replay_gain.html
> > I believe
On Wed, Jan 23, 2019 at 4:01 PM Romain Beauxis
wrote:
> 1.3.6 (23-01-2019)
Well, my on-test hybrid of a Liquidsoap playlist running through FFmpeg for
processing, and several 'expect' scripts feeding into the telnet interface
(because I don't quite 'get' the timings and queues of the Liquidsoap
On Wed, Jan 9, 2019 at 5:17 PM Romain Beauxis
wrote:
> Hi John, sorry for the late response.
>
> It looks like the curl call is timing out. The curl call is working
> locally here.
>
>> When attempting to use an http-protocol link in a script, Liquidsoap
>> calls curl as expected, but the success
Good morning,
When attempting to use an http-protocol link in a script, Liquidsoap calls
curl as expected, but the success of the curl process seems undetected by
the calling program.
I have debugged by altering protocols.liq to change the curl command line
to dump curl's errors into a file (ther
Good morning,
I'm making my first steps in programming Liquidsoap. One of my day-jobs is
reading news for commercial radio, but all we do is 'dispatch' bulletins
into Zetta, and I occasionally see studio screens, but that's all I know
about automation.
To help determine track ends (or fade-outs)
Before I put tags such as "liq_start_next" into my library files, can
I check whether tag names are case sensitive? Taglib converts tag
names to upper case (e.g. "LIQ_START_NEXT" comes back from the file)
whereas FFmpeg, in some containers, doesn't.
Must "LIQ_START_NEXT" be always lowercase as giv
On Wed, Oct 3, 2018 at 10:19 AM Gilou wrote:
> Le 03/10/2018 à 09:42, John Warburton a écrit :
> > I
> > I'd like the system to perform automatic crossfades (actually,
> > superimposed playing without fades) which begin when the loudness of the
> > first piece o
ow them
detecting the fade-out of a track, but relying on a fixed duration fade
over the end of a track. Have I missed something here?
You may already know how to do this, and I've missed it in the
documentation, which would be a matter of regret for me!
Kind regards,
John Warburton
51 matches
Mail list logo
