Skip to content

T-Timers expected time estimates#73

Draft
rjmunro wants to merge 85 commits intofeat/t-timersfrom
rjmunro/t-timers-expected
Draft

T-Timers expected time estimates#73
rjmunro wants to merge 85 commits intofeat/t-timersfrom
rjmunro/t-timers-expected

Conversation

@rjmunro
Copy link
Collaborator

@rjmunro rjmunro commented Feb 6, 2026

About the Contributor

This pull request is posted on behalf of the BBC.

Type of Contribution

This is a Feature

Current Behavior

n/a

New Behavior

Blueprints can add an estimated time to T-Timers either directly or by anchoring them to a part. The over/under compared to the estimate can then be easily tracked in the UI.

Testing

  • 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 PR stores extra T-Timer data in mongo/meteor, adds new interfaces to blueprints integration and timing calculation to the job-worker.

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.

@rjmunro rjmunro force-pushed the rjmunro/t-timers-expected branch from 8dcd562 to 32e84e2 Compare February 10, 2026 17:08
@anteeek anteeek mentioned this pull request Feb 11, 2026
7 tasks
@rjmunro rjmunro force-pushed the rjmunro/t-timers-expected branch from 7f71150 to 6463a63 Compare February 19, 2026 17:17
hummelstrand and others added 28 commits March 5, 2026 16:04
…group, to better indicate that it is clickable.
So we can measure if we are over or under time
This will ensure a timeout is set for the next expected push start time.
…e management

Add three new methods to IPlaylistTTimer interface:
- clearEstimate() - Clear both manual estimates and anchor parts
- setEstimateAnchorPart(partId) - Set anchor part for automatic calculation
- setEstimateTime(time, paused?) - Manually set estimate as timestamp
- setEstimateDuration(duration, paused?) - Manually set estimate as duration

When anchor part is set, automatically queues RecalculateTTimerEstimates job.
Manual estimates clear anchor parts and vice versa.

Updated TTimersService to accept JobContext for job queueing capability.
Updated all blueprint context instantiations and tests.
…tions

Implements segment budget timing for T-Timer estimate calculations in
recalculateTTimerEstimates(). When a segment has a budgetDuration set,
the function now:

- Uses the segment budget instead of individual part durations
- Tracks budget consumption as parts are traversed
- Ignores budget timing if the anchor is within the budget segment
  (anchor part uses normal part duration timing)

This matches the front-end timing behavior in rundownTiming.ts and
ensures server-side estimates align with UI countdown calculations
for budget-controlled segments.
Add optional pauseTime field to TimerState type to indicate when a
timer should automatically pause (when current part ends and overrun begins).

Benefits:
- Client can handle running→paused transition locally without server update
- Reduces latency in state transitions
- Server still triggers recalculation on Take/part changes
- More declarative timing ("pause at this time" vs "set paused now")

Implementation:
- When not pushing: pauseTime = now + currentPartRemainingTime
- When already pushing: pauseTime = null
- Client should display timer as paused when now >= pauseTime
Document the client-side logic for rendering timer states with pauseTime support:
- paused === true: use frozen duration
- pauseTime && now >= pauseTime: use zeroTime - pauseTime (auto-pause)
- otherwise: use zeroTime - now (running normally)
Add timerStateToDuration() function to calculate current timer duration
from TimerState, handling all three cases:
- Manually paused or already pushing
- Auto-pause at overrun (pauseTime)
- Running normally

Also rename "currentTime" to "currentDuration" in "calculateTTimerDiff" method
If the estimate is big, the output should be positive for over.
Just use infininty. The total length may not even be long enough in certain edge cases, for
example if you requeue the first segment while later in the showl.
@rjmunro rjmunro force-pushed the rjmunro/t-timers-expected branch from 6d7de5e to 1132ad0 Compare March 9, 2026 16:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants