Troubleshoot low-latency HLS
without losing the live edge.

First chunk TTFB hovers at 600ms+ versus a 280ms baseline; chunk-completion p95 climbs into the 1.5–2.0s range. Viewers see a working player that suddenly pauses mid-PART, then jumps forward when the chunk drops land. Live edge creeps from the target 2–3s glass into an 8–10s glass.

The ingest / packaging pipeline publishes the partial segments with Transfer-Encoding: chunked but the first chunk stalls behind a CDN edge read-through or an origin hop. The player can fetch the next PART URI but the body bytes arrive late; manufacturing_server.cadence_drift compounds because the chained partial-segment emitter is waiting on the same stalled socket.

Pin the ingest path to a hold-connection transport, push the manufacturing server onto a dedicated egress so a CDN edge cold-pull cannot stall partial chains, and turn on preemptive PART replay when ingest.chunked_transfer_stall trips a chunk-completion p95 > 1.2s for more than one cadence. Streamwake auto-rebalances the egress preference away from the saturated edge within ~30s of the verdict.

Across the run the agent reports 2 of 8 INDEPENDENT PARTs terminated mid-stream. The client decided the prefetch window was unhealthy, dropped the prefetch, and the player visibly downshifted to a safer buffering posture. Several cohort members see a small rebuffer right at the prefetch drop.

preload.can_preload_hint is still passing at the playlist level, but the BYTE STREAM of the PART never completes. Either ingest.chunked_transfer_stall has a dropped chunk that the client cannot recover from, or the manufacturing server never finished publishing the late-stage parts in the prefetch window and the server returns stale bytes the player will not trust.

Emit the full PART only once manufacturing has acknowledged publish; mark any PART that is mid-publish with the INDEPENDENT=NO attribute and have the player skip the prefetch on those parts. part.prefetch_termination should fall to zero once the publish path is consistently committing ahead of the prefetch window.

PART-DURATION hits 0.660s or 0.990s against a declared PART-TARGET=0.330s. Every off-cycle PART needs a partial append mid-GOP, and the player rolls forward to the next IDR — burning ~250ms of buffer each cycle. Buffer math goes back-of-envelope wrong; ABR descends the ladder.

The encoder is emitting 2.5s GOPs under load instead of the 2.0s GOP locked against PART-TARGET=0.33. The packager splits on inference and the parts occasionally start mid-frame, which is exactly the signature encoder.cadence_part_compatible flags. The packager cannot honor PART-TARGET without a stable GOP underneath.

Lock the encoder cadence so GOP duration divides cleanly into TARGETDURATION (PART-TARGET=0.33 with GOP=2.00 → 6 parts per GOP). The agent replays the trailing partials the moment cadence crosses the ±0.05s threshold; gop.boundary_aligned flips to pass when every PART starts with an IDR.

agent timeline shows manufacturing_server.cadence_drift fail with manufactured_parts_per_sec_p95 = 1.7 against an expected 3.03 (one part every PART-TARGET). The playlist still lines up; the player has not panicked yet — but the publish path is consistently ~430ms behind the encoder.

The LL-HLS packaging server (the manufacturing server) is responsible for chopping the encoded chunks into PARTs and emitting them to the playlist + CDN. Under load the packaging worker pool saturates, the partial-segment publisher stops honoring its SLA, and the playlist cursor stays ahead of the published media. The playlist.delta_updates probe stays green because the playlist is being produced — but the BYTES it references trail by hundreds of milliseconds.

Scale the manufacturing worker pool to keep manufactured_parts_per_sec_p95 inside ±15% of expected_parts_per_sec, and prefetch the next GOP from the encoder into packaging memory any time cadence drift exceeds ±10%. manufacturing_server.cadence_drift should flip back to pass on the next cadence window once the pool recovers.

playlist.delta_updates stays green (deltas honored) but playlist.delta_size flips to warn. The agent timeline p95 for delta bytes lingers at 4,920 on a single probe cycle — most deltas are still ~80 bytes but the over-fetch ratio is climbing. Bandwidth on the live edge roughly doubles inside that window.

A BLOCKING playlist reply slipped into the deltas — usually because ingest.chunked_transfer_stall dropped a partial chunk, the server failed to honor the cursor, or the manufacturing-server stalled and the playlist writer returned the full window the player did not need. The player treats the over-fetched delta as a full reload; CDN cache fill rules no longer apply.

Throttle any delta reply that returns over the delta_size_threshold_b to a single orchestrating client and emit a small delta only, and pair playlist.delta_size with manufacturing_server.cadence_drift so the over-fetch root cause is visible. Streamwake auto-throttles when delta bytes p95 exceeds the threshold for more than two cadences.

blocking_playlist.storm_ceiling fails. Over a 60s window the player cohort issued 18 full BLOCKING playlist GETs against a 4-per-minute ceiling. The CDN edge misses stack up; egress saturates; the cohort is now paying 4–5KB per playlist pull when ~80B was sufficient.

Once playlist.delta_size has been failing for several cycles the cohort loses confidence in the delta cursor — every client correlates the bad delta with a refresh and issues a full BLOCKING reload. The failures feed on each other: more BLOCKING reloads produce more cache misses, cache misses inflate the BLOCKING budget, and the storm takes off.

Inject a server-side cap on BLOCKING reloads per cohort (force re-establish delta cursor on a 410 Gone-style stronger signal), and pair the cap with playlist.delta_size so a delta regression becomes a single coordinated rebalance instead of a storm. Streamwake routes the cohort to a healthier egress and forces a delta cursor replay within a single cadence.