[RDD] rmlsend
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 41001...@interpring.commailto:41001...@interpring.com To: rivendell-dev@lists.rivendellaudio.orgmailto:rivendell-dev@lists.rivendellaudio.org Subject: [RDD] rmlsend Message-ID: alpine.DEB.2.00.1402171527290.22011@pythonmailto: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 Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
[RDD] RDMarkerSet is awesome idea but here is a wish list
The idea of being able to rework portions of an existing library in a bulk manor is great! That said, here are some ideas to make RDMarkerSet a lot more useful to us: 1) Allow an optional cart ranges to be specified as well as the group. This will help deal with when a staff member imports new material into the library, to an existing group, but then does something wrong that can be corrected in a bulk manor. 2) Add the ability to change more markers, specifically the segue markers would be good for us (recalculate to a different dB fade level), but I'm sure the ability to change other markers would be useful for others too. I'd also like the ability to set that Don't fade on Segue option in a bulk manor too (granted someone suggested just doing this in the database directly, but I would sure be nice if a database cheat sheet with tricks like this made it to the wiki for us that don't know SQL). Related to that setting segue levels based on dB of fade, it is real nice having that in the command-line version of rdimport as it gives an excellent starting point when importing music (usually gets it good enough about 90% of the time for us, a real time saver!). I would be nice if an automatic segue setting function like this can be added to the normal GUI import section of rdlibrary as a settable default like the trim levels. Then if that isn't enough, it would also be nice if these settings could be different per groups, for example we don't want to automatically segue commercial traffic! Really I'm happy with how I've been able to automate so many processes in Rivendell/Linux that I haven't been able to do for other broadcasters I work for that use other premium playout systems. ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
[RDD] Too long to save VTs
I've been running Rivendell in a 24/24 basis for about a week. Today I stopped it to record some Vts. I getting the same problem that I stated here a few months ago: - It takes about 50'' to save VT, another to Do Over, ie, any operation regarding VT is taking about 50''. I've backup the database and noticed that it grew from 1.2mb to 3mb in a week, wich corresponds roughly to the period that RD was running 24/24. My setup is a single pc. No network, audio files in the same HD as the DB. Someone answered me the last time giving this possible fix: *Added : innodb-flush-log-at-trx-commit=2 to my.cnf**Now the voicetracker responds in less than a second to the save button.* Question: where in the my.cnf file should I paste this? I've pasted it as the last line and had no effect. ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Too long to save VTs
I believe it should be in the [mysqld] section. That being said, it didn't fix the problem for me. I had to add the noatime flag to the fstab entry for the partition the DB was on. Once I did that, it was pretty fast. On Tue, Feb 18, 2014 at 5:47 PM, Pedro Picoto pedro.pic...@gmail.comwrote: I've been running Rivendell in a 24/24 basis for about a week. Today I stopped it to record some Vts. I getting the same problem that I stated here a few months ago: - It takes about 50'' to save VT, another to Do Over, ie, any operation regarding VT is taking about 50''. I've backup the database and noticed that it grew from 1.2mb to 3mb in a week, wich corresponds roughly to the period that RD was running 24/24. My setup is a single pc. No network, audio files in the same HD as the DB. Someone answered me the last time giving this possible fix: *Added : innodb-flush-log-at-trx-commit=2 to my.cnf**Now the voicetracker responds in less than a second to the save button.* Question: where in the my.cnf file should I paste this? I've pasted it as the last line and had no effect. ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
