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.
The book · Volume 2 of 7
Video Streaming: A Complete Guide to Video Delivery: From Network Protocols and Transport to Ingest, HLS, and MPEG-DASH
Blocking playlist reload is what lets LL-HLS players get new parts the moment they exist, without hammering the origin with polls. Volume 2 covers it in detail as part of segment-based delivery: HLS and LL-HLS, MPEG-DASH, CMAF packaging and the glass-to-glass latency budget. Written by Nikolay Sapunov, CEO at Fora Soft.
Implementing LL-HLS blocking playlist reload at your origin and CDN?
We will review your LL-HLS origin and CDN setup and give you configuration that keeps blocking playlist reload fast at scale. 250+ video products shipped since 2005.
