I have not used Replication. At this point in time, I'm mostly working on the RDNexus model and have some command line utilities running.
Dealing with the bi-directional library updates has been fairly straight-forward, as was the "as played" info once I added some playout notifications and timestamp data to RDNotification and RDAirplay. It is the scheduler that has a very specific methodology based on importing a flat file at the time the person wants to do the merge. The mere presence of a file turns the red lights green that data is available for a merge. The concept of the "live log" updates you mentioned doesn't seem to fit the existing architecture. That's why I'm asking so many questions about the logs and merging, since that's an area I have not spent a lot of time in. I'm going to continue working on the RDNexus glue between Rivendell and Nexus using command line tools, and once that interface is ironed out, start looking at the actual integration. At this point I'm leaning towards an rdnexusd daemon and a separate admin/configuration from Replication to handle external schedulers. Hopefully we get more feedback on the subject. Patrick > On May 14, 2019, at 10:18 AM, Fred Gleason <[email protected]> wrote: > > On Mon, 2019-05-13 at 13:12 -0700, Patrick Linstruth wrote: >> My first thought was to have nexusd daemon just make the logs >> directly. This was assuming external music schedulers were used to >> generate all elements of an hour. But after talking to John, people >> use a hybrid system, where RDLogManger clocks contain locally- >> generated events, like legal ids, and only merge part of an hour from >> an external scheduler. > > CC'ing John and Scott into this thread ... > > Actually, *both* models are popular. Facilities that lay on a lot of > mixed programming --e.g. talk and 'ethnic' formats -- typically use the > 'hybrid' model. However, stations that are heavily music-oriented often > want to do *all* of their scheduling in the external music system, with > only very minimal scheduling added in rdlogmanager(1). > > >> With this information, I thought, have nexusd import log events into >> IMPORTER_LINES and merge with RDLogManager like normal. The only >> difference is there wouldn't be a text file moved around and changes >> to the merged log on Rivendell using RDLogEdit would be also be >> updated in MusicMaster. > > Sounds like a reasonable approach. > > >> To facilitate MusicMaster and other schedulers with an API, RDAdmin- >>> Manage Services "Music Data Import" would be updated to choose >> between File, Nexus, etc, and request the appropriate information >> based on import type. > > This of course assumes that scheduling will continue to be done on a > 'batch' basis --i.e. import a finished music schedule at some point > prior to the target log being placed on-air. Then, after the complete > log has been aired, generate a report and send it back to the scheduler > system so it knows what actually aired. > > The point of many 'live log' type setups however is to go beyond that, > allowing a PD to make changes to a music schedule in that scheduler's > native UI and then have the change show up automatically in realtime on > the automation log. Likewise, 'as-played' data from the automation > shows up in the scheduler's native UI synchronously as the events are > actually played on air. Does MusicMaster support such capabilities? > > >> On a positive note, I do have a prototype running that is syncing >> RDLibrary and MusicMaster Library changes with each other. > > Cool! Did you do that through the generic 'Replication' framework in > Rivendell, or was some other approach required? > > >> Scheduling is a whole different animal, which is why I was reaching >> out the list for more education and ideas. > > Yup. We're going 'where no man has gone before' here as far as > Rivendell is concerned. Don't hesitate to include John and Scott (or > even the Rivendell community at Rivendell-devel) in these design > discussions. Those are the guys that live with these workflows every > day, and can provide a lot more insight into what will and will not > work than I in my ivory tower. > > Cheers! > > > |---------------------------------------------------------------------| > | Frederick F. Gleason, Jr. | Chief Developer | > | | Paravel Systems | > |---------------------------------------------------------------------| > | Research is what I'm doing when I don't know what I'm doing. | > | | > | -- Werner von Braun | > |---------------------------------------------------------------------| > _______________________________________________ Rivendell-dev mailing list [email protected] http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
