2026-05-03

Window TV channels are supposed to behave like rerun loops: resolve the videos, sum their real durations, compute the current wall-clock offset inside that loop, then start the selected video at the matching in-video offset.

The product broke that invariant by allowing some scheduled YouTube videos to enter the loop without concrete duration metadata. Downstream code filled the gap with a fallback segment length so channels stayed populated.

That created two clocks:

guide and scheduler -> fallback slot duration
YouTube iframe      -> provider's real asset duration

One concrete failure was a Tip 2 Tip video with a fallback slot of 2100 seconds, but a real YouTube duration of 1767 seconds. When the scheduled offset landed after 29:27 but before the fake 35:00 slot ended, the guide still believed the current item had time remaining. The iframe had already hit the real end of the video.

From the viewer’s seat, the channel looked like it was repeating or over-serving long programming. The underlying issue was not shuffle logic. It was timekeeping.

The fix was to make real duration required for scheduled VOD inventory:

YouTube VOD without duration -> excluded from scheduled loop
featured VOD without duration -> excluded from scheduled loop
channel with too little valid inventory -> flagged or hidden

Backfilling durations and removing the segment-duration fallback made the source registry, exported inventory, guide, scheduler, and iframe agree on one timeline.

The rule going forward: scheduled VOD math cannot invent playable duration. If the provider controls playback, scheduling needs provider duration. Padding a missing duration keeps the UI full, but it turns the guide into a fiction.