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 do....maybe 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 >> [email protected] >> http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev >> >> >> > _______________________________________________ > Rivendell-dev mailing list > [email protected] > http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev _______________________________________________ Rivendell-dev mailing list [email protected] http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
