Never encountered this exact problem, but in my experience, blowing through events has been caused by using Segue transitions. That can be mitigated by using a pause after the command--in my case 2 to 3 seconds of pause does it. If you have 10 seconds of silence you should have plenty to play with. Try a pause after the stop command.
Loading the day-after log has been caused by timed log chain events in our case. Microseconds can count here with race conditions. If a log loads fast enough, it can hit the next day's hard-timed log chain before it plays the first event. But I am assuming your 23:59:10 event is hard-timed, so why it would start that in the morning--even if it blew through the 10AM stop event--seems weird. But even if things went well and 23:59:10 came on time, if the following log chain loads fast enough, it could see the next day's timed 23:59:10 before it plays the proper day's first event--essentially making the log chain a timed event, too. In our case, that stopped happening now that we use 2 logs--one for music and another in Aux 1 for stopsets. The stopset log chain happens in sequence (not timed) after the last stopset program event--which stopset is a make-next at 57 past the hour. TOH ID is the first event in the new day's Aux 1 log. Music log rolls over in a sequenced (not timed) event whenever that log runs out--although we do put in a timed make-next cue event at 11:30 at the point where about 30 minutes of music remains, so it rolls over somewhere close to midnight. Hope that info is useful. --Chuck W. On Sun, 2 Apr 2017 08:21:05 -0400 (EDT) Rob Landry <[email protected]> wrote: > > Folks: > > One of my clients has a Rivendell machine at his transmitter site that plays audio on the air at times and at others will put either > of two studios on the air. > > At 10 AM it's supposed to put the Roxbury studio on the air (Comrex > BRIClink) and STOP until 23:59:10, when it plays ten seconds of > silence and CHAINS to the next days log. > > But sometimes it blows through the STOP and at 10:00:10 loads the > next day's log... and then at midnight, loads the FOLLOWING day's > log. > > This morning I found it running Tuesday's log, having blown through > the STOP transition on Friday, loaded Sunday's log the following > midnight, then blown through the 10 AM STOP transition on Sunday's > log yesterday and loaded Monday's log at 10:00:10, and then loaded > Tuesday's log last night. > > It doesn't always do this; it's been running normally for a month > or so since I upgraded it to RD 2.15.1. But this weekend, it's back > to blowing through STOPs again. > > A similar system at another transmitter site on Cape Cod never does > this; both are running 2.15.1 under Debian 7. > > Have any of y'all encountered anything like this? > > I suppose I'll try to cobble up a macro to run a shell script to > tell rdairplay to stop. > > Rob > > -- > ? ???, ??? ?????? ????????, > ? ???, ??? ??????? "??????", > ??? ????? ??????? ????? > ?????? ???????? ????. _______________________________________________ Rivendell-dev mailing list [email protected] http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
