Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
About the Contributor
This pull request is posted on behalf of the BBC
Type of Contribution
This is a: Bug fix / Feature
This is a couple of intertwined changes. It might be possible to pull the feature out into its own PR if wanted, but its a pretty isolated opt-in functionality and overlaps in area with the fixes.
Each change is a separate commit in this PR.
Current/New Behavior
There is a limitation in the AB logic, where an infinite piece is not allowed to share a session with any other piece. This limitation was added originally because a
sessionName
was described as needing to be unique within a segment, once out of that segment, it is hard to be sure that the name won't be reused unless care is taken to ensure it is globally unique.This PR allows sessions to opt into being treated as a globally unique id. This allows for skipping a lot of the complex session matching logic performed across parts, as we can be confident that any other references to the same id must be a continuation of a session.
This can also be used for some hold-like behaviour, where a piece gets copied between parts during
onSetAsNext
, prior to this change that would sometimes work, depending on where the two parts were located in the rundown.This fixes a bug where pieces with a postrollDuration were being added to the timeline, referencing the end of their part, which did not have an end time set. This added some noise to the timeline objects, and confused sofie when doing
getResolvedPieces
, as the pieces ended up reporting as having an end time based on the planned duration of the part. This in turn would confuse the AB resolver, as it would see all the sessions as ending when the part reached its expectedDuration, which could cause players to be reallocated while they were still being used.And another fixed bug, where adlibbing a piece using ab with a fixed duration into a part would not cause the ab of lookahead objects to be reassigned correctly, which would result in the next clip disappearing from the multiviewer until the adlibbed clip ended. I think that during a take it would end up swapping to the other player, without sufficient time to preload
Testing
Affected areas
Time Frame
Other Information
Status