Classic HLS players poll the media playlist every target-duration to discover new segments. That polling either wastes bandwidth (poll too often) or adds latency (poll too rarely). Blocking playlist reload eliminates the polling: the player includes _HLS_msn=N (the next media sequence number it wants to see) and optionally _HLS_part=K (the partial number), and the server holds the HTTP response open until the playlist reaches that version, then sends it.
From the player's perspective this looks like long polling. From the operator's it requires real engineering: the origin must support long-lived request holds, must wake up exactly the held clients when the playlist updates, and CDN edges must transparently proxy the long-lived response. Apple's HLS specification documents the exact semantics — including timeout limits (3 × target duration), the requirement to send If-Modified-Since headers correctly, and the interaction with rendition reports.
Blocking playlist reload combines with EXT-X-PART and EXT-X-PRELOAD-HINT to give the full LL-HLS latency win. Without blocking reload, the player still discovers new partials with one polling-round-trip latency. With it, the discovery is instantaneous — the playlist update arrives the moment it's ready. Production LL-HLS pipelines depend on all three mechanisms together.
