Liquidsoap

Reloadable one-time playlists

Details

  • Type: New Feature New Feature
  • Status: Resolved Resolved
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 1.0.0-beta3
  • Fix Version/s: 1.0.0+dev
  • Component/s: Liquidsoap
  • Labels:
    None

Description

It'd be nice to have something like playlist.once() but
reloadable, if possible without interacting with the server at all.
Adding a reload command to playlist.once() would be cool, but even
better could be achieved thanks to notifications: for example, the
playlist's queue could be emptied and reloaded with fresh stuff
whenever the playlist file is re-written.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Romain Beauxis added a comment -
Done in hg commit f40529289ef3 !
Show
Romain Beauxis added a comment - Done in hg commit f40529289ef3 !
Hide
Permalink
Romain Beauxis added a comment -
I forgot to add: we do not support notifications for now.. However, you could build your own using an external notification script..
Show
Romain Beauxis added a comment - I forgot to add: we do not support notifications for now.. However, you could build your own using an external notification script..
Hide
Permalink
David Baelde added a comment -
Cool! I was hoping for Sam to jump in and quickly bind notification libraries (already existing for ocaml) in lang_builtins :p Now only that part remains.

Concerning the second commit: can you really avoid race conditions without a mutex?
Show
David Baelde added a comment - Cool! I was hoping for Sam to jump in and quickly bind notification libraries (already existing for ocaml) in lang_builtins :p Now only that part remains. Concerning the second commit: can you really avoid race conditions without a mutex?
Hide
Permalink
Romain Beauxis added a comment -
Well in fact there is still another issue there that was already present in the original playlist.once: the request.dynamic source loops on trying to pull a new request when the playlist is over and that seems kind of CPU intensive..

One solution would be to pass requests uri to a queue using server.execute but I do not like it that much because I would like to implement everything using language primitives.
Another solution would be to shutdown the source when it is done. I have tried to play with source.dynamic to be able to instanciate a new source when the playlist is reloaded but it does not work since apparently it messes with activations..

I am open to any suggestion :-)
Show
Romain Beauxis added a comment - Well in fact there is still another issue there that was already present in the original playlist.once: the request.dynamic source loops on trying to pull a new request when the playlist is over and that seems kind of CPU intensive.. One solution would be to pass requests uri to a queue using server.execute but I do not like it that much because I would like to implement everything using language primitives. Another solution would be to shutdown the source when it is done. I have tried to play with source.dynamic to be able to instanciate a new source when the playlist is reloaded but it does not work since apparently it messes with activations.. I am open to any suggestion :-)
Hide
Permalink
David Baelde added a comment -
Ah, I see. I thought we had an adaptative delay to avoid burning CPU like that... it must be only for queues. Until we can re-implement queues in the language on top of request.dynamic, using queues might be the most reasonable approach.
Show
David Baelde added a comment - Ah, I see. I thought we had an adaptative delay to avoid burning CPU like that... it must be only for queues. Until we can re-implement queues in the language on top of request.dynamic, using queues might be the most reasonable approach.
Hide
Permalink
Samuel Mimram added a comment -
What about using ocaml-inotify? http://projects.snarc.org/ocaml-inotify/
Show
Samuel Mimram added a comment - What about using ocaml-inotify? http://projects.snarc.org/ocaml-inotify/
Hide
Permalink
Samuel Mimram added a comment -
Lots of details remain to be improved. Reopening.
Show
Samuel Mimram added a comment - Lots of details remain to be improved. Reopening.
Hide
Permalink
Romain Beauxis added a comment -
I agree with reopening. A suppor for inotify would be greate too.
Concerning queues, I'll see about it but I am not sure that we can support the on_done function with it..
Show
Romain Beauxis added a comment - I agree with reopening. A suppor for inotify would be greate too. Concerning queues, I'll see about it but I am not sure that we can support the on_done function with it..
Hide
Permalink
Samuel Mimram added a comment -
Implemented with a callback in the "inotify" branch.
Show
Samuel Mimram added a comment - Implemented with a callback in the "inotify" branch.
Hide
Permalink
Samuel Mimram added a comment -
Fixed in 52ddcab5ef45d177135a62d80e9718b36d7a27f3
Show
Samuel Mimram added a comment - Fixed in 52ddcab5ef45d177135a62d80e9718b36d7a27f3

People

  • Assignee:
    Samuel Mimram
    Reporter:
    Erendil
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: