It could. In fact, rdnexusd could simply create the same flat file that is
currently imported once it detects new data. Nothing in RDLogManager would have
to change.
So I think this is what we have so far:
Changes in RDLibrary are pushed to MusicMaster Library.
Changes in MusicMaster Library ar
On Tue, 2019-05-14 at 15:02 -0700, Patrick Linstruth wrote:
> It's a pull model. The client (Rivendell) initiates all transfers. I
> feel that ManageServices is where the MusicMaster stuff should go.
>
> The library is pretty slick. We can ask for a list of song/metadata
> changes since the last t
> On May 14, 2019, at 2:48 PM, Fred Gleason wrote:
>
> On Tue, 2019-05-14 at 13:53 -0700, Patrick Linstruth wrote:
>> 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
On Tue, 2019-05-14 at 13:53 -0700, Patrick Linstruth wrote:
> 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 co
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 tim
