Explained
A stream stops in one of three places: at the server, on the line, or in the player. Two of them you cannot change. The third you can.
This page explains what happens between your provider’s server and your screen when the picture stops — for any IPTV player, not for a particular one. Where we have numbers, they are given; where we don’t, that is stated too.
By the end you will know why the picture freezes more often in the evening than at noon, why the commentator sometimes says the same sentence twice, and how to tell whether your provider, your network or your player is at fault.
Your provider’s server receives the channel, converts it and sends it out in small pieces. The pieces travel over the provider’s line into the internet, through your modem and your Wi-Fi to the device. There the player takes them in, builds up a reserve, unpacks picture and sound and shows them.
The stream never arrives evenly. The server delivers in bursts, pauses briefly, catches up. That is normal — a player that keeps a few seconds of reserve shows none of it. A freeze happens when the reserve is empty before the next burst arrives. The question is always: why was it empty?
In the order they occur in everyday use.
At prime time, during a big match, all of your provider’s customers watch at once — and the server converting the channel can no longer keep up. It delivers more slowly, in longer pauses, or it drops connections to catch its breath. Some providers also disconnect after a fixed time, or when your account has more connections open than agreed — a second device, a running recording.
No player can change that. What it can change is how visible it becomes.
Measured in everyday use (10 cases, 23 August to 7 September 2026): the server delivered nothing for between 6.2 and 9.4 seconds, median 7.3 seconds. At a connection limit, two providers ended the older connection 3 to 9 seconds after the new one, 4 of 4 cases.
Between server and device there are three lines: the provider’s into the internet, yours into the house, and your Wi-Fi. If one of them is not enough for the channel, the stream arrives more slowly than it is played — the reserve melts away and at some point the picture stops. A 4K channel needs about four times as much as the same channel in HD; Wi-Fi at the far end of the flat, a router that is streaming and backing up at the same time, mobile data on the go — any one of these is enough.
A player cannot make a slow line faster. It can decide whether to reload at every bottleneck or to play marginally slower until the bottleneck has passed.
Measured (15 minutes with the line throttled to about 90 percent of what the channel needs): a player that reacts to every bottleneck by reloading showed 42 freezes and 29 connection attempts. The same player playing about 7 percent slower instead: one connection, no freeze, a good minute behind live after a quarter of an hour.
The third cause sits in the device, and it is the reason the same provider runs cleanly on one player and freezes on another. The usual design only notices an outage once the reserve is empty — then it reloads the whole stream: the picture stops, the reserve is discarded, the stream starts again a few seconds earlier. You can hear it when the commentator says the same sentence twice. And whatever you could rewind is gone.
The other design separates fetching and playing: one part fetches the stream and keeps a reserve, another plays it. When the reserve runs low, the first part fetches a new connection in the background and attaches it — the playing part notices nothing as long as there is reserve. The reserve then decides how long an outage stays invisible.
Measured (connection cut hard in the lab, without warning): 20 seconds without the server — no freeze. 60 seconds without the server — 40.3 seconds of freeze, because the reserve was 22.4 seconds, but zero reloads: rewind buffer and connection were kept. New connection 1.1 to 2.1 seconds after the server returned.
No single sign is proof on its own, but together they usually point one way.
| What you see | What it points to |
|---|---|
| Only one channel freezes, the others run. | Server — this channel is converted on an overloaded machine. |
| All channels freeze at the same time. | Line — your network or the provider’s line into the internet. |
| In the evening and during big matches, never at noon. | Server or provider line — overload at prime time. |
| The picture stops, then the commentator says the same sentence twice. | Player — it reloaded and picked up again a few seconds earlier. |
| The picture stops briefly, then continues without a repeat. | A server pause the reserve did not quite cover — the player did not reload. |
| Clean on cable, not on Wi-Fi. | Your Wi-Fi — distance, walls, an overloaded router. |
| It drops as soon as a second device watches or a recording starts. | The connection limit of your account with the provider. |
| Sound runs ahead of or behind the picture. | Server — picture and sound were converted separately there; a player cannot repair that. |
Connection to the server cut hard in the lab, without warning, during playback. One player that separates fetching and playing; other players not yet measured.
| Without server | Freeze | Reloaded | New connection after return |
|---|---|---|---|
| 20 s | none | zero times | 1.3 s |
| 30 s | 11.4 s | zero times | 1.2 s |
| 45 s | 18.2 s | zero times | 1.1 s |
| 60 s | 40.3 s | zero times | 2.1 s |
Reserve at the cut: about 20 to 30 seconds; in the 60-second run 22.4 seconds.
How to read it: as long as the outage is shorter than the reserve, you see nothing. If it is longer, you see a freeze of roughly the difference — but no restart, no repeat, and whatever you could rewind stays. Zero reloads in 5 runs.
All measurements come from the Playback Lab of Neverlag, the IPTV player by axiena AG, Zurich: cut runs on 8 September 2026, line throttling on 9 September 2026, delivery pauses from the playback journal of two weeks of everyday use — each on the Mac, release build. So far only this one player has been measured; the numbers say what this design achieves, not that other players do not reach it.
Every run is in the Lab with date, setup and journal entry, including the ones that went badly. Anyone who wants to reproduce the measurement will find the setup there.
Neverlag is an IPTV player for Apple TV, iPhone, iPad, Mac and Fire TV for Xtream Codes and M3U providers. It separates fetching the stream from playing it, so that connection drops do not lead to reloads. Measured: 60 seconds without a connection, zero reloads.
Because in the evening all of your provider’s customers watch at once and the server converting the channel reaches its limit: it delivers in longer pauses or drops connections. On top of that, the provider’s line into the internet is fuller in the evening. Your own network is usually not the reason — unless it is streaming, gaming and backing up at the same time.
Because the player reloaded: it discarded its reserve and picked the stream up again a few seconds earlier. That is the signature of a player that only notices an outage once the reserve is empty. The server was often only briefly slow, not gone.
Quick test: if only one channel freezes, it is that channel’s server. If all freeze, it is the line — yours or the provider’s. If it runs cleanly on cable and not on Wi-Fi, it is your Wi-Fi. If it drops as soon as a second device watches, it is your account’s connection limit. A player with diagnostics measures this for you: if a neutral host answers quickly and the provider slowly, it is the provider.
Against short outages, yes: anything shorter than the reserve stays invisible — measured, 10 of 10 delivery pauses between 6.2 and 9.4 seconds disappeared into a reserve of about 20 to 30 seconds. The price: you are correspondingly further behind live. Against a line that is permanently too slow, no reserve helps — only less data or a better line.
All measurements in the Playback Lab How a player separates fetching and playing IPTV players compared Questions and answers