Why Does HLS Keep Buffering? A Practical Troubleshooting Guide

Contents

  1. What Buffering Actually Is
  2. A Five-Step Triage Routine
  3. When the Source Is the Culprit
  4. Fixes You Control as a Viewer
  5. The Last Resort: Play It Locally

What Buffering Actually Is

Two clocks run during any HLS session: the playhead consuming footage in real time, and the download frontier fetching the next chunks. The picture freezes the instant the second clock falls behind the first — the buffer has run dry. So every stall, at root, means one of these went wrong: the connection delivers bytes too slowly, an individual segment took an unusually long detour, or the player paused fetching for some other reason entirely.

A Five-Step Triage Routine

  1. Reproduce somewhere clean. Paste the same link into the online player. If it plays smoothly there, the fault lies in the original page or player, not the stream.
  2. Watch the Network panel. Filter for .ts and eyeball load times: a single five-second request points at one bad segment; every request crawling points at bandwidth.
  3. Measure raw throughput. A quick command tells you what the link can actually sustain:
curl -o /dev/null -s -w "%{speed_download} bytes/s\n" "https://example.com/seg-001.ts"
  1. Compare it to the stream's bitrate. If the video needs roughly two-thirds of what your connection can provide, stalls are inevitable — the margin is too thin for network jitter.
  2. Check for rejected requests. Console warnings about CORS, or 403 responses on segments, mean access rules rather than raw speed are to blame.

When the Source Is the Culprit

Fixes You Control as a Viewer

The Last Resort: Play It Locally

When a stream works but only just, watching it through a browser fights the physics the whole way. Pull it down once instead and playback stops depending on the network. The M3U8 to MP4 converter handles this in-browser, and our conversion guide covers command-line alternatives for longer recordings.