Skip to content

6.4.7 - Live DVR retains the window it advertises

Choose a tag to compare

View all tags
@superuser404notfound superuser404notfound released this 02 Aug 09:44
6.4.7
22f71bb

A live session kept about 40 s of rewind history no matter how large a DVR window it was asked for, while the playlist and the published seekable range advertised the whole thing.

Fixed

  • A live DVR rewind deeper than roughly 40 s no longer asks for a segment the cache has already deleted. Live resolved a segment retention budget of 0, documented as "window-only pruning; the sliding playlist already dropped everything behind the window, so retention would serve nothing". That has it backwards. The playlist window is the looser bound (windowSegmentCount, 300 segments for a 600 s DVR window at a 2 s cadence). pruneOutsideWindow is the tighter one, and with a 0 budget it takes its hard-window branch and cuts at currentTargetIndex - backwardWindow, i.e. 20 segments.

    A live session therefore retained ~42 s regardless of dvrWindowSeconds, while the playlist and liveSeekableRange advertised the full window. A rewind past that asked for a segment evictBelow had deleted, and live has no restartHandler to re-produce it, so the fetch burned its timeout and returned nothing. It also broke the invariant LiveWindowSizing states about itself: that playlist firstVisible and cache eviction read one source of truth "so they can never drift".

    Live now resolves the same volume-aware budget as VOD (2 GiB, clamped to a quarter of free space), which is the mechanism built for precisely this case (#93: "a backward seek into watched content"). backwardWindow keeps its own documented job as the Continuous-Audio handover floor, and remains the part never traded away for history.

    Measured with aetherctl live --dvr-window 600 --fast-zap --realtime --preroll 0: before, cacheCount pinned at 21 for the whole 150 s session at a ~31 MB plateau; after, it tracks production (15, 30, 45, 60, 75) up to 113 MB. Bounded rather than unbounded: the same run at --dvr-window 60 grows to 30 segments, exactly windowSegmentCount, and holds there.

Compatibility

No public API change. VOD behaviour is unchanged: it already resolved this budget. The internal helper vodRetentionBudgetBytes is now sessionRetentionBudgetBytes, since it is no longer VOD-only.

Worth knowing for hosts that set a large dvrWindowSeconds on live: a live session now keeps up to that much history on disk, bounded by the retention budget, where it previously kept about 40 s. At 6 Mbps a 600 s window is roughly 450 MB; the 2 GiB cap covers 600 s up to about 28 Mbps, and the quarter-of-free-space clamp protects a nearly full volume. The producer-side prefetch park this budget also feeds is VOD-only as of 6.4.6, so live cannot park on it.

Upgrading

.package(url: "https://github.com/superuser404notfound/AetherEngine", from: "6.4.7")
Assets 3
Loading