Hello there,

I am trying to use and hack liquidsoap-1.0.0.beta1 about dynamic sources
using source.dynamic

I am trying to implement some kind of dynamic scheduling : I want to be able
to add, modify and remove scheduled playlists on the fly, without having to
restart liquidsoap. (It looks like a FAQ, doesn't it ?)

I hacked the source code to implement global string variables via two
functions :
getvar : (string)->string
setvar : (string, string)->unit
for which I also registered some server commands.
(I could have used server.execute("var.get") or something like that, but I
am pretty confident that my issue is not due to this hack. I wonder why
var.get is not directly accessible from the core language, and why it is
necessary to go through server.execute. But this is not my main point here,)

Consider the following minimal example I would like to implement :

I have two "global" variables, var_dyn and var_cond, each of which acts as a
"trigger" when having a special value :
- when var_dyn is triggered, my script dynamically populates the list of
playlists, each of which coming with its own dynamic condition. In our
minimal example, this list is constant.
- when var_cond is triggered, this tells one of my "dynamically" created
playlists to start playing.

I think  the following .liq script should be able to implement this example
:

def test =
 def dyn () =
  def cond () =
   print "cond is run"
   getvar("var_cond") == "ok"
  end
  if getvar("var_dyn") == ""
  then []
  else [ #var_dyn triggers dynamically populating list of playlists (here
considered constant for the sake of simplicity)
   at(cond, single("test.mp3")) #playing this playlist may be triggered
through var_cond
  ]
  end
 end
 source.dynamic(dyn)
end

radio = fallback(test, single("emergency.mp3"))
output.icecast(%mp3, radio) #shortened

The var_dyn trigger works : the list of playlists is accurately populated.
However, the var_cond dynamic condition is never checked, so that I cannot
make my playlist actually play.

This problem seems to have something to do with selection caching in the
definition of the switch operator : if I hack the source code (switch.ml) to
disable it, this problem no longer seems to occur. However, I am not aware
of any nasty consequences of my hack, so I refrain from stating that I
solved the problem.

Have you got an idea of how to improve the situation ? Hoping that you
understood my issues, thank you in advance,

Best regards,

Benoit Avarapi
------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
Savonet-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/savonet-users

Reply via email to