Early in my investigation I tried having the commands sent twice, but I still had times when neither would get through.
The Perl scripts establishing the TCP connection solved the problem; additionally, both script keep a log, so if something fails to get through, I'll know if the command was never sent by Rivendell, if it waas transmitted but never received, or if Rivendell at the receive end didn't execute it.
Having Rivendell monitor the the switcher's silense sense is an excellent idea. I can have it take over and play local music.
Rob On Tue, 18 Feb 2014, Jim Stewart wrote:
I have yet to routinely send rmls between computers, so therefore have not experienced your reliability problems. UDP, by design, is not reliable, so you might consider sending the same command a couple of times to be sure. I’m thinking it won’t hurt to command an audio reroute a couple of times, or worse case pole the BT switcher for current route (in a script) if you have fade issues during switching. One thing I’ve done is use the Silence Sense function of the BT switcher to trigger a script that takes action on a silence condition. In our case sometimes RDAIRPLAY shuts down just after midnight when attempting to chain to the next day’s log. So one thing the script does is tests to see if RDAIRPLAY is running (ps –C rdairplay) and restarts it and starts it playing if it isn’t. The other silence condition for us is when we are receiving a web stream for rebroadcast and it drops out for some reason, my script also detects this and takes measures to attempt to correct for it. Perhaps you can do something similar? If you happen to be using Jack Audio, you can also get a silence alarm from the “silent Jack” application, I’m using this on a backup Rivendell system. Date: Mon, 17 Feb 2014 15:41:01 -0500 (EST) From: Rob Landry <[email protected]> To: [email protected] Subject: [RDD] rmlsend Message-ID: <alpine.DEB.2.00.1402171527290.22011@python> Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII I have an unusual situation: station A has three studios and six remote feeds (via Barix boxes). Rivendell selects which one to put on the air via a Broadcast Tools 16x4 switcher. Station B is in another market, but co-owned with station A. It has one locakl studio and a hard drive full of pre-recorded stuff but takes programming from station A for part of the day. To get station A on the air, its Rivendell box tell sits local switcher to put the feed from A on line, and then it rmlsends to station A's Rivendell box to select the correct studio or Barix feed to send to B. Most of the time it works, but sometimes it doesn't; the ripcd log at A shows thst the UDP datagrams from B don't always arrive and if one is missed, B gets silence instead of the desired program. So, today I set up a couple of Perl scripts to establish a TCP connection to A to transmit the desired rml, which is then rmlsended to localhost at A. That has worked 100% of the time so far, but I'm curious how others here have nandled this problem. Rob
_______________________________________________ Rivendell-dev mailing list [email protected] http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
