HLS buffering on Samsung Tizen and LG webOS: what actually causes it

It is usually not the connection

The instinct is to blame the viewer's bandwidth, and occasionally that is right. But a television on the same network as a laptop that plays the stream perfectly is telling you the problem is on the device or in how the stream is built, and measuring throughput on the TV first saves a lot of wasted investigation.

Wi-Fi is worth ruling out honestly, though: televisions often have worse antennas than phones and sit in fixed positions behind furniture. A wired test is a five-minute experiment that either eliminates or confirms an entire category of cause.

Ladder design that TVs cannot follow

Adaptive bitrate only works if the player can move between rungs quickly and safely. Two ladder mistakes cause most TV-specific rebuffering.

• No low rung to fall back to. A ladder that starts at 3 Mbps has nowhere to go when throughput drops, so the player rebuffers instead of degrading.
• Too many rungs too close together, which makes the player oscillate between them and spend its time switching rather than filling the buffer.
• Renditions that are not keyframe-aligned, so a switch requires discarding buffered data - the switch itself then causes the stall it was meant to avoid.
• A top rung far above what the panel can display, which wastes bandwidth on a stream the viewer cannot perceive and makes the player more fragile.

Segment length and request overhead

Short segments reduce latency but multiply the number of requests, and request overhead is where TV browsers are weakest. Each segment may involve connection setup and a TLS handshake if connections are not being reused, and on modest hardware that cost is large relative to the segment duration.

Four to six second segments are a reasonable default for on-demand on these platforms. If you have gone shorter for latency reasons, confirm that keep-alive is genuinely working end to end - a CDN or origin that closes connections turns a small inefficiency into constant rebuffering on exactly the devices least able to absorb it.

Manifests and memory

A long on-demand asset with short segments produces a large playlist, and parsing a very large manifest on every reload is measurable work on a television. Long live DVR windows have the same effect. If the manifest is hundreds of kilobytes, that alone can produce periodic stalls that look exactly like network problems.

Memory pressure is the other device-side cause and the one most often missed. A page holding large images, a long catalogue list or leaked DOM nodes from previous screens leaves the media pipeline short of buffer, so playback degrades the longer the session runs. The signature is a stream that plays well immediately after launch and badly after twenty minutes of browsing - which points at the app, not the stream.

Use the platform player properly

On Tizen, Samsung recommends its AVPlay API over the plain HTML5 video element for adaptive streaming, and AVPlay exposes streaming properties that control adaptive behaviour - including constraining the bitrate range the player will select from. The HTML5 element with MSE and EME is also supported, but a browser player running on it gets none of that platform-level control. On webOS, playback goes through the platform media pipeline with its own configuration. In both cases, a JavaScript player library layered on top of the platform player instead of driving it correctly is a common and avoidable cause of poor adaptation.

Because behaviour differs by model year on both platforms, any conclusion here needs confirming on the oldest devices you intend to support. A fix that resolves rebuffering on a current set can leave a five-year-old model unchanged.