Re: [RDD] OT (ish): Streaming Advice
Hi all, Thanks for all your replies. I'll have to look into rotter and liquid soap. On the Darkice front, I'm pleased to report that the 1.1 version has been working flawlessly for over 5 days now so I recommend compiling from source if you're a Debian/Ubuntu user. Most of the dependencies for Darkice are similar to Riv's so its not much of a headache to sort out (liblame, libsamplerate etc). The ./configure results spit out errors very close to the package names for whats missing which helps too. I played with the compressors quite extensively and although it helps smooth the sound levels out the audio quality just wasn't good enough for my ears to implement a catch all compressor profile without some baby sitting. Being able to load profiles from the command line for Jamin would certainly help with crash recovery (thankfully not happened yet) and you can solve the Jack problem by using patch bay in QJackCtl. One further tip, for those of you using Live365 but suffering from the DMCA violation delistings (due to no playlists). Setting Live365 to relay mode and taking the feed from icecast works better than pure live mode as I've yet to get kicked back to basic broadcast mode by Live365 (which seems to happen at least once a week). The latency difference is also not noticeable. I swapped from icecast in relay mode to Live365's client running on a Windows machine (live mode) and apart from a slight click and a reduction in volume there was no noticeable difference in song play out position. Audio Quality is also noticeably better from Icecast especially if you're running low bitrates. Regards, Wayne ### 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@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] Log Editing - Anyway to Lock?
Please forgive me any naivety as I've yet to implement Rivendell to fully automate log generation. The only thing I can offer is how Dalet (or at least the old NT4 based version we still use!) works around this problem (not completely successfully) and the work flow of our presenters while using it. Dalet loads logs in 1 hour chunks, with around 15minutes left of play out remaining it loads in the next hours worth of stuff. Whatever is loaded at that time is what ends up on air. At any time a presenter can force reload the log which loads in that particular hours chunk and then automatically scrolls down to where it would be if it had been playing (e.g. 20minutes into the hour). The main thing that changes for us is news reports (5minutes every hour). We leave a "please insert news" tag in the log and the presenter just adds it before the timed news block plays out. The only other thing a presenter generally changes is songs in response to song requests (or when they just hate songs less than 10 years old which is a story for another email). In most cases, I can't see any real reason why two or more people would be working on the same hour/shows log without being near each other. I can see people changing a particular day or at least different shows/hours in the day at the same time however. Perhaps it would be worth splitting the day logs into hours or making the grids show aware and splitting by show (probably assigning grid items to groups)? Theoretically sure you could have 1,000 people editing the same 5 minutes of log and you can think up ingenious ways to work around that but in reality does that really happen and if it does why have you got 3 presenters editing the same 5minutes? Of course you can argue that it could be a user mistake, why not try doing something like a wiki versioning system so that you could at least rollback changes? Regards, Wayne -Original Message- From: rivendell-dev-boun...@lists.rivendellaudio.org on behalf of ltynd...@cogeco.ca Sent: Fri 13/01/2012 21:19 To: rivendell-dev@lists.rivendellaudio.org Subject: Re: [RDD] Log Editing - Anyway to Lock? It comes to mind that maybe we're overlooking a possible option. Right now we have the option for a chain-to in our logs, we also have the ability to load up another log (either in the main log or in one of the AUX logs in RDAirplay). What about an option to merge another log into the current log (kind of like how a copy / paste does)? The workflow would be something along these lines: You've got your broadcast day where: Mary is responsible for 2-3 pm, Joe is responsible for 3-4 pm Mary creates a 2 - 3 pm log, has full editing rights on it Joe creates a 3 - 4 pm log, has full editing rights on it. Neither Mary nor Joe touch the main daily broadcast log. In your main log for the day at 2:00 pm, instead of a Chain-To or a load log into the AUX log, there's a command to merge Merge Mary's Log. At 3:00 pm it merges Joe's log. This could potentially eliminate the confusion that could arise from using both your main and AUX logs. Of course, this would not solve the question of having multiple people editing the same log while live on-air (as in the example that James brought up). And I'm sure there are situations where something like this could/would break. Another question would be whether or not the main log was set to "save" after a "merge" (which I could see potentially causing problems too). But I can also see how a "merge" command could be useful. Just a thought. Lorne Tyndale ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev ### 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
Re: [RDD] Log Editing - Anyway to Lock?
It comes to mind that maybe we're overlooking a possible option. Right now we have the option for a chain-to in our logs, we also have the ability to load up another log (either in the main log or in one of the AUX logs in RDAirplay). What about an option to merge another log into the current log (kind of like how a copy / paste does)? The workflow would be something along these lines: You've got your broadcast day where: Mary is responsible for 2-3 pm, Joe is responsible for 3-4 pm Mary creates a 2 - 3 pm log, has full editing rights on it Joe creates a 3 - 4 pm log, has full editing rights on it. Neither Mary nor Joe touch the main daily broadcast log. In your main log for the day at 2:00 pm, instead of a Chain-To or a load log into the AUX log, there's a command to merge Merge Mary's Log. At 3:00 pm it merges Joe's log. This could potentially eliminate the confusion that could arise from using both your main and AUX logs. Of course, this would not solve the question of having multiple people editing the same log while live on-air (as in the example that James brought up). And I'm sure there are situations where something like this could/would break. Another question would be whether or not the main log was set to "save" after a "merge" (which I could see potentially causing problems too). But I can also see how a "merge" command could be useful. Just a thought. Lorne Tyndale ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] Log Editing - Anyway to Lock?
On Jan 13, 2012, at 14:10 46, Cowboy wrote: > Certainly not the most desirable solution. A timestamp in the DB would also greatly bloat the MySQL binlogs -- not good for replication setups (especially those pulling across slow WAN links). > How much time before a lock is considered stale ? > 10 miliseconds ? > 24 hours ? Neither. Part of the lock includes the ID of the process that created it. If that process is still alive, then _prima facie_ the lock is considered valid and hence honored. If not, then it's stale and can be safely broken. This is why we'd need system-wide IPC. > What if someone has opened a file for edit, forgot to close, > and left for the weekend ? It could happen. Likely. Virtually certain in fact, if past experience is any guide. :) > Forseeing the possibilities, and unintended consequences, > is the hard part. Always is. Hence this list. Cheers! |-| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |-| | Harrisberger's Fourth Law of the Lab: | | Experience is directly proportional to the amount of equipment| | ruined. | |-| ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] Log Editing - Anyway to Lock?
On Fri, 13 Jan 2012, Aaron Horn wrote: > Our issue is that we are loosing a boat load of content, it seems that > this occurs when the log is open in more than one location... So the > log is being played out on RDAirPlay in Studio 1 but a user makes > changes to the log in Studio 2 on RDLogEdit - if the user in Studio 2 > saves all their work but then someone in another studio saves also, > their work is lost. Many years ago I had a similar problem at WCRB with a music scheduling program I wrote. In those days announcers scheduled their own music, and two or three of them would often be working on the same schedule. I solved the problem by writing each transaction into the database immediately, then repainting the screen with the current database content. Thus, if another user made a change in the meantime, it would be reflected in the new screen content. It wasn't perfect, but it was good enough. In terms of Rivendell, each user needs to sign out a log for a period of time: Joe gets Saturday from 2 to 3; Molly gets Saturday from 3 to 4; or else one can assign specific logs to specific individuals. Rob ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] Log Editing - Anyway to Lock?
On 13/01/2012 19:10, Cowboy wrote: > On Friday 13 January 2012 02:02:06 pm Fred Gleason wrote: >> although writing and polling a timestamp in the DB might be viable as well. > Certainly not the most desirable solution. > How much time before a lock is considered stale ? > 10 miliseconds ? > 24 hours ? > What if someone has opened a file for edit, forgot to close, > and left for the weekend ? It could happen. > Ridiculous ? Maybe. > Forseeing the possibilities, and unintended consequences, > is the hard part. > > Perhaps a lock that can only be removed by the process creating it, > OR by an administrative over-ride. Admin manual intervention. > This is why I originally tended away from the locking issue and gravitated towards global instant updates. It gets messy... Perhaps it's best to consider alternative solutions. If you could create a log which behaved as a normal log but was actually composed of multiple logs under the hood, then much of this problem could be avoided. Call it a metalog - you make a daily metalog which consists of all your logs for your shows (each one a metalog entry). Each show can then edit their log without breaking anyone else's logs, and in rdairplay the whole shebang is treated as a generic log; edits are made to the underlying logs, playout is as if it were one continuous log. I'm going to assume/sort of know this would be a heck of a lot of work to implement, but it might end up being a more flexible solution that could solve other problems in similar areas. If it's a choice between one large project and another large project, there's a good argument for making it at least a project that adds functionality rather than limiting it... ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] Log Editing - Anyway to Lock?
On Jan 13, 2012, at 14:04 14, James Harrison wrote: > I think that would be a perfect solution, yeah, assuming you can > effectively merge the changes, warn the user that you've done so, and > let them review the resulting log post-merge. That's the rub. There are times when an automatic merge will just not be possible. An extreme example: 1) Users A and B each open the same log. 2) User A completely deletes the contents of said log, adds a bunch of new events, and saves it. 3) User B completely deletes the contents of said log, adds a bunch of *different* (from User A) events, and saves it. How do we merge the two new logs? In this case, the context of the original, common log has been completely lost, so there is no sane way to determine automatically how this 'merge' ought to happen. 'Ask the user' is hence the only viable option. (This, in fact, is exactly what CVS does when it runs into the analogous situation where two different users have made conflicting changes to the same piece of code.) Now, from a UI and workflow perspective, how do we present this to a user? Cheers! |-| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |-| | Threads -- Threat or Menace? | | | | -- chapter heading from| | "The Art of UNIX Programming" | | by Eric Raymond | |-| ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] Log Editing - Anyway to Lock?
On Friday 13 January 2012 02:02:06 pm Fred Gleason wrote: > although writing and polling a timestamp in the DB might be viable as well. Certainly not the most desirable solution. How much time before a lock is considered stale ? 10 miliseconds ? 24 hours ? What if someone has opened a file for edit, forgot to close, and left for the weekend ? It could happen. Ridiculous ? Maybe. Forseeing the possibilities, and unintended consequences, is the hard part. Perhaps a lock that can only be removed by the process creating it, OR by an administrative over-ride. Admin manual intervention. -- Cowboy http://cowboy.cwf1.com Justice is incidental to law and order. -- J. Edgar Hoover ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] Log Editing - Anyway to Lock?
On Jan 13, 2012, at 13:55 34, Cowboy wrote: > OK, I want to do this, and then that, then the other thing. > Oh, wait, I didn't really want to do that, so I reload without save, > getting back to where I started. > That's what you've broken. Yup. There's also the scenario where I want to make an entirely *new* log, using SaveAs, but don't want any of those changes going into the original. Being able explicitly to control when changes get committed can be a powerful feature. 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://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] Log Editing - Anyway to Lock?
On 13/01/2012 18:55, Cowboy wrote: > On Friday 13 January 2012 01:34:08 pm James Harrison wrote: >> Are there >> any workflows which would be broken by making this the default >> behaviour, > OK, I want to do this, and then that, then the other thing. > Oh, wait, I didn't really want to do that, so I reload without save, > getting back to where I started. > That's what you've broken. Ah, yeah, okay. > >> or do I need to look at making this a configurable option? > I ( as long time readers know ) *always* vote for configurable, > preferably by admin. > >> I >> can't immediately think of any issues this could cause and suspect that >> this would actually be a nice change for everyone in terms of ease of >> use in any case. > This is usually the kind of thing that causes unintended consequences > to become manifest with catastrophic results, for someone. > Such is *why* I always vote configurable. > > Frankly, it seems a better behaviour would be to check before > saving that what was loaded still matches what would be loaded now. > If different, someone else changed something that may conflict. > Toss up a warning. > If no changes have appeared, then lock, save, unlock. > I think that would be a perfect solution, yeah, assuming you can effectively merge the changes, warn the user that you've done so, and let them review the resulting log post-merge. If that's doable, then we'd end up with logs that can be collaboratively edited without loss of data while not affecting any existing workflows, which would be great James ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] Log Editing - Anyway to Lock?
On Jan 13, 2012, at 10:47 15, Aaron Horn wrote: > To me the solution is to remove the 'save' button and have any changes > reflected live on every computer with that log open in an immediate > sense. This merely pushes the basic problem down a level. You'll still have users nuking each other's changes, not to mention that there are times that you don't *want* a change saved system-wide, but only locally. > Either that or lock logs (e.g. 'this log is being edited at location xyz, > please close there before editing the log'). Yes, some sort of locking will be required to resolve this sort of thing, either at the level of entire logs or some section thereof (e.g. 'morning drive', 'middays', 'afternoon drive', etc). Infrastructure-wise, two things are required: 1) A way to assert a system-wide lock 2) A way to detect and break stale locks (e.g. after a system that has created a lock dies unexpectedly) Number 2) is the more difficult of the two. Optimally, some sort of inter-workstation IPC would do the trick, although writing and polling a timestamp in the DB might be viable as well. Not a trivial undertaking, either way. 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://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] Log Editing - Anyway to Lock?
On Friday 13 January 2012 01:34:08 pm James Harrison wrote: > Are there > any workflows which would be broken by making this the default > behaviour, OK, I want to do this, and then that, then the other thing. Oh, wait, I didn't really want to do that, so I reload without save, getting back to where I started. That's what you've broken. > or do I need to look at making this a configurable option? I ( as long time readers know ) *always* vote for configurable, preferably by admin. > I > can't immediately think of any issues this could cause and suspect that > this would actually be a nice change for everyone in terms of ease of > use in any case. This is usually the kind of thing that causes unintended consequences to become manifest with catastrophic results, for someone. Such is *why* I always vote configurable. Frankly, it seems a better behaviour would be to check before saving that what was loaded still matches what would be loaded now. If different, someone else changed something that may conflict. Toss up a warning. If no changes have appeared, then lock, save, unlock. -- Cowboy http://cowboy.cwf1.com Justice is incidental to law and order. -- J. Edgar Hoover ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] Log Editing - Anyway to Lock?
This issue is one of the reasons we ended up not switching to Rivendell at a student station (also in the UK) last year - much smaller setup, one studio PC and three production PCs. (That station is now running Rivendell for backup playout, at least, and it's been utterly flawlessly reliable while doing so!) Currently we're using P Squared's Myriad 3.6, which does at least manage (most of the time) not to have this problem - log edits are made on the server immediately and there's no 'saving' of logs. As soon as a change is made, it's reflected everywhere. In my mind this is the best way to go - there's no awkward "Oops, forgot to save" moments, and it allows collaborative editing. The downside in Myriad is there's only one log, split up into hours, and we've had issues with log corruption before (related to the flatfile DB format, no doubt - not something that would be an issue in a real DBMS like MySQL as long as atomicity is managed properly). An example would be one student in the studio playing off content and doing links with another student in production for the first half hour of the show loading on the rest of the show content and adding it to the log. We had other scenarios with talk or debate shows where a student in the production room is cueing music for the presenters in the studio for their breaks, and like Aaron mentions, having the main log be actual content rather than automation would become an issue for us, as this is currently our main workflow and couldn't be changed easily. This is certainly a huge issue for student station adoption and fixing this would be awesome. I don't think this is a workflow issue - we did have a really good long stare at how to work around this and came up blank when we were considering RD for primary playout at our station. It's either main log = automation only, load logs, etc, or problems arise. And making the main log automation only is most decidedly quite clunky and hard to manage. Nathan's suggestion on the aux/main log switching is the best thing we came up with, but for student presenters, it's a bit much to manage and can confuse the heck out of people. We're not working with professionals with support sat in the room next door, sadly :-) simpler is better in this case, very much so. I've got an evening to kill over here so I'm going to have a stab at the latest sources and see if I can come up with a patch to do away with the 'Save' button and have any changes trigger a save and reload. Are there any workflows which would be broken by making this the default behaviour, or do I need to look at making this a configurable option? I can't immediately think of any issues this could cause and suspect that this would actually be a nice change for everyone in terms of ease of use in any case. Cheers, James Harrison On 13/01/2012 16:05, Nathan Steele wrote: > Actually I thin the first suggestion I made will not work now as I > reread what you want to domaybe it will, I dunno. I still think the > second suggestion would be better for you. Yes I think I would go that > route. Create macros to load each students(or team of students) show > into the aux log, and start the playback of the aux log, and stop down > the main log. Then at the end of their show it needs to have a macro to > start the main log back up. I'm sure there are many other ways to > achieve the same end, this is just a simplified suggestion. Timing and > commercials or spots would be the tricky part, but I'm sure there is a > solution. > > Nathaniel C. Steele > Assistant Chief Engineer/Technical Director > WTRM-FM / TheCrossFM > > > On 1/13/2012 10:57 AM, Nathan Steele wrote: >> In RDAdmin under service there is a check box to enable "autorefresh" >> this will update the log on RDAirplay I think whenever it is edited. >> maybe that would do what you want. >> >> But, why not make the Airplay log with macros that load and play the >> students show logs, and they create their own logs for their shows that >> way no one is accessing a "shared log"? You would not even need to use >> the autorefresh (which can be dangerous). just a thought. >> >> Nathaniel C. Steele >> Assistant Chief Engineer/Technical Director >> WTRM-FM / TheCrossFM >> >> >> On 1/13/2012 10:47 AM, Aaron Horn wrote: >>> Hi there... >>> >>> I have a bit of an issue with Rivendell... We use 1.7.2 on Ubuntu >>> Studio 10.something with ASI soundcards - so far so good. I have an >>> upgrade to 2x planned around Easter. >>> >>> We are a teaching university have have two on-air studios plus three >>> satellite studios. They all share a ZFS audio share and MySQL >>> database on a server. >>> >>> Unlike traditional radio settings, we use a highly corroborative >>> approach to put together our on-air content. That is, many people put >>> together the logs etc. >>> >>> We generate clocks but each show team comes in before their show to >>> edit their section of the day log... The typical
Re: [RDD] Log Editing - Anyway to Lock?
> Our issue is that we are loosing a boat load of content, it seems that > this occurs when the log is open in more than one location... So the > log is being played out on RDAirPlay in Studio 1 but a user makes > changes to the log in Studio 2 on RDLogEdit - if the user in Studio 2 > saves all their work but then someone in another studio saves also, > their work is lost. It's causing total frustration for my users (100+ > of them) and I am not sure how best to go about it other than using I'm not sure I have an answer for this. I know that some (commercial) automation systems use a type of living log that updates across all systems using / editing the log as it is edited, but Rivendell does not do this. I wonder if it would be a feature we could implement at some future time. ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] Log Editing - Anyway to Lock?
On Friday 13 January 2012 10:47:15 am Aaron Horn wrote: > So the > log is being played out on RDAirPlay in Studio 1 but a user makes > changes to the log in Studio 2 on RDLogEdit - if the user in Studio 2 > saves all their work but then someone in another studio saves also, > their work is lost. That would be correct !! This is the common problem in trying to implement database replication schemes. In exactly the scenario you describe, the last save is the one that gets saved last, as would be expected, but that's not what you want. You've just opened a paradoxical can of worms. That, or you do lock the database, so that one and only one can be editing at any given time. Now we have another scenario. User two locks the database for edit, and for whatever reason crashes. The database is now perpetually locked. The first thing you'll need to define, is which save is saved, when, where, and why. -- Cowboy http://cowboy.cwf1.com Justice is incidental to law and order. -- J. Edgar Hoover ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] dail recording/re-broadcast our news
Yeah, I'm gonna work on this one. Thanks a lot for all your ideas, Stephan Fijneman > On Fri, 2012-01-13 at 12:19 +0800, Stan Fotinos wrote: >> Maybe setup recordings for 1 week only and then have those recordings >> uploaded using rdcatch to another location once done with them so >> they >> can be archived. > > This would probably be the cleanest solution... capture the audio using > RDCatch, and have a post-record "upload" to a local (on the Rivendell > system) filesystem folder. Use wildcards to export the file to a > timestamp-labeled filename (so you wouldn't overwrite the audio clip, > allowing long-term archiving if so desired). > > Then, when you want to play it back later, you can use an automated > RDImport process (either via a cron job or a dropbox watch folder) to > get it back into a certain single cart that gets replayed for the > delayed-broadcast newscast. (I.e. there would be a single [set of] > cart[s] that is|are scheduled repetitively in the log, and the RDImport > process would simply overwrite that audio with fresh audio coming from > the timestamped audio that was previously exported via RDCatch.) > > It's a bit of a hack, but I think it's doable. Hopefully this gives you > some ideas of how. > > -- > +--+--+ > | Sherrod Munday | | > | Senior VP, Engineering | (423) 396-8130 (W) | > | Sky Angel U.S., LLC | | > +--+--+ > > ___ > Rivendell-dev mailing list > Rivendell-dev@lists.rivendellaudio.org > http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev > ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] dail recording/re-broadcast our news
Hi all, I think it is best to stay a close to the Rivendell system as possible. I do not use Jack, not looking forward to use Audacity. To answer Partick's question ==> We do a live news show from 18:00H to 19:00H and want to re-broadcast the following morning from 04:00H till 05:00H I think one solution is a script that creates a new cart and then kicks-off the recording, (using macro RS and RR) and schedules the playback (macro EX) would work. So the core of the issue to this solution is: creating a new cart. Stan's idea also sounds even better: This can be set-up within Rivendell, without external scripts, on a weekly or even daily base. The archive does not have to be in Rivendell, we just need it for legal reasons. It is fine if it lands as sound-files in some directory. So, can I do an "upload" to the same machine? Can I just use a local path as the URL in the RDCatch-Upload? Thanks, Stephan Fijneman Love-FM , St. Lucia -- > I've tried that method before... it's not the most reliable even on a 3GB > RAM system with a core2 Duo processor. If Audacity wants to mess up (which > sometimes it does) by getting set at a sample rate other than that of > JACK, > the recordings don't sound the best. > In addition, some set up is required. If you REALLY want to record using > Audacity, and you use Rivendell with JACK... but the audio from Rivendell > is already being routed elsewhere, then you will need to install JACK > Mixer > and reconfigure the audio network. All input and output applications and > devices must have their separate channels on JACK Mixer. Then Rivendell > must from then on input directly into JACK Mixer, which from JACK Mixer > you > can then control using clickable buttons which devices the audio should be > output to... and with JACK Mixer, you can have the audio output to more > than one device. > I use JACK Mixer myself and it's a pretty good program. Only frustrating > thing is if you want the audio to automatically route itself... you cannot > have stereo channels for JACK Mixer names them with a SPACE in them > (GR!)... thereby making it not able to be used in something like > /etc/asound.conf. The workaround is to create not a stereo channel but two > mono channels for each input and output device... and giving it a name > without anything other than letters numbers and underscores. Problem is > though double the controls to work with! In addition, you have to set it > up > correctly so that even when using two mono channels for each source and > destination, it still comes out/in as stereo in those sources or > destinations. It's kind of complicated. > > Anyway, back to the point. What he wants from my understanding is a way to >>automatically< create a new cart and record a new broadcast each day > without him having to do it himself. To do that specifically, is possible, > however it would require an external script such as PHP triggered by a > macro cart or by a cron job. The PHP script has to be designed to, each > day, automatically fill in data for a new cart in the Rivendell MySQL > database and also to change the destination cart in the recording entry in > RDCatch. > Creating a script like this IS possible... I have an idea of how it can be > done. But I'm not going to begin until I get the okay from the author of > this topic. > The estimated completion time for the script will be up to one week if I > include testing routines to verify it works correctly. > > >> What about using jack to capture to something like audacity, and then >> save it to a file. If you want it in Rivendell import it into a new >> cart which can then be scheduled for whenever... >> >> ...Kevin >> -- >> Kevin Miller - http://www.alaska.net/~atftb >> Juneau, Alaska >> In a recent survey, 7 out of 10 hard drives preferred Linux >> Registered Linux User No: 307357, http://linuxcounter.net >> ___ >> Rivendell-dev mailing list >> Rivendell-dev@lists.rivendellaudio.org >> http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev >> > ___ > Rivendell-dev mailing list > Rivendell-dev@lists.rivendellaudio.org > http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev > ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] dail recording/re-broadcast our news
On Jan 12, 2012, at 18:14 44, sf...@xs4all.nl wrote: > RDCatch lets me record, but not to a new cart for every day. I don't want > to schedule 365 recordings! The macro's don't let me create a new daily > cart. Set up a dropbox configured to import to the desired group, then add a daily upload event in RDCatch to the dropbox. A little baroque, but it gets the job done. 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://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] Log Editing - Anyway to Lock?
Actually I thin the first suggestion I made will not work now as I reread what you want to domaybe it will, I dunno. I still think the second suggestion would be better for you. Yes I think I would go that route. Create macros to load each students(or team of students) show into the aux log, and start the playback of the aux log, and stop down the main log. Then at the end of their show it needs to have a macro to start the main log back up. I'm sure there are many other ways to achieve the same end, this is just a simplified suggestion. Timing and commercials or spots would be the tricky part, but I'm sure there is a solution. Nathaniel C. Steele Assistant Chief Engineer/Technical Director WTRM-FM / TheCrossFM On 1/13/2012 10:57 AM, Nathan Steele wrote: > In RDAdmin under service there is a check box to enable "autorefresh" > this will update the log on RDAirplay I think whenever it is edited. > maybe that would do what you want. > > But, why not make the Airplay log with macros that load and play the > students show logs, and they create their own logs for their shows that > way no one is accessing a "shared log"? You would not even need to use > the autorefresh (which can be dangerous). just a thought. > > Nathaniel C. Steele > Assistant Chief Engineer/Technical Director > WTRM-FM / TheCrossFM > > > On 1/13/2012 10:47 AM, Aaron Horn wrote: >> Hi there... >> >> I have a bit of an issue with Rivendell... We use 1.7.2 on Ubuntu >> Studio 10.something with ASI soundcards - so far so good. I have an >> upgrade to 2x planned around Easter. >> >> We are a teaching university have have two on-air studios plus three >> satellite studios. They all share a ZFS audio share and MySQL >> database on a server. >> >> Unlike traditional radio settings, we use a highly corroborative >> approach to put together our on-air content. That is, many people put >> together the logs etc. >> >> We generate clocks but each show team comes in before their show to >> edit their section of the day log... The typical way to do this is for >> them to build their show in terms of playlist and promos in a 'scratch >> log' before copy-pasting into the main log. >> >> Our issue is that we are loosing a boat load of content, it seems that >> this occurs when the log is open in more than one location... So the >> log is being played out on RDAirPlay in Studio 1 but a user makes >> changes to the log in Studio 2 on RDLogEdit - if the user in Studio 2 >> saves all their work but then someone in another studio saves also, >> their work is lost. It's causing total frustration for my users (100+ >> of them) and I am not sure how best to go about it other than using >> the day logs only for automation and getting people to use their own >> logs for live programming (an approach I want to avoid as it becomes >> messy and difficult to manage). >> >> To me the solution is to remove the 'save' button and have any changes >> reflected live on every computer with that log open in an immediate >> sense. Either that or lock logs (e.g. 'this log is being edited at >> location xyz, please close there before editing the log'). >> >> Thoughts/help? >> > ___ > Rivendell-dev mailing list > Rivendell-dev@lists.rivendellaudio.org > http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev > > > ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] Log Editing - Anyway to Lock?
In RDAdmin under service there is a check box to enable "autorefresh" this will update the log on RDAirplay I think whenever it is edited. maybe that would do what you want. But, why not make the Airplay log with macros that load and play the students show logs, and they create their own logs for their shows that way no one is accessing a "shared log"? You would not even need to use the autorefresh (which can be dangerous). just a thought. Nathaniel C. Steele Assistant Chief Engineer/Technical Director WTRM-FM / TheCrossFM On 1/13/2012 10:47 AM, Aaron Horn wrote: > Hi there... > > I have a bit of an issue with Rivendell... We use 1.7.2 on Ubuntu > Studio 10.something with ASI soundcards - so far so good. I have an > upgrade to 2x planned around Easter. > > We are a teaching university have have two on-air studios plus three > satellite studios. They all share a ZFS audio share and MySQL > database on a server. > > Unlike traditional radio settings, we use a highly corroborative > approach to put together our on-air content. That is, many people put > together the logs etc. > > We generate clocks but each show team comes in before their show to > edit their section of the day log... The typical way to do this is for > them to build their show in terms of playlist and promos in a 'scratch > log' before copy-pasting into the main log. > > Our issue is that we are loosing a boat load of content, it seems that > this occurs when the log is open in more than one location... So the > log is being played out on RDAirPlay in Studio 1 but a user makes > changes to the log in Studio 2 on RDLogEdit - if the user in Studio 2 > saves all their work but then someone in another studio saves also, > their work is lost. It's causing total frustration for my users (100+ > of them) and I am not sure how best to go about it other than using > the day logs only for automation and getting people to use their own > logs for live programming (an approach I want to avoid as it becomes > messy and difficult to manage). > > To me the solution is to remove the 'save' button and have any changes > reflected live on every computer with that log open in an immediate > sense. Either that or lock logs (e.g. 'this log is being edited at > location xyz, please close there before editing the log'). > > Thoughts/help? > ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
[RDD] Log Editing - Anyway to Lock?
Hi there... I have a bit of an issue with Rivendell... We use 1.7.2 on Ubuntu Studio 10.something with ASI soundcards - so far so good. I have an upgrade to 2x planned around Easter. We are a teaching university have have two on-air studios plus three satellite studios. They all share a ZFS audio share and MySQL database on a server. Unlike traditional radio settings, we use a highly corroborative approach to put together our on-air content. That is, many people put together the logs etc. We generate clocks but each show team comes in before their show to edit their section of the day log... The typical way to do this is for them to build their show in terms of playlist and promos in a 'scratch log' before copy-pasting into the main log. Our issue is that we are loosing a boat load of content, it seems that this occurs when the log is open in more than one location... So the log is being played out on RDAirPlay in Studio 1 but a user makes changes to the log in Studio 2 on RDLogEdit - if the user in Studio 2 saves all their work but then someone in another studio saves also, their work is lost. It's causing total frustration for my users (100+ of them) and I am not sure how best to go about it other than using the day logs only for automation and getting people to use their own logs for live programming (an approach I want to avoid as it becomes messy and difficult to manage). To me the solution is to remove the 'save' button and have any changes reflected live on every computer with that log open in an immediate sense. Either that or lock logs (e.g. 'this log is being edited at location xyz, please close there before editing the log'). Thoughts/help? -- Regards, Aaron Horn, aaronh...@gmail.com. ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] dail recording/re-broadcast our news
On Fri, 2012-01-13 at 12:19 +0800, Stan Fotinos wrote: > Maybe setup recordings for 1 week only and then have those recordings > uploaded using rdcatch to another location once done with them so > they > can be archived. This would probably be the cleanest solution... capture the audio using RDCatch, and have a post-record "upload" to a local (on the Rivendell system) filesystem folder. Use wildcards to export the file to a timestamp-labeled filename (so you wouldn't overwrite the audio clip, allowing long-term archiving if so desired). Then, when you want to play it back later, you can use an automated RDImport process (either via a cron job or a dropbox watch folder) to get it back into a certain single cart that gets replayed for the delayed-broadcast newscast. (I.e. there would be a single [set of] cart[s] that is|are scheduled repetitively in the log, and the RDImport process would simply overwrite that audio with fresh audio coming from the timestamped audio that was previously exported via RDCatch.) It's a bit of a hack, but I think it's doable. Hopefully this gives you some ideas of how. -- +--+--+ | Sherrod Munday | | | Senior VP, Engineering | (423) 396-8130 (W) | | Sky Angel U.S., LLC | | +--+--+ ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] dail recording/re-broadcast our news
I've tried quoting it... and that did not work. I believe I've tried escaping it too but I'm not sure if I did. On Fri, Jan 13, 2012 at 8:57 AM, Cowboy wrote: > On Friday 13 January 2012 08:32:21 am Patrick Schmalstig / WRRJ Radio > wrote: > > JACK Mixer names them with a SPACE in them > > (GR!)... thereby making it not able to be used in something like > > /etc/asound.conf. > > Admitting I have not tried this, have you tried to quote or escape > the stereo channel name ? As in... > "Stereo Channel" > or > Stereo\ Channel > > -- > Cowboy > > http://cowboy.cwf1.com > > Justice is incidental to law and order. >-- J. Edgar Hoover > > ___ > Rivendell-dev mailing list > Rivendell-dev@lists.rivendellaudio.org > http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev > ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] dail recording/re-broadcast our news
On Friday 13 January 2012 08:32:21 am Patrick Schmalstig / WRRJ Radio wrote: > JACK Mixer names them with a SPACE in them > (GR!)... thereby making it not able to be used in something like > /etc/asound.conf. Admitting I have not tried this, have you tried to quote or escape the stereo channel name ? As in... "Stereo Channel" or Stereo\ Channel -- Cowboy http://cowboy.cwf1.com Justice is incidental to law and order. -- J. Edgar Hoover ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] dail recording/re-broadcast our news
I've tried that method before... it's not the most reliable even on a 3GB RAM system with a core2 Duo processor. If Audacity wants to mess up (which sometimes it does) by getting set at a sample rate other than that of JACK, the recordings don't sound the best. In addition, some set up is required. If you REALLY want to record using Audacity, and you use Rivendell with JACK... but the audio from Rivendell is already being routed elsewhere, then you will need to install JACK Mixer and reconfigure the audio network. All input and output applications and devices must have their separate channels on JACK Mixer. Then Rivendell must from then on input directly into JACK Mixer, which from JACK Mixer you can then control using clickable buttons which devices the audio should be output to... and with JACK Mixer, you can have the audio output to more than one device. I use JACK Mixer myself and it's a pretty good program. Only frustrating thing is if you want the audio to automatically route itself... you cannot have stereo channels for JACK Mixer names them with a SPACE in them (GR!)... thereby making it not able to be used in something like /etc/asound.conf. The workaround is to create not a stereo channel but two mono channels for each input and output device... and giving it a name without anything other than letters numbers and underscores. Problem is though double the controls to work with! In addition, you have to set it up correctly so that even when using two mono channels for each source and destination, it still comes out/in as stereo in those sources or destinations. It's kind of complicated. Anyway, back to the point. What he wants from my understanding is a way to >automatically< create a new cart and record a new broadcast each day without him having to do it himself. To do that specifically, is possible, however it would require an external script such as PHP triggered by a macro cart or by a cron job. The PHP script has to be designed to, each day, automatically fill in data for a new cart in the Rivendell MySQL database and also to change the destination cart in the recording entry in RDCatch. Creating a script like this IS possible... I have an idea of how it can be done. But I'm not going to begin until I get the okay from the author of this topic. The estimated completion time for the script will be up to one week if I include testing routines to verify it works correctly. > What about using jack to capture to something like audacity, and then > save it to a file. If you want it in Rivendell import it into a new > cart which can then be scheduled for whenever... > > ...Kevin > -- > Kevin Miller - http://www.alaska.net/~atftb > Juneau, Alaska > In a recent survey, 7 out of 10 hard drives preferred Linux > Registered Linux User No: 307357, http://linuxcounter.net > ___ > Rivendell-dev mailing list > Rivendell-dev@lists.rivendellaudio.org > http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev > ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] File transfers between Rivendell systems
I have some scripts that do this which update the essential tables CARTS CUTS SCHEDULE_CODES and migrates the audio. We restrict the updates to news and essential stuff to conserve bandwaidth. Robert On Fri, Jan 13, 2012 at 12:17 PM, Rob Landry <41001...@interpring.com>wrote: > > One of my clients runs a Rivendell system at each of his stations' > transmitter sites. Currently he uploads audio files to drop boxes at the > sites where they get rdimported; but now he wants to use rdlibrary to > produce cuts in his studio, so I need to figure out how to move the cuts > and their associated metadata from one database to another. > > My current thought is to create a "Rivendell_sync" MySQL database on the > production file. It will have a copy of the CUTS table, and a script will > wake up periodically and scan this table and the one in the Rivendell > database for differences. When it finds one, it will know that a cut has > been added or changed, and it will copy the corresponding audio file to > the transmitter site(s) associated with its Rivendell group. Then it will > send a text file containing the dumped contents of the CART and CUTS > record for the cut in question. > > At the transmitter site, another script will check the incoming text file > against the CUTS and CART tables in its own Rivendell database. If they > are different, it will plant the incoming audio file in /var/snd and > update the two tables with the data from the text file. > > My questions of y'all is: does this make sense? What are the potential > pitfalls? Is there a better way to do this? > > Thanks, > > > Rob > > ___ > Rivendell-dev mailing list > Rivendell-dev@lists.rivendellaudio.org > http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev > ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
