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]<mailto:[email protected]>>

To: 
[email protected]<mailto:[email protected]>

Subject: [RDD] rmlsend

Message-ID: 
<alpine.DEB.2.00.1402171527290.22011@python<mailto: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

Reply via email to