[RDD] Synchronizing carts and logs

Rob Landry 41001140 at interpring.com
Mon Jun 13 16:57:44 EDT 2016

I can't speak for anyone else, but I'm not looking to export Rivendell 
cuts, but to have them show up on a Rivendell system attached to a 
different server.

Say, for instance, my client has two radio stations which I will call WSRO 
(Framingham) and WBAS (Hyannis).

If someone at WSRO records a newscast in Rivendell, I want it to show up 
at WBAS with the same cart number, metadata, and audio; and if someone 
records a spot at WBAS, I want it to show up at WSRO.

Moreover, I also want logs generated at one station to be available at the 

I've been able to make this happen reliably using my Perl scripts, but 
only by reading and writing directly to and from the MySQL CART, CUTS, 
LOGS, and *_LOG tables. I'm looking for an alternative that isn't likely 
to be broken when someone upgrades to a later version of Rivendell that 
might use a different database schema.


Я там, где ребята толковые,
Я там, где плакаты "Вперёд",
Где песни рабочие новые
Страна трудовая поёт.

On Mon, 13 Jun 2016, Fred Gleason wrote:

> On Jun 13, 2016, at 14:33, drew Roberts <zotzbro at gmail.com> wrote:
>       I am not sure about all metadata, but WO puts things like artist
>       and title in the file. When you import into another system, this
>       comes along. (IIRC.)
> This has been true for Rivendell as well for quite some time.
>       It would likely be good if we had the option to leave the file
>       name as cart_cut or change it to something like title_artist or
>       artist_title.
> The main limitation with the current scheme is the relative paucity of
> available metadata fields.  For formats that offer transparent audio
> quality, you’re basically limited to WAV, which means BWF/CartChunk for
> metadata.  Not much there beyond Title, Artist and Client (although there is
> support for providing Start/End, Segue and Talk marker data, a facility
> which Rivendell takes full advantage of).  Various automation vendors have
> proprietary extensions that provide more fields, but those are pretty much
> limited to interoperation within that vendor’s product offerings (and
> Rivendell, which will read a number of those formats).
> While we could go down the road of inventing Yet Another One-Off Metadata
> Format, it’d far more useful to use something that is a bit more industry
> standard while also offering the ability to capture the full range of
> available fields.  Those may be incompatible requirements.  Any ideas?
> Cheers!
> |----------------------------------------------------------------------|
> | Frederick F. Gleason, Jr. |              Chief Developer             |
> |                           |              Paravel Systems             |
> |----------------------------------------------------------------------|
> |     Text processing has made it possible to right-justify any idea,  |
> |            even one which cannot be justified on any other grounds.  |
> |                                                -- J. Finnegan, USC.  |
> |----------------------------------------------------------------------|

More information about the Rivendell-dev mailing list