Re: [RDD] Pitch Control (Again)
5% is way too high. .5% to about 2% is about the range. 2.5% is really noticeable. The point of the technique is to make a competitor playing your music to sound sluggish to button pushers. Sent from my iPhone On Nov 23, 2014, at 9:34 PM, "Lorne Tyndale" wrote: > Hi, > > If you run rddbcheck after you change your audio file, it'll go through > and fix the cart/cut lengths in the database, based on the actual > lengths of the audio tracks (I just did a quick test on a test file / > machine I have running an audio file through SOX and speeding it up 5%). > > However as you point out this won't fix any segue / talk time / hooks / > other markers there. > > But for me I'm putting it to my backup. Even at only 5%, the Dire > Straights track I picked as a test just does not sound right. > > Another suggestion that I have - when you make a backup of your > /var/snd, also grab a backup of your database. > > > > > >> Hi, >> >> Beware that if you are applying this to an existing library; there are >> cart lengths/average_lengths in the CARTS table and I'm pretty sure cut >> lengths in the CUT table. >> >> It would also throw off any segue/talk time/hook/cut start/end markers >> you had put in. >> >> Should be possible to script a 5% increase and adjust markers >> accordingly rather than manually changing everything. >> >> On 2014-11-23 20:50, Lorne Tyndale wrote: I think the answer in this case is clear: pitch alteration belongs in the production room, not the air chain. >>> >>> I tend to agree with this too. >>> >>> Another option that I could point out - which essentially would be >>> the >>> same as doing the alteration in production only without the human >>> element involved (thus automating the process for those with large >>> libraries). With a few MySQL queries and some scripting it would be >>> possible to generate a list of the audio file names in /var/snd for >>> which audio pitch speedup is desired. Then - make a backup of >>> /var/snd >>> (so you'll still have the original) and write a script to use SOX to >>> automate the modifying / pitch speed up of any audio tracks you want >>> to >>> perform that effect on and have that script put the new versions of >>> the >>> files in /var/snd (make sure they have the same file name as the old >>> file name). This should have a similar end-effect of modifying each >>> one >>> in something like Audacity, without the need to sit there and go into >>> each file. >>> >>> Writing such code should be relatively trivial and potentially >>> provide >>> the desired result. Since it would not modify any of the Rivendell >>> source code it would be unlikely to break anything. And going back >>> to >>> the original would simply be a matter of restoring the needed files >>> from >>> backup. >>> >>> Of course without someone listening to each track (as you would when >>> editing each one) you'd lose the human ability to make sure things >>> still sound good. >>> >>> >>> ___ >>> 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 > ___ > 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
Re: [RDD] Pitch Control (Again)
Hi, If you run rddbcheck after you change your audio file, it'll go through and fix the cart/cut lengths in the database, based on the actual lengths of the audio tracks (I just did a quick test on a test file / machine I have running an audio file through SOX and speeding it up 5%). However as you point out this won't fix any segue / talk time / hooks / other markers there. But for me I'm putting it to my backup. Even at only 5%, the Dire Straights track I picked as a test just does not sound right. Another suggestion that I have - when you make a backup of your /var/snd, also grab a backup of your database. > Hi, > > Beware that if you are applying this to an existing library; there are > cart lengths/average_lengths in the CARTS table and I'm pretty sure cut > lengths in the CUT table. > > It would also throw off any segue/talk time/hook/cut start/end markers > you had put in. > > Should be possible to script a 5% increase and adjust markers > accordingly rather than manually changing everything. > > On 2014-11-23 20:50, Lorne Tyndale wrote: > >> I think the answer in this case is clear: pitch alteration belongs > >> in the production room, not the air chain. > > > > I tend to agree with this too. > > > > Another option that I could point out - which essentially would be > > the > > same as doing the alteration in production only without the human > > element involved (thus automating the process for those with large > > libraries). With a few MySQL queries and some scripting it would be > > possible to generate a list of the audio file names in /var/snd for > > which audio pitch speedup is desired. Then - make a backup of > > /var/snd > > (so you'll still have the original) and write a script to use SOX to > > automate the modifying / pitch speed up of any audio tracks you want > > to > > perform that effect on and have that script put the new versions of > > the > > files in /var/snd (make sure they have the same file name as the old > > file name). This should have a similar end-effect of modifying each > > one > > in something like Audacity, without the need to sit there and go into > > each file. > > > > Writing such code should be relatively trivial and potentially > > provide > > the desired result. Since it would not modify any of the Rivendell > > source code it would be unlikely to break anything. And going back > > to > > the original would simply be a matter of restoring the needed files > > from > > backup. > > > > Of course without someone listening to each track (as you would when > > editing each one) you'd lose the human ability to make sure things > > still sound good. > > > > > > ___ > > 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 ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Pitch Control (Again)
Hi, Beware that if you are applying this to an existing library; there are cart lengths/average_lengths in the CARTS table and I'm pretty sure cut lengths in the CUT table. It would also throw off any segue/talk time/hook/cut start/end markers you had put in. Should be possible to script a 5% increase and adjust markers accordingly rather than manually changing everything. On 2014-11-23 20:50, Lorne Tyndale wrote: I think the answer in this case is clear: pitch alteration belongs in the production room, not the air chain. I tend to agree with this too. Another option that I could point out - which essentially would be the same as doing the alteration in production only without the human element involved (thus automating the process for those with large libraries). With a few MySQL queries and some scripting it would be possible to generate a list of the audio file names in /var/snd for which audio pitch speedup is desired. Then - make a backup of /var/snd (so you'll still have the original) and write a script to use SOX to automate the modifying / pitch speed up of any audio tracks you want to perform that effect on and have that script put the new versions of the files in /var/snd (make sure they have the same file name as the old file name). This should have a similar end-effect of modifying each one in something like Audacity, without the need to sit there and go into each file. Writing such code should be relatively trivial and potentially provide the desired result. Since it would not modify any of the Rivendell source code it would be unlikely to break anything. And going back to the original would simply be a matter of restoring the needed files from backup. Of course without someone listening to each track (as you would when editing each one) you'd lose the human ability to make sure things still sound good. ___ 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
Re: [RDD] Rdairplay jumps backwards...
On 23.11.2014 18:02, Wayne Merricks wrote: Thats why I don't have any hard timed events at the start of a log until 00:30. By making sure your log make's next at 23:59:55 ish at best you'll only have a song or advert/stinger left to play so worst case scenario for a 15 minute song you'll be hitting the start of your new day log at 00:15 ish. I need on every top of the hour the switch to the line in for the news via FM receiver. And at 5 minutes past full the fade/switch of of the news. Followed by the Showopener. I thought you didn't want to cut the song, seems I misunderstood, in that case you're doing exactly what I'm doing. Only on saturday party evening i don't want to cut the songs, because there a no news until 2 a clock in the night. So i have in the saturday log at 00:00 and 00:05 HST events. In your main log put an event just before the log chain and stick it with a hard start make next at 23:59:50 with a play transition. This way you know you'll have your final song playing and then this event followed by the log chain after 23:59:50. Load up your aux log with a very simple set: 23:59:55 A macro that fades down over 5 seconds (be sure to include a sleep 5 line too) and then does a play next on the main log). Then have the aux log chain back to itself so it reloads (or else it will only work once as the event has already played). What actually happens is this: 23:59:50 Main log, shunts all except for currently playing, final event and log chain 23:59:55 Aux Log, fades and then plays next on main log 00:00:00 Main Log hits the play next event (via aux) which chains to the next day. 00:00:01 ish Main log starts playing your news etc for the new day, ready for the 00:05 show opener. It sounds complicated. Maybe you have some screenshots.? ;) I don't think you'd need a timed event for 00:05 I assume your news is a set length and if it isn't, wouldn't that sound weird if the news started saying, "breaking news nuclear missiles incoming to America if you live in Welcome to WMRB Radio, bringing you the hits every day" Hahahaha. Thats what exactly happens every hour. But mostly at the end of the weather. The news from FM are never exact 5 min. long... BTW. Why you use the AUX log.? On the hours with news a have a cart with 4 second silence and a very long fade time in rdairplay for that machine. If you do a hard start fade macro on the main log, the song stops and the macro fades down a whole lot of silence (unless that was changed in a recent version but we're using 2.5 so its not that old). I don't use a fade macro. I play the 3-4 second silence cart. RDairplay fades itself to silence. This is just the way we do it at our station, there is probably lots of ways to work around the problem but this has served us well for over 2 years now. ___ 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
Re: [RDD] Pitch Control (Again)
> I think the answer in this case is clear: pitch alteration belongs in the > production room, not the air chain. I tend to agree with this too. Another option that I could point out - which essentially would be the same as doing the alteration in production only without the human element involved (thus automating the process for those with large libraries). With a few MySQL queries and some scripting it would be possible to generate a list of the audio file names in /var/snd for which audio pitch speedup is desired. Then - make a backup of /var/snd (so you'll still have the original) and write a script to use SOX to automate the modifying / pitch speed up of any audio tracks you want to perform that effect on and have that script put the new versions of the files in /var/snd (make sure they have the same file name as the old file name). This should have a similar end-effect of modifying each one in something like Audacity, without the need to sit there and go into each file. Writing such code should be relatively trivial and potentially provide the desired result. Since it would not modify any of the Rivendell source code it would be unlikely to break anything. And going back to the original would simply be a matter of restoring the needed files from backup. Of course without someone listening to each track (as you would when editing each one) you'd lose the human ability to make sure things still sound good. ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Pitch Control (Again)
agreed On Sun, 2014-11-23 at 15:22 -0500, Frederick Gleason wrote: > > That’s certainly a factor, but not the primary one in my view. Unix design > history has a very strong tradition of building tools that focus on doing one > thing well and then allowing those tools to interoperate, rather than monster > monoliths that try to be all things to all people. This preference turns out > to have all kinds of side benefits, not the least being code with lower > defect rates (bugs) because it allows global code complexity to be held to a > minimum. This is a tradition that I take very seriously when extending > Rivendell. Thus, the first question I ask when looking to add any particular > feature is “does it *have* to be in Rivendell, or is there another place in > the toolchain where this would be better implemented”? I think the answer in > this case is clear: pitch alteration belongs in the production room, not the > air chain. > ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Pitch Control (Again)
actually not, it's the button to disregard the segue marker on the beginning of the next event... semantics aside, I don't think a traditional cold start is going to be a good addition On Sun, 2014-11-23 at 15:22 -0500, Frederick Gleason wrote: > > PS, I am still lobbying for a "cold start switch"! > > Isn’t that that button marked ‘RESET’ on this box next to me? :) > > Cheers! ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Pitch Control (Again)
On Nov 23, 2014, at 11:32 03, John Anderson wrote: > what's obvious, is the Fred isn't likely to do it! Bah! Humbug!! :) > What worries me was the extra cpu usage, That’s certainly a factor, but not the primary one in my view. Unix design history has a very strong tradition of building tools that focus on doing one thing well and then allowing those tools to interoperate, rather than monster monoliths that try to be all things to all people. This preference turns out to have all kinds of side benefits, not the least being code with lower defect rates (bugs) because it allows global code complexity to be held to a minimum. This is a tradition that I take very seriously when extending Rivendell. Thus, the first question I ask when looking to add any particular feature is “does it *have* to be in Rivendell, or is there another place in the toolchain where this would be better implemented”? I think the answer in this case is clear: pitch alteration belongs in the production room, not the air chain. > PS, I am still lobbying for a "cold start switch"! Isn’t that that button marked ‘RESET’ on this box next to me? :) Cheers! |--| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |--| | Perfection is reached, not when there is no longer anything to add, | | but when there is no longer anything to take away. | |-- Antoine de Saint-Exupery | |--| ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Rivendell-dev Digest, Vol 19, Issue 37
On Nov 23, 2014, at 13:04 37, Jim Stewart wrote: > In any case, my gripe here is that it seems that these daemons fail to do > enough sanity checks, and tend to suffer from "race conditions". "ripcd" can > either quietly, not start up, or start up incorrectly if "caed", which > appears to need to start up first, is not yet ready to receive some sort of > communication from it. In the past and present, this has caused many hours of > confusion for me. This is all handled in the stock init script included with the sources. Are you not using this? Cheers! |--| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |--| | A room without books is like a body without a soul. | | -- Cicero| |--| ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Rivendell-dev Digest, Vol 19, Issue 37
Sorry, I guess I over-trimmed the thread behind this post. I've been using Debian Linux (both 32 and 64 bit depending on actual hardware I'm running it on), the primary "on air" machine is still running the older "Squeeze" distribution, everything else I have Rivendell on runs "Wheezy" except for a personal laptop I have that is on "Sid" but is not set up to function for the radio station in any way. I typically use the binaries from Tryphon, but have compiled my own at times to get a latest fix or features. In any case, my gripe here is that it seems that these daemons fail to do enough sanity checks, and tend to suffer from "race conditions". "ripcd" can either quietly, not start up, or start up incorrectly if "caed", which appears to need to start up first, is not yet ready to receive some sort of communication from it. In the past and present, this has caused many hours of confusion for me. Date: Sun, 23 Nov 2014 09:38:17 -0500 From: Cowboy Subject: Re: [RDD] Rivendell Not Recognizing Macros Commands On Saturday 22 November 2014 09:44:52 pm Jim Stewart wrote: > It was all in the ordeal I have to go through to get the Rivendell daemons to > load correctly. > This should not be an issue. What OS ? -- Cowboy ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Rdairplay jumps backwards...
Aha, but what happens, when that last track runs into the hst from the same logs beginning..? At 00:05 a showopener after the news for example. Thats why I don't have any hard timed events at the start of a log until 00:30. By making sure your log make's next at 23:59:55 ish at best you'll only have a song or advert/stinger left to play so worst case scenario for a 15 minute song you'll be hitting the start of your new day log at 00:15 ish. I thought you didn't want to cut the song, seems I misunderstood, in that case you're doing exactly what I'm doing. In your main log put an event just before the log chain and stick it with a hard start make next at 23:59:50 with a play transition. This way you know you'll have your final song playing and then this event followed by the log chain after 23:59:50. Load up your aux log with a very simple set: 23:59:55 A macro that fades down over 5 seconds (be sure to include a sleep 5 line too) and then does a play next on the main log). Then have the aux log chain back to itself so it reloads (or else it will only work once as the event has already played). What actually happens is this: 23:59:50 Main log, shunts all except for currently playing, final event and log chain 23:59:55 Aux Log, fades and then plays next on main log 00:00:00 Main Log hits the play next event (via aux) which chains to the next day. 00:00:01 ish Main log starts playing your news etc for the new day, ready for the 00:05 show opener. I don't think you'd need a timed event for 00:05 I assume your news is a set length and if it isn't, wouldn't that sound weird if the news started saying, "breaking news nuclear missiles incoming to America if you live in Welcome to WMRB Radio, bringing you the hits every day" BTW. Why you use the AUX log.? On the hours with news a have a cart with 4 second silence and a very long fade time in rdairplay for that machine. If you do a hard start fade macro on the main log, the song stops and the macro fades down a whole lot of silence (unless that was changed in a recent version but we're using 2.5 so its not that old). This is just the way we do it at our station, there is probably lots of ways to work around the problem but this has served us well for over 2 years now. ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Pitch Control (Again)
what's obvious, is the Fred isn't likely to do it! that's not saying that someone else might not, and who knows, if it worked without screwing up something else, who knows... What worries me was the extra cpu usage, I don't know if anyone noticed, but since I personally have a bad habit of collecting old hardware and using that, I have seen where some of the newer versions are not as "snappy" as they used to be... (running the software on the new (correct) hardware eliminates that concern) so one has to carefully consider whats added.. PS, I am still lobbying for a "cold start switch"! ja ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Rdairplay jumps backwards...
On 23.11.2014 17:02, Wayne Merricks wrote: Hi, I fought with this when I started. It seems logical to put a hard timed midnight in for a new log but all it achieves are the problems you're experiencing. RD should look at the date, not only the time.? Feature request..?! What I do instead is put the hard times at the end of the log. For example: At 23:59:55 I have a hard timed macro in the aux log that does a fade down over 5 seconds and then loads the next log. In your case what you want is a make next on something before the log chain. That way you won't lose what is currently playing and when that finishes the new log will load. Aha, but what happens, when that last track runs into the hst from the same logs beginning..? At 00:05 a showopener after the news for example. BTW. Why you use the AUX log.? On the hours with news a have a cart with 4 second silence and a very long fade time in rdairplay for that machine. You might experience a second or two delay depending on what your set up is that could be potentially silent when the log loads. I'd love a way of appending logs in advance but that causes other timing issues (e.g. which 23:59 event should you use) so would need extra code to work around. Looking at the date..;) The machine is fast enough. Only 500ms silence. No problem. Regards, Wayne On 2014-11-23 01:18, Ruediger wrote: Hi How can I prevent that rdairplay jumps backward in the log when a cart goes far beyond 0:00 .? I'm playing a 12inch Show from 8:00 PM to 2:00 AM. If a track starts at 11:57 (three minutes to midnight ...) and takes 8 minutes rdairplay stops playing the 12inch track and jumps to the HST newscloser from the beginning of the log. And!. Thats not shown on the "Next HST time..clock" Any hints.? Thanks in advanced. Ruediger ___ 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 ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Rdairplay jumps backwards...
Hi, I fought with this when I started. It seems logical to put a hard timed midnight in for a new log but all it achieves are the problems you're experiencing. What I do instead is put the hard times at the end of the log. For example: At 23:59:55 I have a hard timed macro in the aux log that does a fade down over 5 seconds and then loads the next log. In your case what you want is a make next on something before the log chain. That way you won't lose what is currently playing and when that finishes the new log will load. You might experience a second or two delay depending on what your set up is that could be potentially silent when the log loads. I'd love a way of appending logs in advance but that causes other timing issues (e.g. which 23:59 event should you use) so would need extra code to work around. Regards, Wayne On 2014-11-23 01:18, Ruediger wrote: Hi How can I prevent that rdairplay jumps backward in the log when a cart goes far beyond 0:00 .? I'm playing a 12inch Show from 8:00 PM to 2:00 AM. If a track starts at 11:57 (three minutes to midnight ...) and takes 8 minutes rdairplay stops playing the 12inch track and jumps to the HST newscloser from the beginning of the log. And!. Thats not shown on the "Next HST time..clock" Any hints.? Thanks in advanced. Ruediger ___ 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
Re: [RDD] Pitch Control (Again)
On Sunday 23 November 2014 08:35:13 am Jim Hartranft wrote: > I didn't mean to start an argument but... *I* can appreciate that. If we all always agreed on everything all the time, we would have never advanced beyond the Neanderthal. While Neanderthal had a 1/2 billion year run, their technology never really advanced very far. > In my opinion, and probably many of yours too, Rivendell is #1 out of the > top 6 radio automation systems. Some of us do hold that opinion. ;) > 4 out of the 5 other systems have this > feature. Understood, however we do need to understand that Fred's position is valid. > Whether or not it gets used is different, it would just be nice to > have the feature for those who want to use it. And in a round-a-bout way, you do, by calling an external editor such as Audacity, from within the library pages, to handle content modification. > Maybe this is all irrelevant, but to me it's a good idea. Yes, and to me, *not* having made some changes along the way, so that Rivendell could handle video in addition to or instead of audio as originally envisioned, was a good idea too. But alas, there is no "all things to all people all of the time" regardless of what the politicians like to say. OTOH, the "Open Source" argument is also valid. You ( or anyone for that matter ) is certainly free to add the feature, and once so added, might even be incorporated into the "official" source. -- Cowboy http://cowboy.cwf1.com Some people live life in the fast lane. You're in oncoming traffic. ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Rivendell Not Recognizing Macros Commands
On Saturday 22 November 2014 09:44:52 pm Jim Stewart wrote: > It was all in the ordeal I have to go through to get the Rivendell daemons to > load correctly. > This should not be an issue. What OS ? -- Cowboy http://cowboy.cwf1.com Some people live life in the fast lane. You're in oncoming traffic. ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Pitch Control (Again)
Jim Hartranft writes: > > I am still wishing to pitch shift speed > the music, leave ids and spots. This > should be a feature implemented in > RDLibrary. Running a Top 40 station, > it is almost a must have in my market > as the other pop stations speed their > music up. I had emailed Fred directly > with no response, so hopefully this > gets seen. > > Do not mistake this request for time > stretching, this is an actual speed > change, affecting both time and pitch. > Almost all play out systems have this > feature, and would make Rivendell the > perfect automation system for ANY > format station. > I didn't mean to start an argument but... In my opinion, and probably many of yours too, Rivendell is #1 out of the top 6 radio automation systems. 4 out of the 5 other systems have this feature. Whether or not it gets used is different, it would just be nice to have the feature for those who want to use it. Do I use RDHPIInfo? No, because I don't have an ASI card.. but if I got one, I'd use it. Maybe this is all irrelevant, but to me it's a good idea. ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Importing files from a Rivendell Dropbox
Hi there I think the file importing from a dropbox is working well now. I increased the apache time out value from 300 to 3000 and some test imports have worked well. I presume 300 = 300 seconds = ten minutes and 3000 = 3000 seconds = 100 minutes and when you consider it only took about 10 to 15 mins to import the 52 minute audio files it didn't miss out by much time. Many thanks Geoff Barkman On 11/21/14, Rob Landry <41001...@interpring.com> wrote: > > > On Fri, 21 Nov 2014, Geoff Barkman wrote: > >> Thats interesting about the files importing before they are finished >> copying. I struck that a few years back when copying pcm wave files >> into dropboxes... I assumed the network was too slow... so I assumed. >> I solved it by saving as 320k mp3 and hadn't struck the problem >> since. I wonder if an option would be for a dropbox to wait a few mins >> before it started importing? Perhaps a checkbox or an ability to wait >> x number of minutes before it started importing? > > 30 seconds is usually enough, although it's easy to change the value in my > script. It runs at the top of each minute, checking all subfolders of > /home/scott/import except "bad", which is where invalid files end up, and > any other subfolders listed in an exceptions list. > > If a previous instance of the script is already running the new one > immediately terminates. > > The script will run rdimport on any files with a .wav suffix. Anything > else gets moved to 'bad", along with any file that fails to import. > > > Rob > ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
