Hi claudio,
Does this mean that once a (remote) song has been retrieved and
cached, it is considered as *scheduled* and it cannot be removed from
its position in the schedule?
With a request.dynamic(), when a song has been downloaded, it is
indeed definitely scheduled by the request.dynamic() instance, and
cannot be removed. However, this doesn't mean that the song will be
played right after the ongoing track, because you can have whatever
complex stuff on top of your request.dynamic() source.
Let's say that your request.dynamic() source is named dyn.
- decide I want to push a jingle before them?
fallback([jingle,dyn]) does that job. What's jingle ? Maybe a playlist
wrapped in a switch so that it only becomes active every hour
(switch([({ 0m and 0s },playlist(..))])), maybe a request.queue()
which you feed by hand or using an external program.
- skip one of these cached songs and play the next one in cache?
- completely erase this cache and request fresh new songs from the
remote service?
I don't see any way to do that following the previous approach. If you
really need this and would describe why, we could try to think of a
good solution.
With request.queue() (request.editable()) you can only push songs by
hand or with an external program. It won't be called when the cache
gets too empty, so it'd have to query the source quite often to figure
out if something has to be pushed. On the other hand, you gain the
ability to skip queued requests, possibly all of them. I doubt that
one wants to go that way, it's quite inconvenient.
This ability to skip queued requests could be added in a similar way
to all request sources (that includes request.dynamic) but I'd like
this change to be convincingly motivated, as I don't find it very
elegant.
Ready for the next row of questions ;)
--
David
