From: okay_awright <oka...@dd...> - 2011-07-18 13:55:13
|
hey On 17/07/2011 09:05, Jean-Francois Mauguit wrote: > Hello, > > On 16 Jul 2011, at 16:16, okay_awright wrote: >> -broadcast a specific track at a specific time, or at least make sure an >> entry from the queue won't be played before some time stamp. Like adding >> a new time property to Liquidsoap's internal queue. This timestamp is >> dynamically computed and cannot be specified in the configuration file. > > Here, we are running 5000 radios using liquidsoap :-) We are using request.dynamic which is calling a service 10 seconds before the end of the current track to know what it has to play next. Our radio planning tool is storing in a db all the planning of the radios and the service has just to get what should be played and returns it to Liquidsoap. So it deliver the right sound at the right moment. RadioDJ could change their planning when they want, it updates the DB and the next LS call will return the new sound to play. > Just out of plain curiosity: how high is the charge on your systems with that many radio stations? how many liquidsoap instances are running? on how many machines? The 10s time limit sounds nice but I don't think I can rely on this, tracks can be located on temporarily congested networks, and depending on user-defined file processing on Liquidsoap's end (e.g. compression) I wouldn't assume buffering times and latencies are always identical. It's after all LS's own duty to manage its queue according to its own timings, and it performs that job wonderfully BTW. Did you ever encountered inconsistencies within your queue with such a short time for injection? Are you files located on a network? what's your effective bandwidth and protocol for fetching files? I wanted that kind of features to take care of situations where no playlist should be played (radio intentionally off air), I think I can simulate that by forcing Liquidsoap to output silence for the given period (using 'blank'). When Liquidsoap is requesting the next track to play, I'll check the retrieved metadata and either switch to a plain request.dynamic(request.create()) if the radio has actually something to play, or blank otherwise. Maybe you can think of something better? Let me know. Perhaps I can do something with at() as well, but its usage sounds obscure and I still don't know if it really interferes with the queue scheduling - BTW I guess the specified time is system-dependant, i.e. based on the server time zone, and cannot go lower than the minute in precision. >> -can play a track for a specified duration only. Like before, this >> duration cannot be part of the configuration file. >> And, finally, if a webservice of some sort (REST, SOAP, whatever) is >> planned in replacement or to complete the Telnet interface. > > Our service called by liquidsoap is able to decide the duration of the track to play (if it has to shorten the tracks due to an top of the hour, news, meteo, or something else it could do it). In fact we are using mp3split in front of liquidsoap to cut the mp3 (get the entry point and the exit point). It sounds reasonable. Do you really cut the mp3 beforehand, or do you just add cue points and use the new cue_cut operator? I you don't really cut tracks, I guess I can just add the related metadata myself, on-the-fly, without relying on mp3split or MP4, FLAC and OGG equivalents. Thanks for your input Jean-François. > > We are using LS 0.9.3 (latest stable release). > > HTH > > Jef > > -- best regards, okay_awright <okay_awright AT ddcr DOT biz> [PGP key on request] |