Hi Chuck,

On 1/30/21 13:14, you wrote:
> May I just interject here--the 3.5 behavior is the correct one, IMO.  I 
> noted a few years ago that if a machine log was stopped and a “make 
> next” command executed, it started that stopped log playing.  On the 
> other hand, if the log was playing and a “make next” command executed, 
> it did NOT start playing at that “make next” position; it just advanced 
> the log to the “make next” position as the next event in the queue; not 
> identical actions.
> 

Thanks for the detailed description. I do recall your previous post, but 
had nothing to add to the conversation at the time.

> It is complex how that affected us, and I explained it at the time, but 
> nothing was done about it.  To try and briefly recap--at the time, we 
> played a recording of the most recent town council meeting once a 
> month.  That often ran longer than an hour.  We run 2 logs, one with 
> only the day’s music, and the second with all the stopsets and programs 
> with macros switching between logs at the appropriate times.  While the 
> second log is playing, the first (music) log waits.  At 23:30 every day, 
> a “make next” marker advances the music log to a position that will put 
> the crossover to the next day’s music log at approximately midnight.
> 
> The town council meeting runs during a public service block that occurs 
> once a month from 22:00 to midnight.  What was happening (in v2.10.3) is 
> that as the council meeting was running, at 23:30, the stopped and 
> waiting music log not only advanced to the “make next” position, but 
> started the next event in that log, resulting in double audio, with 
> music now playing over the town council meeting.  I argued at the time 
> that in a stopped situation, a “make next” command should only advance 
> the log to the “make next” position, NOT additionally start a stopped log.
> 

Ah-ha! That *does* make sense! "Make Next" does just what it says. So, 
maybe Fred (or one of the other developers?) made that intentional 
change somewhere along the line in 3.x... It would be good to know if 
jorge's logs are configured with "Start Immediately" or "Make Next".

> We do not run the council meeting any longer (they did not really want 
> it publicly broadcast, and stopped our airing it, even though it is 
> supposedly open to public attendance--so much for democracy), so there 
> has been no occasion to test it on v3.x.  But from what these posts 
> indicate, the current v3.5 behavior is what we were looking for in v2.10.3.
> 
> --Chuck
> 

I concur with your view that the current behavior is more "correct".

Thanks for your input!

   ~David Klann

> On Sa, 30 Jan 2021 13:19:08 +0000
> David Klann <dxkl...@pm.me <mailto:dxkl...@pm.me>> wrote:
> 
>> Hey drew,
>>
>> On 1/30/21 06:25, you wrote:
>> Jorge,
>>
>> as a part of my bash scripted startup process, I run these scripts after
>> rdairplay starts on my 2.x and 3.x riv boses...
>>   > IIUC, I am not the only riv head doing something like this.
>>
>> It is the rmlsend line at the end of the script that loads the log and
>> starts it playing on the correct cart / spot / time in the log.
>>
>>
>> I understand what you're doing with the scripts (I too do something like
>> this).
>>
>> I believe that what jorge is relying on is the expected behavior of
>> Rivendell to simply wait until the next Timed Event to start when the
>> log is loaded after a power failure (yes, dead air until that happens).
>> I have experienced this: restarting the computer, automatically loading
>> RDAirplay, RDAirplay automatically loading the current day's log, and
>> waiting for the next Timed Event. It just doesn't trigger at the
>> expected time in Rivendell 3.5.0 (on CentOS, so I suspect this is not
>> explicitly an Ubuntu issue).
>>
>> In fact one can test this by stopping RDAirplay normally, then
>> restarting RDAirplay. After restarting, don't initiate playout, just
>> wait for the next Timed Event (you can even modify an existing Event,
>> making it "Timed, Make Next"). Make sure "Operating Mode" is set to
>> "Automatic". The timed event seems to trigger (the left-hand Log display
>> is moved to the current time), but playout does not start. If you modify
>> an Event and set it to "Timed, Start Immediately" it *will* start.
>>
>> So, if I'm tracking jorge, the problem is Timed Events set to "Make
>> Next", and if the Log is not playing, the log will not start by itself.
>>
>> Correct jorge?
>>
>>     ~David Klann
>>      Broadcast Tool & Die
>>
>> all the best,
>>
>> drew
>>
>> On Sat, Jan 30, 2021 at 12:24 AM jorge soto <jsoto3...@gmail.com  
>> <mailto:jsoto3...@gmail.com>  
>> <mailto:jsoto3...@gmail.com  <mailto:jsoto3...@gmail.com>>> wrote:
>>
>>      Hi Drew,
>>      nothing fancy. I start RdAirplay with Session and Startup on Ubuntu.
>>      in Configure RDAirPlay i checked Restart Log After Unclean Shutdown
>>      and load specified log %m/%d/%Y
>>      Legal ID at top of the hour is a hard time, make next event. and the
>>      clock has other hard time, make next events. Works fine on Rivendell
>>      2.19
>>      but on 3.5 lhe events don't start playing.
>>
>>      On Fri, Jan 29, 2021 at 4:54 AM drew Roberts <zotz...@gmail.com  
>> <mailto:zotz...@gmail.com>
>>      <mailto:zotz...@gmail.com  <mailto:zotz...@gmail.com>>> wrote:
>>
>>          Jorge,
>>
>>          iirc, I did have to make changes to the bash scripts that start
>>          things up and load and fire my logs and it was at least partly
>>          due to changes in the database schema...
>>
>>          How were you loading your log, calculating where to start and
>>          then starting the log in that spot?
>>
>>          all the best,
>>
>>          drew
>>
>>          On Fri, Jan 29, 2021 at 1:05 AM jorge soto <jsoto3...@gmail.com  
>> <mailto:jsoto3...@gmail.com>
>>          <mailto:jsoto3...@gmail.com  <mailto:jsoto3...@gmail.com>>> wrote:
>>
>>              I have? a machine running rivendell 2.19. I have hard timed
>>              events and time sync events on the log. whenever there is a
>>              reboot rivendell starts, loads the log and the time sync or
>>              the hard timed events fire and the log starts at the correct
>>              time.
>>
>>              i installed rivendell 3.5 on another machine and what works
>>              on 2.19 doesn't work on
>>              3.5. Did something change?
>>
>>              I tried both ways, with a brand new database and importing
>>              the database from 2.19, neither works. the hard time/time
>>              sync events do bring the log to the correct time but it
>>              doesnt start playing.
>>              _______________________________________________
>>              Rivendell-dev mailing list
>>              Rivendell-dev@lists.rivendellaudio.org  
>> <mailto:Rivendell-dev@lists.rivendellaudio.org>
>>              <mailto:Rivendell-dev@lists.rivendellaudio.org  
>> <mailto:Rivendell-dev@lists.rivendellaudio.org>>
>>              http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
>>
>>
>>
>>          --
>>          Enjoy the *Paradise Island Cam* playing
>>          *Bahamian Or Nuttin* -https://www.paradiseislandcam.com/
>>
>>
>>
>> -- 
>> Enjoy the *Paradise Island Cam* playing
>> *Bahamian Or Nuttin* -https://www.paradiseislandcam.com/
> 

_______________________________________________
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Reply via email to