Hi, As Romain said, there is a not-so-visibly-documented detail about the queues. In liquidsoap, we like our operators to be sure that they can stream audio. The extreme case is when they are infallible, and thus suitable for streaming to listeners. In other case it simply guarantees that you can switch safely to some source, it's ready stream won't disappear in the meantime.
So, queues have two parts. The primary queue contains ready requests, that is ready chunks of stream. The secondary queue contains requests that have not yet been resolved -- resolving means downloading and checking the track. You can see details about these two queues in the "trace <RID>" command output. Because the primary queue is about assurance of streaming, you can't delete anything from it. However, there is no reason except software architecture for not being able to exchange two ready songs, and a couple other harmless changes. All in all, the design could probably be enhanced, and will probably be. This probably won't occur soon, unless someone makes a good proposition (that means simple). Don't hesitate to give a try. Until a better design, you probably want to minimize the number of tracks in this annoying primary queue. You can do that, thanks to the parameters "length" and "default_duration" (see liquidsoap -h request.equeue). For example, use request.queue(length=20., your_source) and you'll have only one track in advance in the primary queue instead of two currently -- or is it really three currently ? Cheers, -- David ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Savonet-devl mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-devl
