Feat/sofie 449 duration based timing mode

[jesperstarkar]

Type of Contribution

This is a: Feature

Current Behavior

Today you can specify a planned start and planned duration, which to Sofie means the show is scheduled to run within a certain block of walltime.

For floating-start shows, today, you can specify just the duration, then manually start it at the right time. You can currently not hint about the preliminary start time, the best estimate, from the editorial side.

New Behavior

Adding a new timing mode which changes the rules. The intention is to protect the Duration property, and enforce a rule that generates the Planned end property from the actual started time + this planned Duration.

As described in the code comments:
This mode is inteded for shows with a "floating start", meaning they will start based on when the show before them on the channel ends. In this mode, we will preserve the Duration and automatically calculate the expectedEnd based on the actual start of the show (playlist.startedPlayback).

The optional expectedStart property allows setting a start property of the show that will not affect timing calculations, only purpose is to drive UI and inform the users about the preliminary plan as planned in the editorial planning tool.

Testing

Feature tested with simple regression testing on other timing modes in the adjacent code spaces.

• I have added one or more unit tests for this PR
• I have updated the relevant unit tests
• No unit test changes are needed for this PR

Affected areas

This is a bit of a mess...
We follow existing patterns of timing properties and calculations being scattered across corelib, ui libs and ui frontend files.

There's duplications, and nested if/else statements in various places, stacked on top of each other as needed.

We want to change this to a clear pattern in the next scope of work!

Time Frame

Other Information

Status

• PR is ready to be reviewed.
• The functionality has been tested by the author.
• Relevant unit tests has been added / updated.
• Relevant documentation (code comments, system documentation) has been added / updated.

[jesperstarkar]

Testing:

The new mode is feature-tested, with manual regression tests for all other modes on the estimated end and diff calculations.

[justandras]

I've suggested some small formatting changes to fix the failing linting and some code/readability improvements.

[justandras]

I would only have one return statement for timing.expectedDuration for simplicity.

Suggested change

	export function getExpectedDuration(timing: RundownPlaylistTiming): number | undefined {
	// Duration can only be known in Forward- an BackTiming
	if (PlaylistTiming.isPlaylistTimingForwardTime(timing) || PlaylistTiming.isPlaylistTimingBackTime(timing)) {
	return timing.expectedDuration
	} else {
	return undefined
	}
	}

[justandras]

I would move the anchor resolution into a helper for readibility and clarity.

Suggested change

	} else if (PlaylistTiming.isPlaylistDurationTimed(timing)) {
	export function getAnchors(
	playlist: Pick<DBRundownPlaylist, 'timing' | 'startedPlayback' | 'activationId'>,
	timingContext: RundownTimingContext
	): { front: number; back: number } {
	const { timing, startedPlayback } = playlist
	const currentTime = timingContext.currentTime || getCurrentTime()
	if (PlaylistTiming.isPlaylistTimingForwardTime(timing)) {
	const start = startedPlayback ?? Math.max(timing.expectedStart, currentTime)
	const duration = timing.expectedDuration ?? timingContext.totalPlaylistDuration ?? 0
	return {
	front: Math.max(currentTime, start),
	back: timingContext.nextRundownAnchor ?? timing.expectedEnd ?? start + duration,
	}
	}
	if (PlaylistTiming.isPlaylistTimingBackTime(timing)) {
	return {
	front: currentTime,
	back: timingContext.nextRundownAnchor ?? timing.expectedEnd,
	}
	}
	if (PlaylistTiming.isPlaylistDurationTimed(timing)) {
	const start = startedPlayback || PlaylistTiming.getExpectedStart(timing) || 0
	const end = PlaylistTiming.getExpectedEnd(timing, startedPlayback) ?? currentTime + timing.expectedDuration
	return {
	front: Math.max(currentTime, start),
	back: timingContext.nextRundownAnchor ?? end,
	}
	}
	return { front: currentTime, back: currentTime }
	}
	export function getPlaylistTimingDiff(
	playlist: Pick<DBRundownPlaylist, 'timing' | 'startedPlayback' | 'activationId'>,
	timingContext: RundownTimingContext
	): number | undefined {
	const { timing, startedPlayback, activationId } = playlist
	const active = !!activationId
	const { front: frontAnchor, back: backAnchor } = getAnchors(playlist, timingContext)

[justandras]

Since we are changing this function, I would also update this calculation for clarity

Suggested change

	let diff = PlaylistTiming.isPlaylistTimingNone(timing)
	const {
	asPlayedPlaylistDuration: playedDuration = 0,
	remainingPlaylistDuration: remainingDuration = 0,
	totalPlaylistDuration: totalDuration = 0,
	} = timingContext
	const expectedDuration = timing.expectedDuration ?? totalDuration
	let diff = PlaylistTiming.isPlaylistTimingNone(timing)
	? playedDuration - expectedDuration
	: frontAnchor + remainingDuration - backAnchor