5.9.1

A far-forward VOD seek above a retained scrub band no longer parks in 30 s serve timeouts into item death; the producer re-anchors at the target immediately. Patch release (no public API changes).

Fixed

• A far-forward seek whose target sits just above a dead scrub band's resident top now re-anchors the producer immediately instead of riding 3x30 s cache-miss timeouts into -1017 / failedToPlayToEndTime item death and a stage-2 reload (~108 s to correct target state). Reported geometry: a 600 s scrub left its segment band resident under the retention budget (#93), the producer was later re-anchored at ~302 s (march front ~316 s), and a fourth seek targeted 640 s. The request for the target segment fell in the forward-wait window just above the dead band's top, and that branch read the resident cache maximum as "the producer is about to write this", parking the request with no restart. The earlier seeks in the same session all took branches that do check the active producer, which is why only the far-forward one died.

  Two layers were fixed, matching the two misreads:

  • The segment server's forward-wait branch now keys on the active producer's write front (its high water since restart, or its anchor before the first write) instead of the resident maximum. A request beyond the reachable window re-anchors the producer at once; healthy catch-up backpressure one segment past the march front is unchanged.
  • The 8 s seek-deadline path (#129) preserved a "progressing" producer because the old position still had forward buffer, blind to the pending target sitting ~330 s beyond what the march could reach inside the consumer's timeout budget. The deadline backstop now also re-anchors when the pending seek target lies beyond active march coverage; a healthy march filling toward a reachable target still keeps its progress. The deadline log line names the new case (target beyond producer coverage) so a recurrence is directly attributable.

  Reported by cmcpherson274 (#141).

Consumers on 5.9.0 should bump.