"Resolve Overlays to Playlist" does not work well when TimeUpdateSync FTEs are used

[Bo98A]

If I have a TimeUpdateSync FTE scheduled when, or just before, a overlay is scheduled for, the TimeUpdateSync FTE appears after the overlay when ticking the "Resolve Overlays to Playlist" option in the Playlist Template Wizard. This can result in the overlay not being played as the TimeUpdateSync would skip any previous entries at its scheduled time. I would've expected overlays to be scheduled after a TimeUpdateSync rather than before.

This gets notably worse if you have multiple overlays in an hour as overlays are added after the initial schedule, so a HH:10 overlay could be scheduled before a HH:00 TimeUpdateSync if you have >= 10 minutes of overlays.

[radio42]

I understand your points, but this is how it currently works.
I might take a look to improve things in a future version (if possible).

[radio42]

Yes, this might be the case, but is unfortunately by design.
I am afraid that this is again a matter of expected vs. current prioritization respectively a chicken and egg issue.

You are right, that at first the script entries (including FTEs) are resolved to generate the initial playlist.
After that the overlays are added to the playlist at it's 'destinations'.

This is by design in order to emulate the 'normal' behavior (as it would happen, if Overlays would be played out normally by the Overlay Player on top of the playlist). In this scenario you would have the same behavior. If an overlay does suppress/pause a current playlist, all its following items are also 'delayed'.
In addition, some other users might what to have the exact behavior, which causes trouble in your case (meaning they might want to 'skip late overlays').

Thus, mixing FTEs (especially TUS-FTEs) and Overlays can unfortunately (as you correctly recognized) lead to some artifacts or unexpected side effects.
One solution is to not mix them. E.g. if you have a Top-Of-The Hour FTE, you might also schedule this as an extra overlay entry instead. Note, that you can 'Combine Parallel' overlays (see general settings, section 'Scheduler/Scripts'). Also Note, that you can schedule multiple overlays exactly at the same effective StartTime (using the StartTime and Show In Advance Time). In such case the Overlay's 'Prio.' defines the order in which appear.
Another solution is to manually adjust the playlist and remove the unwanted artifacts and move the TUS-FTEs above your Overlays.

I am afraid, that currently I have no better solution and I am not even sure, that a better solution is even existing.

[Bo98A]

This is by design in order to emulate the 'normal' behavior (as it would happen, if Overlays would be played out normally by the Overlay Player on top of the playlist). In this scenario you would have the same behavior. If an overlay does suppress/pause a current playlist, all its following items are also 'delayed'.

Wouldn't the "normal" behaviour be that an overlay is played after a TUS-FTE? If I had, for example, HH:00:00 TUS-FTE and a HH:00:01 overlay, the overlay player will play after the TUS-FTE while what is happening with the playlist would result in the overlay either playing before or most likely not at all.

If it's by design then fair enough, but I'm confused on what exactly it's emulating.

One solution is to not mix them. E.g. if you have a Top-Of-The Hour FTE, you might also schedule this as an extra overlay entry instead. Note, that you can 'Combine Parallel' overlays (see general settings, section 'Scheduler/Scripts'). Also Note, that you can schedule multiple overlays exactly at the same effective StartTime (using the StartTime and Show In Advance Time). In such case the Overlay's 'Prio.' defines the order in which appear.

It would lose the TUS feature though unfortunately, as well as the ability to use script rules after what would've been the FTE.

Another solution is to manually adjust the playlist and remove the unwanted artifacts and move the TUS-FTEs above your Overlays.

Annoying when there's quite a few overlays to deal with on a regular basis but it seems to be the only solution.

I am afraid, that currently I have no better solution and I am not even sure, that a better solution is even existing.

Fair enough, thanks for letting me know.

[radio42]

Wouldn't the "normal" behavior be that an overlay is played after a TUS-FTE?

'Normally' an overlay is started independently in it's own overlay player control some seconds ahead of its effective start time.
Assuming it is a Soft start type overlay, it would then evaluate (when due) the currently playing track, which could be any track before a subsequent TUS playlist entry! Thus the playlist at this point is already deactivated (AutoPlay set to FALSE). Thus the Overlay would be played before the TUS.
But yes (I agree), the resulting behavior would be different here, as the Overlay is played 'before' the TUS and a TUS would never remove any overlay.
So may be I should simply adopt that same behavior for a TUS within the playlist as well: meaning do not remove a preceeding resolved overlay entry? I am not sure yet and I have to double check various dependencies first

Another option might also be to not only resolve an overlay to a playlist, but to also resolve it as a TUS.
(meaning a TUS entry is added ahead of the resolved overlay entry in addition)
I'll look into this option as well.

[radio42]

Ok
Until then there might already be a new version as I figured one small glitch with multiple parallel overlays which will fix til then.

Update: I have now updated the .55-beta with an optimized version.
There might still be a few and rare 'unlogic' results, in case you mix real FTEs with fixed Overlays, but this is so far the best I can do, as two concurrent FTEs happening at the same time are irrational and can not really be resolved perfectly.
For TUS (TimeUpdateSync) and resolved overlays it is however working good now I hope.

[radio42]

I was looking into it a bit more in detail this evening (as I am leaving tomorrow for holiday, I wanted to get you at least something out before).
So I tried to optimize the 'Resolve Overlay to Playlist' logic a bit more, and yes, it seems 'trouble free' to add Overlays AFTER a possible TUS in case they have the same effective StartTime!

So here is a v4.0.1.55-beta to try: Please "Check for Beta-Versions..."

[Bo98A]

Thank you! I won't be able to test it out until Monday unfortunately but I'll get back to you.

Enjoy your holiday!

[Bo98A]

All is good now for overlays after TUS-FTEs but the backtiming calculation for overlays seems to not be working anymore. Overlays scheduled do not seem to look at the previous overlays' duration anymore.

e.g. a 5 minute overlay at HH:00:00 will shift the HH:10:00 overlay to be more around HH:15:00. Overlays scheduled immediately after TUS-FTEs are fine.

Additionally, the "show in advance"/"max. early" time seems to be ignored but that was already the case. Not sure if that was intentional or not so I'm mentioning it just in case.

[radio42]

Yes I guess this needs to be corrected (the shifting of overlays due to the previous ones).
But the MaxEarly and ShowInAdvance are intentionally ignored as already explained.

I am not when to fix this as I am currently in holiday.