Fixing buffering and stuttering: a checklist that starts with the right question

Most buffering advice starts with "check your internet". You already did. The better first move is to work out which of several failures you have, because each has a different fix and the app has already classified it for you.

Nine failures, not one#

The player has no single notion of "not working". It classifies faults into 9 kinds, and the class decides which recovery runs:

F1  NetStall      no bytes arriving at all
F2  SilentEof     the stream ended without you asking
F3  HardError     the stream would not open
F4  DemuxStarve   bytes arriving, no frames coming out
F5  VideoFreeze   picture stopped, audio still playing
F6  TotalFreeze   both stopped, data still flowing
F7  BlackFrames   everything healthy, picture is black
F8  ClockStall    the input clock stopped advancing
F9  RebufferLoop  repeated rebuffering in a rolling window

These are different problems. F1 is your network or the provider's. F4 is a stream sending padding instead of video, which is a provider problem your connection cannot fix. F7 is usually the source feeding black, which no amount of restarting will help.

Nothing is declared instantly. A fault has to persist through a window first: 4 seconds of zero bytes, 6 seconds of a starved demuxer, 4 seconds of stalled video, 4 seconds of total freeze. Those windows exist because a 2 second hiccup is not a fault. A player that reacted to every one would spend the evening restarting a stream that was about to recover.

What the player already does before you do anything#

Three things, so you do not duplicate them.

It adapts its own buffers. When rebuffering repeats, the player raises its caching floor by 1000 milliseconds per verdict, up to 5000. On a marginal connection the app has probably already given itself more buffer than the 1200 milliseconds of network cache and 800 of live cache it starts with. Turning a buffer setting up by hand often redoes work that already happened.

It is also careful about what counts as rebuffering. An episode is counted only when the cache drops below 62 percent, and it ends at 88. That hysteresis exists because live HLS cache readings wobble across segment boundaries, and counting every dip below full would flag healthy streams as broken.

And it catches the failure that produces no error, which is why "it just sits there" is a real category. A stream can stop sending while leaving its socket open. We tested this against a fault-injection harness and the result was unambiguous: the byte counter delta goes to 0 and there is no player event at all. Nothing errors. Nothing throws. The picture holds on the last frame it had.

That is why detection is a timer watching counters rather than an error handler, and why there is a 4 second wait before anything happens. If your stream freezes and recovers a few seconds later, you have watched that mechanism work.

I did not expect the retry side to be the biggest lever. With both connect graces at 8 seconds, a total byte stall spent 8 of its 15.7 seconds restarting a URL that was still dead. Shortening the retry grace to 4 seconds, the same 4 seconds of zero bytes already trusted to condemn an established stream, was the single largest improvement in measured fault-to-alternate time. The ladder also allows exactly 1 restart before switching sources, because field data showed a second restart of a dead source never helps.

The checklist, in the order that finds things fastest#

1. Is it one channel or all of them? One channel is a source problem and no setting on your machine will fix it. If your provider offers the same channel in another quality or from another server, try that. All channels is your side.

2. Is it wired or wireless? This is the single most productive question. A live stream is a continuous real-time read, and marginal wireless produces exactly the symptom people blame on the player. Try a cable once, purely as a diagnostic.

3. Does the same channel play on another device on the same network? If it plays on a phone and not on the PC, you have narrowed it to the machine. If it fails on both, you have narrowed it to the network or the provider.

4. Are you at your connection limit? Two connections and three devices is a stutter that looks like bandwidth and is not. Max connections covers why a connection can stay spent after you stopped watching.

5. Is the picture actually stopping, or is it judder? Regular, rhythmic stutter on panning shots is usually a refresh-rate mismatch: 50 Hz content on a 60 Hz display. That is a display setting, not a buffer problem, and no amount of caching will change it. Connecting a laptop over HDMI covers it.

If you use a proxy or VPN inside the app#

One behaviour to expect. When a connection profile is configured, media the transport cannot carry fails closed rather than quietly falling back to a direct connection. That is deliberate. A privacy setting that silently stops applying is worse than one that stops working visibly.

So a channel that worked before you configured a profile and fails after it is not necessarily a broken profile. It may be a stream whose scheme the relay cannot carry, refusing to leak. That is the profile working. VPNs and stream performance covers what actually matters there.

If the picture is frozen but the sound continues, that is F5 specifically and it has its own article: video freezes, audio continues for the mechanism, and sound but no picture for what to do about it.