ElvishArtisan / rivendell

A full-featured radio automation system targeted for use in professional broadcast and media environments
205 stars 64 forks source link

Feature Request - Ability to select a specific cut for a log #895

Closed ltyndale closed 1 year ago

ltyndale commented 1 year ago

I'd love the ability to be able to select a specific cut from a cart when adding or scheduling a cart in a log. Perhaps when you select the "Add Cart" and the drop down arrow could be available (like it is in rdlibrary) and allow you to select a specific cut.

Reasons for this - for long-form shows that are broken up into different parts (part A, part B, part C, etc) - from a library administration standpoint it is easiest to have all these parts in a single cart, and each cut being a segment of the programme. Currently if you schedule that cart multiple times in the same log and set the "schedule cuts by" tag as "specified order" it will play the next cut in the cart each time. This works but is far from perfect. For example if you have a 3 part programme with Part 1, Part 2, and Part 3 as separate cuts and schedule the same cart 3 times in the log (so it'll play part 1, part 2, and part 3 with whatever spots / id's, etc that are scheduled between each log entry) it won't grab the time length of each cut, but rather display the average time length in rdairplay and rdlogedit. Also if for some reason a segment gets missed (incorrect scheduling, etc) the next time that cart is scheduled then it might start playing the wrong cut.

By further being able to specify which cut gets played in the log this would likely fix both the time display issue and ensure that the cut you want played actually gets played.

The only other way to handle a milti-part programme is to create separate carts for each segment of the programme. This works and eliminates some of the issues with putting all the segments into cuts, but it can present some library administration issues.

ElvishArtisan commented 1 year ago

This basic idea was kicked around years ago. We came to the conclusion that it didn't make sense, largely because it would mean having to reimplement much of the existing scheduling apparatus (transition types, etc) at the cut level, plus we really don't want to wire a bunch of special policy into the cut scheduling mechanism (there's already too much there IMO). If the precise placement and ordering of material is crucial, then you you really should be placing the elements in individual carts and scheduling them explicitly.