Network timeouts and retry logic: the player that gives up too early
A single slow segment request should never end a session. It does when the player uses desktop-sized timeouts, retries nothing, or retries everything at once the moment the CDN comes back.
How a transient error becomes a fatal one
Networks fail briefly all the time: an edge node restarts, a Wi-Fi connection renegotiates, an origin is slow for a few seconds under load. A player with a short timeout and no retry converts each of those into a playback error, and the viewer sees a failure for a problem that was over before they finished reading the message.
The opposite mistake is just as common. A player that retries immediately, at a fixed interval, on every kind of failure produces a thundering herd: when a CDN recovers from an outage, every client retries in the same second and knocks it over again. Retrying a 404 for a segment that will never exist wastes the same time as retrying a 503 that would succeed, and neither the player nor the viewer learns anything from it.
- Timeouts set for a desktop on a wired connection, applied to a television on Wi-Fi.
- No retry at all on segment or manifest requests.
- Fixed retry delays with no jitter, synchronising every client after an outage.
- The same retry policy for 404, 403, 5xx and timeouts, which need different handling.
- No alternate path when the primary CDN is down.
The rules that work
Scale timeouts to the content: a segment request timeout around twice the segment duration, so a single slow fetch is tolerated while a stalled one is caught before the buffer drains. Retry timeouts and 5xx responses - 502, 503 and 504 in particular - three to five times with exponential backoff and random jitter. Do not retry 404 or 403 beyond a single confirmation; they indicate a missing object or a rejected request, and the right response is to skip the segment or re-authorise, not to wait. Honour a Retry-After header on 429 and 503 when one is present.
Treat manifests and segments differently. A failed live manifest refresh can be retried on the next refresh interval without any interruption; a failed segment in the buffer window is urgent. On live streams, skipping a permanently missing segment and continuing from the next one keeps the viewer watching, where a strict player would stop.
Fail over, then report
When retries against one base URL are exhausted, switch to another: multiple base URLs in DASH, redundant variant streams in HLS, or a second CDN hostname the player is configured with. Playback continues from the buffered position and the viewer sees nothing. Player libraries such as Shaka Player, hls.js and dash.js expose retry parameters and failover hooks for all of this; the defaults are tuned for browsers, and the work is in setting them for television networks and testing them by pulling the cable during playback.
Every retry and every failover should be reported to analytics with the status code and the CDN involved. A rise in retries is the earliest warning of a delivery problem, usually well before playback failures start.