Moving a frozen frame is not removing it: a fix we took out, 15 October 2026

The freeze it was meant to remove

An event in a schedule shorter than one frame of its channel cannot air: there is no frame to put it on. Since 12 October 2026 our engine refuses such an event when a schedule is loaded and when the engine starts. If one reaches the decoder anyway, the decoder passes over it and the compliance log records it as skipped. Its slot, a fraction of a frame, still has to go somewhere. The channel repeats its last frame once, a one-frame freeze at that programme change, and the log declares it as a source arriving late.

The rule we built, and the cost we stated

On 14 October 2026 we built a rule to remove that freeze. Where the next item’s first frame would miss the frame the change itself airs on, the item would start at once, at the change, instead of waiting for its own time. We wrote down its cost before building it: such an item starts up to half a frame early, and the difference rides on to the next item fixed to a time, which starts on its time as every fixed item does.

What our reviews found

We run a read-only review of our own newest work, probing it and inverting its claims. The first one after the rule found the stated cost was wrong. On items that end a little short of their scheduled length, for instance a file whose sound outlasts its picture by a quarter to half a frame, each item started a little earlier than the one before. Within three or four items the difference reached a whole frame, and the engine aired a frame of its emergency material between two programmes. In one test at 25 frames a second there were three such frames and ten of twelve items aired a frame early. The build before the rule had four one-frame freezes there, with every item on time.

We narrowed the rule to the one case it was raised for. The next review, in the early hours of 15 October 2026, found that even there the freeze was moved, not removed. It now landed just before the next fixed-time item, and every item before that aired a frame early. Our own record of the narrowed rule had said there was no freeze anywhere. We had read that off a test printout that listed freezes only beside cue messages, and that test had no cue. We corrected the record in each place it appeared.

What we did

We took the rule out, as two commits that undo it; nothing in our history was rewritten. Then we ran the twenty scenarios both reviews had built, on the engine without its SDI card, against the build from before the rule. What aired was the same on both: every item’s first frame, every freeze and every frame of emergency material between items. Splice cues for downstream ad insertion agreed to within a hundredth of a frame.

The rule was only ever in our development tree. It was never deployed, and nothing described here went on air.

What remains

An event under a frame that is passed over costs one frame, a freeze where it was. Every item airs on time, as before the rule.

The same review found an older rule of ours behaving the same way: a gap shorter than a frame is not a gap, so an item between half a frame and a frame past its programme change started at once. After several items each ending a little short, that could add up to a frame or two of emergency material between programmes. We measured two ways of fixing it and, on 15 October 2026, changed the rule. Such an item now waits for its own time: the change holds one frame, every item airs on time, and nothing compounds. In the tests that showed the problem, five frames of emergency material and four early items in eleven changes became seven one-frame freezes and none early. This change, too, is in our development tree and has not gone on air.

Our next review, on 16 October 2026, found the same band in a rule that runs after a clock step, and found the held frame being counted as the decoder running dry, which would have raised false alarms. We changed both the same day, in our development tree.