I have some scripts that do this which update the essential tables CARTS
CUTS SCHEDULE_CODES and migrates the audio. We restrict the updates to news
and essential stuff to conserve bandwaidth.

Robert

On Fri, Jan 13, 2012 at 12:17 PM, Rob Landry <[email protected]>wrote:

>
> One of my clients runs a Rivendell system at each of his stations'
> transmitter sites. Currently he uploads audio files to drop boxes at the
> sites where they get rdimported; but now he wants to use rdlibrary to
> produce cuts in his studio, so I need to figure out how to move the cuts
> and their associated metadata from one database to another.
>
> My current thought is to create a "Rivendell_sync" MySQL database on the
> production file. It will have a copy of the CUTS table, and a script will
> wake up periodically and scan this table and the one in the Rivendell
> database for differences. When it finds one, it will know that a cut has
> been added or changed, and it will copy the corresponding audio file to
> the transmitter site(s) associated with its Rivendell group. Then it will
> send a text file containing the dumped contents of the CART and CUTS
> record for the cut in question.
>
> At the transmitter site, another script will check the incoming text file
> against the CUTS and CART tables in its own Rivendell database. If they
> are different, it will plant the incoming audio file in /var/snd and
> update the two tables with the data from the text file.
>
> My questions of y'all is: does this make sense? What are the potential
> pitfalls? Is there a better way to do this?
>
> Thanks,
>
>
> Rob
>
> _______________________________________________
> 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

Reply via email to