Hi Marcin,
Thanks for detailing your problem. I'm glad to hear that you somehow
solved it for now, although the hack, as you said, is not 100% accurate,
and a bit redundant.
I think liquidsoap has a nicer answer for your first approach. You need
to push a constraint with a hard timing constraint, why not use a second
queue with higher priority ?
fallback([request.dynamic(id="special",..),
request.dynamic(id="usual",..)])
You could even set the fallback to be track insensitive and cut "usual"
tracks in the middle for a very precise timing -- of course, a
transition is needed to make that sound good.
Having two queues might seem messy. If your scheduler is the kind of
tool that needs to know at which time any track is played, it's not a
solution. However, if for your tool most tracks are just (smart) random
filling while only some special ones have a time constraint, this kind
of setup should do. Does that sound good to you ?
By the way, is your scheduler project public ? We're still looking for
the killer open-source scheduler that should sit next to liquidsoap. I
know several radios that have their own stuff developed from scratch,
but no nice tool that is both high-level and flexible.
--
David
