ProppFrexx ONAIR User-Forum

Right now overlays support the "AsPlaylistInsert" option to resolve overlays to the playlist as embedded containers.

This works fine for overlays that are scheduled during the runtime of a program (eg: a program entry each hour and the overlays are scheduled at xx:15, xx:30, xx:45).

But there is an edge case: this does not work at the moment for overlays that are scheduled at the starttime of a program. The overlay is inserted into the playlist of the old hour and will be skipped once the playlist of the new hour takes over. This is the case for all start types (non-TimeUpdateSync and TimeUpdateSync)

I can think of 2 solutions to fix these issues:

• Add a new option to respects the scheduled time and inserts the overlay as embedded container accordingly
  Rather than inserting the overlay in the active playlist (or with TimeUpdateSync: above the TimeUpdateSync playlist entry), insert it on the actual scheduled time.
  
  For TimeUpdateSync (which we are currently using), this behaviour is already implemented when using "Upcoming overlays > Resolve Overlay To Playlist". When clicking this button the overlay is inserted after the TimeUpdateSync, which is what we need.

• Add an option to resolve overlay to the playlist immediately when a program playlist becomes visible
  This is like "ResolveEmbeddedContainersWhenScheduled", but as dynamic option that can be checked for an overlay, rather than the program. When a program is scheduled/started the corresponding overlay is already inserted as embedded container into the playlist.
  
  This is a solution for this edge case, as the overlay is suppose to be scheduled at the start of the program. However, it wouldn't really work for overlays scheduled during the program, as there is no guarantee the playlist has been pre-scheduled til the time the overlay must be played back. This is not a problem in our use-case but is something to consider here. Perhaps checked overlays can be inserted at the end of the already loaded playlist entries.

Perhaps there are other options. I am just thinking aloud here. What do you think?

This should actually already happen and was even designed to work like that.
I.e. the AsPlaylistInsert option (when at runtime) actually should look, if there is already a newer program/playlist open, and in such case decide to not inject the overlay to the currently active, but inject the overlay as a container to that 'newer' playlist (where the program start time is greater or equal to the overlay start time).

However, in one of the latest versions an error was added, as accidentally a comparison was flipped from '>=' to only '>' - which lead to this error. If you for example define the previous program's end time to x:59:59 it would properly work.
So this error will be corrected in the next version asap!

Makes sense!

However, I tried setting a program to 00:59:59 (with show advance time of 120 seconds and "Soft TimeUpdateSync" starttime) and an overlay at 01:00:00 (with show advance time of 60 seconds with "AsPlaylistInsert") and the overlay is still placed before the TimeUpdateSync marker.

The End time of the program is actually the relevant value, which had to be set to x:59:59…
But as said, it will be fixed in the next version asap.

A new beta version v4.3.6.2-beta is available which should fix the issue.
Please use the "Check for Beta Version..." feature to update...

Thank you! I will test this later today and let you know if we have further issues.

It seems to not have been fixed in our configuration. The overlay is still inserted in the old playlist, as it was before.

Our programs:
* An hourly program which starts at xx:00
* Start Type: Soft TimeUpdateSync
* Show advance time: 120 seconds

Our overlays:
* An overlay which starts at xx:00
* Start Type: Manual
* Show advance time: 60 seconds
* Options: AsPlaylistInsert, ApplySuppressFilters

Maybe it has something to do with the TimeUpdateSync start type?

Same here and I have the same test setup. Except I had different program and overlay start times…
But here it works as designed and the overlay was added at the top of the new program.

Hmm... that is weird. I did some more testing (with dynamic playlist or a playlist file) and with all of these variants the overlay was still inserted incorrectly in the old program.

Yes, this is another edge case, as there is already a TUS existing (from the program change) in the playlist, which needs to be validated... I will take a look!