observer

observer copied to clipboard

Current behaviour of OB Server is for a show to always start precisely on time, thereby causing any currently in-progress media to be abruptly interrupted.

Considering many use cases where content is not always (or maybe ever) pre-produced to a stringent running time, particularly those using Dynamic Playlists, there is a significant need for the ability to allow shows some leeway around start/end times.

My idea to solve this would be adding the following settings:

• Overlap Behaviour [Start Early/Start Late/Force Punctual]
• Delayed Start Time Allowance [How long is a show allowed to go over time]
• Early Start Time Allowance [How early is a show allowed to start]

Notes:

• Settings should have both global (default) and manual (per-show) options
• Use case for a show starting early would be Dynamic Playlists where it may be better to start a show 30-60 seconds early than queue up a new song and cause the next show to start several minutes late.
• Start Early/Start Late options are not strict, but a way to set your preference where an item would both start within the early allowance window, and finish within the delayed start window. This capability might depend the other piece of work for 'Intelligent Dynamic Scheduling' in order for OB Server to be sufficiently future-aware.

This issue is one of the biggest complaints I hear about CJUC FM from the community. The hard cut at the top of the hour when a show changes is very jarring for listeners.

Most radio automation systems handle this by being able to set each timed entry in a log as "Start Immediately", "Make Next", or "Wait as much as xxx" where xxx can be set to a number of minutes/seconds.

For start early, if a log is underfilled then some systems can grab content from a "fill" category to fill out the remaining time, others will just allow the log to continue to run underfilled. Either way there is usually a timer indicator on the screen to indicate if the log is underfilled, overfilled, or right on time (rare that happens). Underfilling (or overfilling) a log is more of a programming / scheduling issue as opposed to an automation system issue.

If a logged item gets tagged as "Make Next", then once the time of the timed log entry is hit, it'll dump anything left between what is currently playing and the timed item, allowing the currently playing item to finish playing and then it'll go into the timed log entry.

If an item is tagged as "Start Immediately", once the time for the log entry is reached it'll either fade out the currently playing item and go into the particular log entry, or it will hard-stop the currently playing item and start the next. Fade out or hard stop is usually an option that can also be set.

And finally if the "Wait up to xxx" is selected it works just like the "start immediately" only it'll delay the start for up to whatever it is set for in the log.

Of course these rules usually only take effect in the event that something is put in the log with a hard-time setting.

Some of this was already done in Develop that ties in with Fading in\out. We have these fields in DB and workflow when to fade in\out (do not do this on spoken word) and to figure this all out dynamically (without having to set fields) This was done first because it affects timeline for playback so the player can get instructions when to play at top of hour. Version 1 would play until end of media, then we had volunteers, schedule one of their long 20 minute media to play at end of hour, cutting into next persons show. We then made it strict on top of hour scheduler. Agreed this is a much needed feature, I hate when my favorite part of song gets cut at top of hour.