mirror of
https://github.com/cpvalente/ontime.git
synced 2026-08-07 16:33:51 +00:00
Claude
1fad99f505
The group timer was derived in the client, which meant every view that wanted it had to depend on the rundown query. That coupling was already awkward for the PiP timer, whose separate react root needed its own query client, and it would have spread to every remaining view. Moving the derivation to the server removes the coupling. The value is still the running event timer offset by the content scheduled around it, so the group keeps behaving as if it were a single event containing all its children. Because the group timer is the event timer offset by a constant, it changes exactly when the event timer does and can share its broadcast throttling. - add RuntimeStore.groupTimer, null unless the running group opted in - split the group around the loaded event when the group is loaded, so the per tick cost is an addition rather than a walk of the rundown - derive on the getState() projection so it cannot drift from the timer it is built on - reduce the client to a plain selector, dropping the PiP query client workaround Also fixes elapsed time, which was calculated from the group duration and so clamped to zero for as long as time added to an event kept the group in credit. It is now derived symmetrically with the remaining time, and the two always add up to the total. Timer and PiP shared eight identical branches for choosing between the two timers. These now go through a single resolver. A group has no warning or danger thresholds, so it only reports as running or overtime, and feeding that phase through the existing modifiers makes the suppression of warning and danger a consequence of what a group is rather than something each view has to remember. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Kniqs443KUNCRABwVJwT7K