About me
I found this bug while authoring the Broadcast Conductor app that uses TSR Bridge from the superconductor project. The bug was tested and validated using Superconductor.
Observed Behavior
Bug Summary
When a CasparCG device disconnects and later reconnects, [timeline-state-resolver] can replay state using a stale timeline timestamp instead of current resolver time.
This causes resumed playback to seek to an old position rather than the correct live position.
Observed Behavior
This is most obvious in setups with one or more CasparCG outputs (most visible with two outputs running the same absolute-time schedule), if one server is offline for a period and reconnects:
The reconnected server resumes near the last position it had before disconnect.
It remains offset from the continuously running server by approximately the disconnect duration.
.
Expected Behavior
Expected Behavior
On reconnect/resync, the reconnected CasparCG device should use current resolver time (including current clock offset) and align with the live timeline position, minimizing or eliminating drift versus other devices.
Version
52
Severity / Impact
Impact
Significant on-air desync between parallel playout outputs.
Offset scales with outage duration, so longer disconnects produce larger visible mismatch.
Likely Root Cause
During reconnect state replay, the “state before now” was reapplied with its original historical [state.time] instead of a refreshed current time, leading seek/play calculations to be based on stale time
About me
I found this bug while authoring the Broadcast Conductor app that uses TSR Bridge from the superconductor project. The bug was tested and validated using Superconductor.
Observed Behavior
Bug Summary
When a CasparCG device disconnects and later reconnects, [timeline-state-resolver] can replay state using a stale timeline timestamp instead of current resolver time.
This causes resumed playback to seek to an old position rather than the correct live position.
Observed Behavior
This is most obvious in setups with one or more CasparCG outputs (most visible with two outputs running the same absolute-time schedule), if one server is offline for a period and reconnects:
The reconnected server resumes near the last position it had before disconnect.
It remains offset from the continuously running server by approximately the disconnect duration.
.
Expected Behavior
Expected Behavior
On reconnect/resync, the reconnected CasparCG device should use current resolver time (including current clock offset) and align with the live timeline position, minimizing or eliminating drift versus other devices.
Version
52
Severity / Impact
Impact
Significant on-air desync between parallel playout outputs.
Offset scales with outage duration, so longer disconnects produce larger visible mismatch.
Likely Root Cause
During reconnect state replay, the “state before now” was reapplied with its original historical [state.time] instead of a refreshed current time, leading seek/play calculations to be based on stale time