search

AaronJowitt / Rivendell

RIvendell Automation Issue/Req Tracking
0 stars 0 forks source link

RDAdmin Log re-merge switch to retain metadata #2

Open AaronJowitt opened 8 years ago

AaronJowitt commented 8 years ago

RDAdmin toggle - Music Merge/Re-Merge retain VT marker metadata. Optionally allows external music log remerging (incl current day) without effecting pre-existing VT audio or metadata (specifically - markers that determine pre-roll/post roll). Note: Unclear how this can work if RD (and not MM externally) assigns the cart number, unless RD can retain the cart number on a remerge??

A "Retain Metadata" switch for external music log and/or external traffic log re merging you suggested sounds fine. You, Brad and I specifically discussed that it would retain any existing VT metadata (segue, overlap positions, levels etc) for VT's that had an externally generated cart number.

I'm assuming by extension that it would also retain custom metadata for all other non-VT events too (eg - pure 'song to song' transitions changed in the VT module's segue editor), but we didn't specifically discuss that. So to clarify; its desirable that it does that - retain any/all log based custom meta data/segues for all events. This ensures any custom song/ID/song transitions that have been performed in the VT segue editor module are not 'lost' on log remerging.

All event transitions should hold on remerge (for event sequences that remain common to the current log, and the newly merged log) even if some events have been added/deleted from any part of the log (i.e the new log is longer/shorter than the old one).

ElvishArtisan commented 8 years ago

Ok, I need some sample data sets here for testing. Could you sent me a couple music log import files: one as a baseline, and another that would be representative of the types of changes that we could expect to see. The challenge we're running into here is with correlating the metadata from the old events to the new ones; I've some ideas on how this could work, but I'd like to try them out with some Real World data before going too far down this path.

AaronJowitt commented 8 years ago

Sure. Fred, I'll forward you a few .mus logs via email. I'll lay out what may be a typical day with the external MUSIC logs changes (re-merges) across the day of broadcast. Note I have excluded external TRAFFIC only remerges that may occur. ; 151209.MUS - #1 (pre Alice 6pm-11pm). It has all VT's recorded/completed by talent up till 1800 (excluding the 1600 hour) on the log. From 1800-2300, a template is in place for the syndicated Alice show, but most songs have not yet been placed in it, only the default show filler songs are in place. 2300-0000 is complete.

151209.MUS - #2 (with Alice 6pm-11pm) @~1130 (clock time) MUSIC log is remerged on day of broadcast. The changes are to add all the songs in the Alice show 1800-2300. Note this also involves re-ordering and.or deleting optional padding/filler songs in the show. There is a time marker at beginning of the show after ~1800, and another at the end at ~2300. Current automation will auto reload/refresh the log at the ~1200 time marker.

151209.MUS - #3 (song changes 1306-1314) @~1240 (clock time) MUSIC log is remerged on day of broadcast. The changes are to delete the Meat Loaf song at 13:06, put a replacement shorter song in its place, and add a padding short song after the next ID. There is a time marker at ~1300 and the next at ~1400. Current automation will auto reload/refresh the log at the ~1300 time marker.

151209.MUS -#4 (replace 1600 hour) @1440 (clock time) MUSIC and TRAFFIC log is remerged on day of broadcast. The changes are to replace the entire 1600 hour with a music special. There is a time marker at ~1600 and the next at ~1700. Current automation will auto reload/refresh the log at the ~1500 time marker.

Current automation on log reloading/merging does not;

All MUSIC log changes we make reflect future hours in the day. We do not modify logs for material already aired.

Note VT's are scheduled (including cart number) from the Music scheduler, and appear on those logs 0500-1800 only. They are identified by cart numbers 15,000-16,000, and title field contains 'time call' info for the announcer; eg: 14:57:23 VT RblNet

Hope this helps.

AaronJowitt commented 8 years ago

The previous post used log examples where the VT's (externally scheduled incl cart number) had all already been completed in the RD VT module (voiced by talent, with custom segues set etc) before the day of airing. That will occur sometimes (particularly holidays, Sundays etc).

More commonly, shifts will be VT'd by announcers on day on broadcast - not necessarily in the order of the shifts/airing. They do not add/remove log items (incl VT's) from the log - they just record their VT's that are scheduled on the log.

It is possible a log while being VT'd by talent, is remerged (as detailed in previous post). Ideally would need same flexibility with RD, as the staff remerging logs are not always aware of whether a log is being VT'd.

It is also possible a log is being VT'd in two different studios i.e. A lunch time announcer VTing her shift in Studio 1, while drive time announcer VT's his shift in Studio 2. Ideal (but not essential, if announcers liaise with each other) that RD has same flexibility.

Current automation retains all VT/custom segue metadata in above scenarios.

AaronJowitt commented 8 years ago

email 28 Jan 2016;

Hello Fred,

Good to hear your safe and can get out and about now.

Thanks for your example.

If I'm thinking correctly, if you have a temp reference snapshot of the 'old' log (needed only till remerge is complete), can you track all adjacencies/parings within each hour. You don't need to look at a single cart (i.e 23456 Station Promo) in isolation, and therefore the fact that same cart may appear multiple times on a days log should be irrelevant.

In your 2nd example no custom transitions should be retained. They should all default (like the current behavior) to the cart/cut db values. The reason is none of events reflect the original log pairing. i.e. Song1 no longer sequences into Station Promo. Station Promo no longer sequences into Songs 2. etc. Your merge logic should see that all the pairings are 'new', so should be default values.

To use your 2 examples (1 & 2), and add one more re-merge example in the middle (1B);

EXAMPLE 1

12345 Song 1 23456 Station Promo 32474 Song 2 79318 Song 3 23456 Station Promo 75962 Song 4

If this log is remerged, all the above pairings stay in tact, so any custom transitions (if RDAdmin switch is set accordingly) will be retained.

EXAMPLE 1B

Then we remerge again with only one change, replacing song 3 with Song 8;

12345 Song 1 23456 Station Promo 32474 Song 2 79350 Song 8 23456 Station Promo 75962 Song 4

All pairings staying in tact (except those heading in or out of Song 8), so any custom transitions are retained - except those either side of Song 8.

i.e. Sequentially down the log, the merge logic comparing the new log to the old log determines;

The end of '12345 Song 1' retains any custom transition into '23456 Station Promo.  (They were previously paired prior to remerge)
The end of '23456 Station Promo' retains any custom transition into '32474 Song 2'.  (They were previously paired prior to remerge)
The end of '32474 Song 2' into '79350 Song 8' defaults to cart/cut DB transitions.  (This is a 'new' pairing)
The end of '79350 Song 8'into '23456 Station Promo' defaults to cart/cut DB transitions.  (This is a 'new' pairing)
The end of '23456 Station Promo' retains any custom transition into '32474 Song 2'.  (They were previously paired prior to remerge)

EXAMPLE 2

Log is remerged again, retaining none of the pre-existing pairings;

24389 Song 5 32474 Song 2 23456 Station Promo 08435 Song 6 23456 Station Promo 34548 Song 7

These are all new pairings, so no custom transitions retained. All default to cart/cut db values.

Would that work?

Cheers

Aaron