Skip to content

T-Timers expected time estimates#73

Open
rjmunro wants to merge 57 commits intofeat/t-timers-ui-topbarfrom
rjmunro/t-timers-expected
Open

T-Timers expected time estimates#73
rjmunro wants to merge 57 commits intofeat/t-timers-ui-topbarfrom
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
rjmunro added 20 commits March 9, 2026 16:12
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
@rjmunro rjmunro marked this pull request as ready for review March 10, 2026 10:19
@rjmunro rjmunro changed the base branch from feat/t-timers to feat/t-timers-ui-topbar March 10, 2026 12:42
rjmunro and others added 3 commits March 10, 2026 13:16
…t-timers-expected

* commit 'fdc144a86623b2b5874789ac366307e514d3c2ec':
  chore: Show only the playlist name if the playlist contains more than one rundown, otherwise show only the rundown name.
  chore: Removed unused style for timeOfDay T-timer counters, as T-timers are never shown as time-of-day. Simplified the tweakability of the T-timer mock data.
  chore: Added missing font variant variable.
rjmunro and others added 30 commits March 12, 2026 14:03
… before the first take in untimed mode"

This reverts commit 1758a6e.
…he new Rehearsal striped could be seen through the labels when not in the active state. Refrained from doing the same thing with the dimmed hours and colons in counters since the text glow used for highlighting made them stand out too much.
…matches the angle of "missing VT" zebras, indicating a problem. This way the new striped Rehearsal Top Bar background is logically separated from the warnings.
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