> So I wanted to ask you more details about this sentence. It makes me
> think that you don't really need that duration. Something else would
> fit ? Are you asking to flush the queue ?
There're two possibilities to solve my problem.
Consider following test case. You broadcast music, but at 15:00 you want
to emit some programme.
In one solution it must be emitted at 15:00:00. There's need for an
interface that would allow to clear all already buffered music files and
inject next one (with some sort of transition). It's e.g. when you have
radio station with news at every full hour. It also can be used in any
other case, when you need to force liquidsoap to play NOW something that
you choose, because of any reason. In that case I don't need to estimate
duration.
In second solution you allow that your programme would be emitted e.g.
at 15:03:24 which is the time when the last buffered song ends in our
example. But because (at least my one) liquidsoap has 2 more buffered
songs than current one, you have to compute real time, when what's in
liquidsoap buffer would stop playback. Because liquidsoap asks for next
song to buffer when it finishes playback of current one (what's rather
obvious) if you rely on real (clock) time, it can result in that if I
receive request at 15:00, answer with annotate, my next element would be
played e.g. at 15:16, where that 16 minutes are time of already buffered
elements in my example. So I need to react earlier. To react earlier I
need to estimate duration of already buffered elements to know, how much
earlier I need to react.
Currently, I've just have length of any audio file in my scheduler's SQL
database, but that a) is somehow redundant b) doesn't include fade times
c) doesn't include silence stripping. So it's not 100% accurate, but's
currently enough for my project. I telnet to my liquidsoap, take list of
buffered elements ("alive"), then using "metadata <rid>" take SQL ID
(sent before with annotate) of elements that has different rid than
received from "on_air". Then I sum up current.remaining and all lengths
taken from database. Somehow complicated, but works for me.
I wrote my first email before I wrote what I described above, so
currently my problem is solved (maybe without 1st solution, but I think
it's possible to also program it with some combination of 2
request.dynamic and starting/stopping them in some order), I don't
expect anything to be added to liquidsoap. But maybe my point of view (a
person that makes quite professional scheduler based on liquidsoap)
would be valuable.
--
m.
