[RDD] Ideas for Local playback, server sync

Robert Jeffares jeffares.robert at gmail.com
Mon May 7 19:35:14 EDT 2012


Mine is a bit more basic. I have 2 remote stations which update CART
and CUTS direct from MYSQL  [but not at the same time] every hour.

We also update Local Announcements specific to each outpost, so while
the database is replicated the audio goes only where it needs to. the
wav files are short, and bandwith used is well within our allocations.
 Clocks and Logs also get updated. Each outpost gets what it needs.

One central production server. Clones with unique elements.

Syndicated programming gets distributed as mp3 and loaded into the
appropriate carts at each site. The play dates are set in the master
server.

We had to stagger the MySql remote dumps, and we put the Clock and Log
data in a file which gets updated along with weather and stuff because
too much addressing MySql caused a go slow.

all done with shell scripts.

Updating music inventory is possible but is a drain on bandwidth and
takes too long. We put all the new tracks on a USB 1TB and have
someone plug it in at the remote box and ssh in and copy them in to
/var/snd  Monthly update works for us. When they are all loaded it's
simple to take them from the HOLD group and put them where they need
to go.


Regards

Robert Jeffares

The Wireless Station
Big Valley Radio
New Zealand

On Tue, May 1, 2012 at 2:17 AM, Rob Landry <41001140 at interpring.com> wrote:
>
> My approach is to have a master machine at station A which has, in addition
> to the Rivendell MySQL database, another MySQL database called
> Rivendell_sync that has just two tables: CART and CUTS. A Perl script runs
> every five minutes (via cron) and compares the contents of these two tables
> to their counterparts in the Rivendell database. When an addition or change
> is detected, the corresponding /var/snd file is uploaded to the other
> ("slave") machines, followed by a text file containing the contents of the
> relevant Rivendell CART and CUTS records. Then, the Rivendell_sync tables
> are updated to reflect the addition or change.
>
> At each of the "slaves", another Perl script receives the uploads and
> updates the local Rivendell CART and CUTS tables accordingly.
>
> I make no attempt to propagate deletions, but that capability would be easy
> enough to add.
>
>
> Rob
>
> On Fri, 27 Apr 2012, Wayne Merricks wrote:
>
>> Hi all,
>>
>> I've been kicking this around the scary place that is my head for quite a
>> while and thought I'd throw this over to the mailing list for any better
>> ideas.  Apologies for the length of the email, the brain dump got a bit
>> out
>> of control.
>>
>> What I'm trying to achieve is a way of continuing with on air play out in
>> the case of a network failure.  In this particular case its planned
>> failure
>> (my UPS has seen better days).
>>
>> Temporarily I can rsync the /var/snd from the server to the studio file
>> system and then mysql dump (or slave replication) from the server to the
>> studio.  Edit the rd.conf file and kick airplay during a live link and
>> nobody will notice.
>>
>> However it got me thinking about a more permanent solution by trying to
>> make
>> the default situation be that Rivendell plays locally at all times.
>>
>> MySQL:
>>
>> In theory I could set up a multi-master MySQL between the server and
>> critical studios.  You can offset auto-numbers to alleviate race
>> conditions
>> on record inserts however I don't know enough about MySQL to know how it
>> handles updates/deletes and how well/badly it recovers from a network
>> loss.
>>
>> I had a custom program made for call handling (really basic) a few years
>> ago
>> and when I set up a simple slave replicator I found that I couldn't do
>> things like ordered SQL selects with limits e.g. ORDER BY id DESC LIMIT 1
>> as
>> it broke the replication.
>>
>> Problems like this make me think multi master is a bad idea for Riv.
>>
>> /var/snd:
>>
>> Being lazy you'd want something like a continuous rsync.  I looked into
>> things like DBRD and Gluster FS but they all seem to have big warnings
>> about
>> shooting the other node in the head and I gave up at that point.  Then I
>> thought I would do something more intelligent.
>>
>> Have a "drop box"  share on the server that is nothing to do with Riv.
>> When
>> this share receives files a daemon script copies it into the server
>> /var/snd
>> via rdimport.  The output of this gives you the cart number (and as such
>> the
>> file name the cart has).  After the import has finished the script then
>> copies the file to each critical clients /var/snd.
>>
>> This has downsides, the time between the import and the copy (assuming
>> MySQL
>> replication happens right away) could potentially mean this would happen:
>>
>> "Hi presenter, I've imported the news for 12, please shove it into the
>> play
>> list"
>> "OK" <presenter sees a nice big red cart with an audio problem as its
>> still
>> copying across>
>>
>> Would it be easier to just do snapshot updates once an hour (rsync and
>> MySQL) and have some sort of script that tweaked rd.conf and kicked
>> airplay
>> whenever it noticed there was a network outage?  Any DB activity during
>> the
>> outage would kill the slave replication so I'd probably have to
>> script/manually repair the damage before replication continued.
>>
>> I could probably even script in a 30 second Station ID stored locally
>> while
>> the change was taking place so that Riv wasn't strictly needed.
>>
>> Just wondering if this is something anyone has seriously thought about?
>>
>> --
>> Wayne Merricks
>> The Voice Asia
>> 0121 522 6080
>>
>>
>> ____________________________________________________________________________
>> Scanned by MailMarshal
>>
>>
>> ____________________________________________________________________________
>>
>>
>>
>> ____________________________________________________________________________
>> Attention:
>>
>> The information contained in this message is confidential and intended for
>> the addressee(s) only. If you have received this message in error or there
>> are any problems, please notify the originator immediately. The
>>
>> unauthorised use, disclosure, copying or alteration of this message is
>> strictly forbidden. Christian Vision or any of its subsidiaries will not
>> be
>> liable for direct, special, indirect or consequential damages arising from
>> alteration of the contents of this message by a third party or as a result
>> of any virus being passed on. Please note that we reserve the right to
>> monitor and read any e-mails sent or received by the company under the
>> Telecommunications (Lawful Business Practice) (Interception of
>> Communications) Regulation 2000. Christian Vision is registered in England
>> as a limited company 2842414 and as a charity 1031031
>>
>>
>> ____________________________________________________________________________
>>
>
> _______________________________________________
> Rivendell-dev mailing list
> Rivendell-dev at lists.rivendellaudio.org
> http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
>


More information about the Rivendell-dev mailing list