Simian has the three "decks" that it loads events into, so that it is always in some "position" to do stuff before loading the next days logs. Those decks then become the "timeline" of events to perform. I think it would work well to think about the problem from a "virtualization" perspective. The chain of "events" that are in the logs need to be virtualized into a separate "shorter" list. I am not sure if "20" is a good number, I haven't really thought about it.
Once the play out list is virtually separated from the logs, then it becomes easy to manage a number of issues. Gregg On Sep 17, 2012, at 1:49 PM, Nathan Steele <[email protected]> wrote: > The issues discussed by the OP have been my biggest problem with RD, I > would love to see changes that worked and made them a thing of the past. > Though I have since been able to overcome most issues, I did about a > month ago start having problems again. Tried many things and eventually > what worked was exactly what we were doing before....no idea why it > didn't work right the 4 days in a row that it didn't. I like the thought > of a rolling log. I assume this would allow one to VT and not reload the > log as long as you are VT'ing ahead of the "buffer" 20 events or 1 hour > or whatever is decided. I know we could use the auto update log feature, > but I have decided the potential for danger is too high, so for now if > they VT in the same day they have to reload the log, which occasionally > results in playing a song over again..... > > Nathaniel C. Steele > Assistant Chief Engineer/Technical Director > WTRM-FM / TheCrossFM > > On 9/17/2012 1:46 PM, Cowboy wrote: >> On Monday 17 September 2012 01:31:38 pm Wayne Merricks wrote: >>> This is more complex in terms of required changes but has some benefits >>> (and drawbacks). For example airplay always populates with x items to >>> play. Lets say 20 for now. When event 1 starts playing, event 21 is >>> appended to the end of the list. >>> >>> If we get a log chain we append event 1 of the that new log to the end. >> Personally, I like it. >> I'm also somewhat taken aback that it hasn't come up before !? >> >> Yet another advantage would be that if there were some problem >> with the newly appended event ( file not found, whatever ) you'd have >> the time of those pending 20 events to fix or replace. >> >> It's a paradigm shift, but one likely worth considering. >> > > _______________________________________________ > Rivendell-dev mailing list > [email protected] > http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev _______________________________________________ Rivendell-dev mailing list [email protected] http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
