Recover failing MPEG-DASH sessions
without guessing.

Running players — already on segment $Number$=7421 — see the next manifest relist with startNumber=1 and the join cohort sees a fresh timeline. Long-running sessions either drop silently to a 404 on the URI resolution the player built from the old Number, or the live-edge stalls because the news index has nothing the player trusts above $Number$=1.

The packager restarted without draining the prior Number counter. MPD@7422 ships with startNumber="1", SegmentTemplate has no $Number$ inheritance guard, and the previous tail-window probes reference $Number$ values the packager no longer publishes. segment.numbering_drift catches it; window_anchor_advanced trips as a secondary because publishTime moves even though the timeShiftBufferDepth did not advance.

On any packager restart, emit a fresh Period (`<Period id="P1">`) instead of resetting startNumber; or, if you cannot change the Period boundary, preserve Number monotonicity by keeping the prior packager warm long enough to drain the trailing window. Streamwake coerces the agent to replay the prior window the moment segment.numbering_drift fires.

A graceful primary→secondary packager hot-swap lands cleanly. The new MPD skips from $Number$=8210 to $Number$=9100 — the secondary’s startNumber was tuned to “hundreds after the primary” instead of "the exact next Number". A cohort rendering bounds checking catches the gap and stalls on the seam; ABR locks the lowest rung for the cohort that joined across the swap.

Secondary packager startNumber was set conservatively to “a few hundred above where the primary was last seen” — it adds headroom but breaks `$Number$` monotonicity from the player’s perspective. The probe segment.numbering_drift trips on any gap > 1; window_anchor_advanced trips if the gap opens a hole the manifest does not cover in the trailing 6 segments.

Read startNumber from the last successful MPD@tail on the primary side and seed it into the secondary before hot-swap; or, more robustly, use a shared counter (Redis / etcd) so the secondary computes startNumber from the same clock the primary writes. Streamwake asserts startNumber continuity across the trailing 6 segments and trips segment.numbering_drift the moment a gap > 1 appears.

MPD parses green. Players either reject the first segment with “no moof box at declared offset” or report QuotaExceededError on the first .m4s append. Logs show the byte range returned 200 but the box at the offset is not what the player expected. Republisher that emits low-latency subsegments is the suspect.

SegmentBase@indexRange on the v2 Representation points at byte 0x10C0–0x18FF — the sidx box lives inside a subsegment that the republisher is also writing for low-latency delivery. Half the time the sidx is intact, half the time the republisher has overwritten the subsegment body behind the player. sidx.parse_ok fails on the box-cross-check; sidx.references_inline fails because the references resolve out-of-line relative to the init URL.

Co-locate the sidx box inside the byte range of the init URL (SegmentBase@indexRange must NOT cross media-segment boundaries). When streaming live with low-latency rewriting, use SegmentTemplate + SegmentTimeline — sidx is unnecessary, and $Number$ gives you the deterministic address you need. Streamwake fails the attach on the next probe cycle once the sidx box-cross-check fails.

On the first request the player thinks every segment in `timeShiftBufferDepth` is "available now" — even ones the packager has not actually landed yet. The player fetches segment 7423 before the packager publishes it, gets 404, and ABR descends the ladder. Latency reads as 9–12s because the player is chasing a manifest ahead of the byte stream.

The packager declares a low-latency DASH workflow (small timeShiftBufferDepth, short minimumUpdatePeriod) but does not emit `<AvailabilityTimeOffset>` on the AdaptationSet. Default value is 0, which means "all segments referenced inside the available window are ready immediately." For a low-latency republisher that is wrong: the implementation needs a positive offset (typically equal to the manufacturing-server publish cadence) for the legal "available-after-this-much-time" semantics. window_anchor_advanced trips because the player is consuming window anchor faster than the bytes land; availability_offset.coherent flips to fail (or warn).

On any low-latency DASH AdaptationSet, emit `<AvailabilityTimeOffset value="X"/>` where X ≥ the manufacturing-server publish cadence; mirror the same value on every Representation inside the AdaptationSet so audio and video agree. Streamwake asserts availability_offset.coherent on $Number$ + SegmentTimeline t/d alignment.

The player lets a segment sit marked "available" for X seconds longer than the packager has actually published it. Fetch logs show the player doing GETs that return 404 against freshly published media; ABR keeps the lowest rung because buffer math underflows. Latency appears to spike to 15+ seconds when in fact bytes are arriving on time.

A misconfigured packager signs availabilityTimeOffset positive (the spec uses a floating-point offset where positive = "available in PAST relative to a wallclock anchor") by default on every segment, including the live-edge segment that is "available NOW." The probe availability_offset.coherent uses the MPD’s own UTC timing reference against SegmentTimeline starts to detect the sign flip. once the offset flips against a live-edge segment, the player treats it as not-yet-available when it is.

Compute `availabilityTimeOffset` from the live-edge SegmentTimeline start against publishTime, not against the wallclock; emit 0 on the live-edge segment and a strictly positive value only on segments the packager is not yet ready to commit. Verify with availability_offset.coherent on the next MPD reload — the probe should flip to pass within one cadence window of the fix.

A long-running session reaches the next Period boundary, the player tries to fetch the first `.m4s` of $Number$ from the new Period, gets HTTP 404. The previous Period’s tail had no segment with that URI on origin — the new Period has its own BaseURL and the player built the URI from MPD@old. ABR drops to the bottom rung while the seek range catches up.

On Period transition, Representations did not preserve the address shape — the new Period’s $Number$ starts at 1 but the player seeks to $Number$=7421 and asks for `video/720p/seg-7421.m4s` relative to the new BaseURL. The packager has no such URI. segment.numbering_drift fires on the period hop; segment.tail_window fires on the trailing gap.

Either restart the new Period at the prior $Number$+1, or emit an xlink:href into the new Period that resolves against the prior adress. Streamwake asserts window_anchor_advanced on every period boundary and pre-rolls the trailing window so the cohort does not pay the cold-cache tax on the first segment.

Players joining mid-stream land on a manifest where SegmentTemplate @media is `video/720p/seg-$Number$.m4s` but startNumber has just been reset to 1 — yet the partner CDN still has catches named `seg-7421.m4s` on origin (the prior packager’s run). The player fetches `seg-1.m4s`, gets 404, ABR drops the rung.

Same root as the package-restart case but a more aggressive form: the packager decides to "fresh-Number" on a reload but the CDN cache layer still hosts the prior counter. The byte stream at the new address is unrelated to what the byte stream at the old address was — yet the segment hash_drift probe has nothing to compare against because the URIs differ. segment.numbering_drift catches the discontinuity; window_anchor_advanced catches the resulting seek-range mismatch.

On any Number reset, invalidate the cache for every URI under the old counter (`PURGE` on the affected path globs) before relisting startNumber; or, never re-Number during a live event. Streamwake auto-fails the attach on the next probe cycle if the manifest declares startNumber=1 against a CDN that still hosts the previous counter. See the working postmortem at /incident-lab/origin-shield-saturation-correlated-cache-miss-storm — when segment-number-cohort cache-miss posture + origin-shield fan-in co-fire, the queue depth climbs and the cohort is the symptom, the upstream cache-tier is the cause.

Player parses the .m4s bytes; MSE throws `SourceBuffer.appendBuffer` with a track-brand error: the sidx box exists but the major brand in the ftyp box excludes the `msdh`/`msix` track identifier that MSE requires to walk the sidx references. Player falls back to no-segmentation mode and ABR oscillates between rungs.

The packager authored the sidx box but the ftyp brand set in the same media segment is `isom + dash + cmfv` — enough for plain playback but missing the Sidx-aware track identifier MSE looks for when the brand is declared. sidx.parse_ok catches the ftyp/sidx mismatch before MSE does; sidx.references_inline fails because the brand mismatch blocks the append.

Align the ftyp brand set on every media segment so it includes both `msdh` and `msix` whenever the same track publishes an sidx box; have the packager treat this as a packaging lint. Streamwake fires sidx.parse_ok on the next probe cycle the moment the brand set clears.

MPD parses green, but the player believes the segment is 6.0s while the actual bytes only carry 5.7s of media — ABR thinks the buffer underflows halfway through the segment, DESCENDS the ladder, ascends again, and reproduces that oscillation on every cadence. Tail viewers report a half-second rebuffer every 8–10 seconds.

The sidx subsegment durations add up to a $Duration$ that disagrees with the SegmentTimeline `S@t/r/d` on the parent Representation. Cross-element drift — the player schedules the next fetch by $Duration$ but the byte stream only carries what the sidx boxes advertise. segment.tail_window fires because tail-window-bytes is wrong against the declared timeline; sidx.parse_ok fires as the secondary because the box-carve does not match the timeline.

Emit sidx subsegment durations that sum to the SegmentTimeline `S@duration` on the parent Representation; refuse to publish until sum(S@d) == Sum(sidx.ref_size) / $Timescale$. Streamwake pairs sidx.parse_ok with segment.tail_window so the cross-element drift surfaces as a single verdict.

A cohort that joined the live edge starts seeing one of two regression patterns depending on player: native dash.js refetches every segment from the start because it interprets the offset as "the window moved"; shaka-player holds the tail and stops advancing, and latency creeps from 4s to 18s.

`availabilityTimeOffset` was tuned too aggressively for the manufacturing-server cadence — segments the player expected to be ready are still not ready. The player compensates by seeking forward past the offset, which pulls the seek window into the past without ripping forward. window_anchor_advanced trips on the first mismatch; availability_offset.coherent flips as the secondary probe.

Tune offset to match the manufacturing-server’s actual publish cadence (median over the last N windows, not the worst case); re-tune at the next MPD reload. Streamwake asserts availability_offset.coherent + window_anchor_advanced on the same probe cycle so the loop closes on a single cadence.