"Resolve Overlays to Playlist" does not work well when TimeUpdateSync FTEs are used
Re: "Resolve Overlays to Playlist" does not work well when TimeUpdateSync FTEs are used
Well, a new v4.0.1.56-beta is available, in which the Overlay's are hopefully "better" resolved.
Let me explain what the issue was. So far the overlays have been resolved to the playlist using their 'Approximate Duration', as given on the overlay entry definition.
However, when they are 'displayed' as a dynamic embedded container in a playlist, they where displayed using the current effective playtime (meaning the currently assigned campaigns are evaluated).
This difference led to the different resp. incorrect positions you discovered.
In the new version I am now always using current effective playtime when the overlays are resolved to determine the playlist position.
Note, that if the effective playtime of a slot/overlay changes after you created the playlist file (e.g. you assign more adverts to a slot after the playlist was created), the positions of subsequent overlays might have been changed, if you would re-create the 'same' playlist.
But this is a 'Back to the Future' issue, which cannot really be solved!
As such, I can only calculate the overlay positions as good as possible at the moment in time when you create the playlist; later changes of the adverts are possible, but would not have any impact on the overlay positions afterwards.
So I hope you'll find this latest version more accurate.
Let me explain what the issue was. So far the overlays have been resolved to the playlist using their 'Approximate Duration', as given on the overlay entry definition.
However, when they are 'displayed' as a dynamic embedded container in a playlist, they where displayed using the current effective playtime (meaning the currently assigned campaigns are evaluated).
This difference led to the different resp. incorrect positions you discovered.
In the new version I am now always using current effective playtime when the overlays are resolved to determine the playlist position.
Note, that if the effective playtime of a slot/overlay changes after you created the playlist file (e.g. you assign more adverts to a slot after the playlist was created), the positions of subsequent overlays might have been changed, if you would re-create the 'same' playlist.
But this is a 'Back to the Future' issue, which cannot really be solved!
As such, I can only calculate the overlay positions as good as possible at the moment in time when you create the playlist; later changes of the adverts are possible, but would not have any impact on the overlay positions afterwards.
So I hope you'll find this latest version more accurate.
Bernd - radio42
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
Re: "Resolve Overlays to Playlist" does not work well when TimeUpdateSync FTEs are used
Any news? Is it now working as expected?
Bernd - radio42
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
Re: "Resolve Overlays to Playlist" does not work well when TimeUpdateSync FTEs are used
Sorry, I had a busy couple of days. I'll will test this out tomorrow, thanks.
Re: "Resolve Overlays to Playlist" does not work well when TimeUpdateSync FTEs are used
I've tried updating but I keep getting this error:
Code: Select all
ERROR: ProppFrexx Update failed!
The following files could not be created:
C:\Program Files\radio42\ProppFrexx ONAIR\DevExpress.Spreadsheet.v16.1.Core.dllRe: "Resolve Overlays to Playlist" does not work well when TimeUpdateSync FTEs are used
Are you sure that all ProppFrexx apps are closed?
Else you might try to unzip the downloaded zip file manually?
I'll also take a look later today (as I am currently on holiday) if the zip file got corrupted during the upload.
Else you might try to unzip the downloaded zip file manually?
I'll also take a look later today (as I am currently on holiday) if the zip file got corrupted during the upload.
Bernd - radio42
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
Re: "Resolve Overlays to Playlist" does not work well when TimeUpdateSync FTEs are used
Strange, I just tested it here (in the holiday resort) myself and it updated just fine!
So maybe you also just try the "Check for Beta-Versions..." again...
So maybe you also just try the "Check for Beta-Versions..." again...
Bernd - radio42
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
Re: "Resolve Overlays to Playlist" does not work well when TimeUpdateSync FTEs are used
The update is now installing fine today.
I've tested a 9 hour playlist and all the overlays are correctly scheduled now, thanks!
For the "max. early" thing, I'm just shifting the start time back which has the same effect when resolving overlays like this (I'm not using AllowEarlyCloseStartTime). I asked in case the reasoning why this didn't happen itself was different to FTEs.
I've tested a 9 hour playlist and all the overlays are correctly scheduled now, thanks!
For the "max. early" thing, I'm just shifting the start time back which has the same effect when resolving overlays like this (I'm not using AllowEarlyCloseStartTime). I asked in case the reasoning why this didn't happen itself was different to FTEs.
Re: "Resolve Overlays to Playlist" does not work well when TimeUpdateSync FTEs are used
I am glad that it is finally working.
Regarding the Max Early and Zmac Laye thing is simply that it is a bit difficult to calculate if not impossible.
In addition will most people pre-schedule playlists for later manual play-out. And in that scenario is such calculation anyhow obsolete.
So I might take a look into this maybe in a future release.
Regarding the Max Early and Zmac Laye thing is simply that it is a bit difficult to calculate if not impossible.
In addition will most people pre-schedule playlists for later manual play-out. And in that scenario is such calculation anyhow obsolete.
So I might take a look into this maybe in a future release.
Bernd - radio42
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution