Neverlag Playback Lab
IPTV Player Lab
Everything we measure is here. Every run, not just the good ones.
The home page claims that most freezes start in the player. The Lab is the evidence behind that claim: what we measure, how we measure it and what came out.
We measure because claims are cheap. A player that says “stable” has to show how long the picture stands still when the connection is gone, what it does when the line delivers too slowly and what happens when 4K doesn’t get through.
That is why the rule at the top has no exceptions: every run is published, not just the good ones.
Built for networks and streams that aren’t perfect.
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.
- 0 reloads — connection cut for 20, 30, 45 and 60 seconds
- 42 → 0 freezes in 15 minutes on a throttled line — without and with adjustment
- 1.3 s median until the new connection once the server answers again
Method
- Disturbances are produced, not awaited: we cut and throttle the device’s line ourselves, with a stopwatch and the journal.
- Identical source: the same provider, the same channel, the same playlist for every run — and later for every player.
- We count what the viewer sees: frozen picture in seconds, missing programme in seconds, reload yes or no.
- All runs are reported, not the best ones. Median and range where there are several.
- No setting is disabled in a competitor’s app that users would normally have active. We test what the user gets.
- Bench and everyday are kept apart: bench means deliberately disturbed, everyday means the journal without intervention.
- The numbers come from the journal that every Neverlag installation writes locally. You’ll find yours in the app under Diagnostics.
25 September — the evidence for the rethought player
The home page says: Neverlag acts on disturbances before the picture stands still, brings 4K back on its own and shows no black on a restart. Here is the measurement behind that, from 24 and 25 September, on the Mac with the finished app.
We measured against a server we run ourselves (the restart additionally on a real provider stream), with a piece in between that produces disturbances: it cuts the connection, throttles the line, restarts the stream or lets the channel die — on command, with a stopwatch. A camera films the screen; what we count is what you would see.
Above every table, one paragraph says what it shows. Technical terms are in brackets after the everyday word.
The connection is completely gone for 20 seconds and the player has 30 seconds of reserve (buffer). The question: does it intervene although it doesn’t have to — and does the picture stand still? Answer: it reloads nothing and switches nothing, because the reserve carries, and attaches the new connection as soon as the line is back. At that moment the picture stutters for a good half second — that is where the old and the new stream are joined.
| Disturbance | What another player does | What Neverlag does | Measured | Date |
|---|---|---|---|---|
| 20 seconds without a connection, 30 seconds of reserve | Notices once the picture stands still, then reloads | Keeps playing from the reserve, reloads nothing, switches nothing | 0 reloads, 0 switches, 0.6 s stutter at the join, reconnected 4.7 s after the disturbance ended | 25 September |
The provider restarts the stream — the clock inside the stream jumps back to zero (timebase restart). Other players then reload the channel: two seconds of black, rewind window gone. Neverlag holds the last picture and attaches the new stream at the end. Measured first on a real provider stream (routed through our piece in between, two minutes of recording), then once more on our own server: 0.50 s.
| Disturbance | What another player does | What Neverlag does | Measured | Date |
|---|---|---|---|---|
| Stream restarted at the provider | Reloads, about two seconds of black | Last picture stays, then playback continues | Freeze 0.44 s, 0 black frames in two minutes of recording | 24 September |
The channel goes down at the provider: the connection stands, but nothing arrives any more. Other players show an error message. After a few seconds Neverlag establishes that the source is dead and takes the other route to the channel by itself (the second delivery route, HLS). The switch itself costs a good second of freeze. In this run the player then wrongly judged the new route as “not helping” and reloaded once unnecessarily — that bug was fixed on 25 September (finding S50 below), proven on the test bench, not yet repeated live.
| Disturbance | What another player does | What Neverlag does | Measured | Date |
|---|---|---|---|---|
| Channel dead at the provider | Error message, you zap away | Takes the other route to the channel by itself | Other route after 14 s, picture 1.2 s after the switch | 24 September |
The same blockade as above, but on the other delivery route (HLS), where the player has less reserve. Here Neverlag did not bridge the disturbance — the reserve was not enough. But it did not give up: it waits, tries again on its own and is back 9 seconds after the blockade ends.
| Disturbance | What another player does | What Neverlag does | Measured | Date |
|---|---|---|---|---|
| 20-second blockade on the other delivery route (HLS) | Error message “stream unavailable”, the end | Waits, restarts on its own | Restart 9 s after the blockade ended, first picture 0.19 s later | 25 September |
The line is too slow: it delivers 8 megabits per second (Mbit/s), the 4K channel needs 12. Neverlag goes through what might help, step by step, and only then switches to HD — without the picture standing still. When we remove the throttle, it checks in the background two minutes after the switch and brings 4K back on its own, without interruption.
| Disturbance | What another player does | What Neverlag does | Measured | Date |
|---|---|---|---|---|
| Line throttled to 8 Mbit/s, channel needs 12 | Stutters, reloads again and again | Checks the steps, switches to HD, tells you in one line | Switch to HD after 27.7 s, 0 interruptions; the switch itself: one freeze of 0.8 s | 25 September |
| Throttle removed | Stays on HD until you zap | Checks in the background and brings 4K back | 4K back 2 minutes after the switch, 0 interruptions | 25 September |
| “Back to 4K” button pressed | — | Respects your choice for the evening | Button pressed 0.4 s after the switch: back on 4K, 0 second switch | 25 September |
Finally the classic series, the same evening with the finished Mac app: we cut the connection for 20, 30, 45, 60 and 90 seconds, with around 30 seconds of reserve — the test server didn’t build up more. As long as the reserve lasts, you see nothing. When it doesn’t, the picture holds until the connection is back. And after a minute of failed attempts Neverlag shows a message, waits in fixed steps (15, 30, 60 seconds) and then restarts on its own — which is why the 60- and 90-second runs are not good runs. They are here because everything is here.
| Disturbance | What another player does | What Neverlag does | Measured | Date |
|---|---|---|---|---|
| 20 seconds without connection | Notices when the picture freezes, then reloads | Keeps playing from the reserve | 0 s freeze, 0 reloads, reconnect 0.8 s after the end | 25 September |
| 30 seconds without connection | Reloads, rewind window gone | Reserve almost empty, brief freeze, then on | 1.5 s freeze, 0 reloads, reconnect 0.4 s after the end (8 September: 11.4 s freeze) | 25 September |
| 45 seconds without connection | Reloads | Reserve empty, picture holds until the connection is back | 20.5 s freeze, 0 reloads, reconnect 5.0 s after the end | 25 September |
| 60 seconds without connection | Reloads, error message | After a minute of failed attempts: message, 15 seconds wait, restarted on its own | about 43 s without picture, 1 restart, reconnect 13 s after the end (8 September: 40.3 s freeze, no restart) | 25 September |
| 90 seconds without connection | Reloads, error message | Message, waits in steps (15, 30, 60 seconds), restarts on its own | about 106 s without picture, reconnect 46 s after the end of the blockade | 25 September |
What we found along the way and fixed before the release
The first version switched to the other delivery route too early during the blockade — on the same dead line — and threw away 17 seconds of good picture instead of playing them. It remembered the other route as “proven” although it had seven interruptions, and on the other route it clung to a dead source for 45 seconds. We fixed all three and measured again; the numbers above are the measurement after the fix.
Still open: if the channel goes down on the other delivery route, Neverlag currently needs about half a minute until the picture is back via the first route. The next build saves a quarter of a minute of that. It is here because you would see it.
And from the last table: after a minute without connection, Neverlag today waits in fixed steps (15, 30, 60 seconds) before trying again — which is why the reconnect then takes 13 to 46 seconds instead of one. Rare in everyday use; it is in the Lab nonetheless.
Fire TV
The Fire TV build of 25 September (build 20260925.1642) has the same mechanisms as the Apple app. On the stick itself — Fire TV Stick 4K and 4K Max, journals of 22 September and 23 September — this is documented: the app runs with the picture going straight to the TV, and the findings from the stick (no sound on some channels, a white screen after the back button, sound behind the picture after the home button) are fixed in the builds of 23 September.
Not yet documented on the stick: the disturbance measurements above. For Fire TV they ran on 25 September on a lab test device (Fire TV technology, but not the stick itself); there the connection came back one second after the 20-second blockade ended, first picture 0.44 seconds later. The run on the stick is pending and will appear here as soon as it is done.
The week before
The evidence of 25 September builds on things that were built and measured the week before.
-
Reserve of 30 to 60 seconds (23 September)
Neverlag keeps at least 30 seconds of reserve on every device, up to 60 where the line allows. Measured on the Mac: 20 seconds without a connection with 34 seconds of reserve — 0 seconds of freeze, 0 reloads, not a single request to the provider; 45 seconds without a connection: 8 seconds of freeze, no reload.
-
Channel dead — the other route on its own (22 September)
If the channel dies at the provider, Neverlag takes the other delivery route by itself, then another source of the same channel. No setting, no question. In the simulator: picture after 0.55 seconds on the other route. If none of the routes helps, Neverlag tells you — with a countdown to the next attempt instead of hammering the provider with requests.
-
Sound and picture in sync (21 September)
On Apple TV the sound was 15 seconds behind the picture after a cut in the stream — found in the journal of 21 September. Since 22 September Neverlag re-aligns the sound with the picture without reloading the channel; the reserve stays.
-
Consideration for the provider (24 September)
The player holds back at the provider: in 5 minutes of undisturbed playback there were 2 connections to the channel and 2 requests to the account — counted by the piece in between, 0 reloads. During disturbances Neverlag asks at growing intervals, not every second.
- Bench
The finding that changed everything
Freeze, gap, reload with the connection cut
Setup
We cut the connection for 20, 30, 45 and 60 seconds. A fifth run: cut for 20 seconds after Neverlag had been allowed to build up 60 seconds of reserve.
We measure how long the picture stands still, how much programme is missing afterwards and whether the player reloads.
Result
Connection cut Lead-in Freeze Gap Reload 20 s none 0.0 s 0.0 s 0 30 s none 11.4 s 6.1 s 0 45 s none 18.2 s 18.0 s 0 60 s none 40.3 s 34.3 s 0 20 s 60 s 0.0 s 0.0 s 0 Up to 20 seconds you notice nothing: no freeze, no gap. How long the picture stands still beyond that depends on how much reserve there was at the cut — in these runs between 20 and 30 seconds.
To be honest: at 60 seconds without a connection and 22 seconds of reserve, the picture stood still for 40 seconds and 34 seconds of programme are missing. Neverlag didn’t reload here either — playback carried on as soon as the server was back, without throwing the reserve away.
Other players: not yet measured.
- Bench
Slow line
Freezes, connections, pace on a throttled line
Setup
For 15 minutes the line delivers only about 90 percent of what the channel needs. Two runs: once without, once with Neverlag’s playback-speed adjustment.
We count freezes and connections and measure how far playback falls behind live.
Result
Metric Neverlag Lume UHF IPTVX iPlayTV Freezes without adjustment 42 not yet measured not yet measured not yet measured not yet measured Attempts to rebuild the connection without adjustment 29 not yet measured not yet measured not yet measured not yet measured Freezes with adjustment 0 not yet measured not yet measured not yet measured not yet measured Connections with adjustment 1, over 20 minutes not yet measured not yet measured not yet measured not yet measured Playback with adjustment about 7% slower not yet measured not yet measured not yet measured not yet measured Without adjustment the player reloads again and again because the reserve doesn’t last — 42 freezes in 15 minutes. With adjustment Neverlag plays a little slower, keeps one connection for the whole run and never reloads.
Once, in the second minute, Neverlag deliberately held the picture for 7 seconds to build up reserve. That wasn’t an empty reserve but a decision — and it’s here because you would have seen it.
About 7 percent slower means: after a quarter of an hour you are a good minute behind live. The diagnostics show it; you don’t see it.
Other players: not yet measured.
- Bench
Server stops responding
Time to a new connection
Setup
The same five runs as above: the connection is up, the server delivers nothing. We measure how quickly Neverlag is reconnected once the server responds.
Result
Metric Neverlag Lume UHF IPTVX iPlayTV Runs 5 not yet measured not yet measured not yet measured not yet measured New connection after the server returns, median 1.3 s not yet measured not yet measured not yet measured not yet measured Range 1.1–2.1 s not yet measured not yet measured not yet measured not yet measured Reloads 0 not yet measured not yet measured not yet measured not yet measured Neverlag keeps checking whether the server is reachable and reconnects as soon as it responds — in these runs one to two seconds after it came back. It doesn’t wait for a fixed timer and doesn’t reload; the new connection is joined onto the reserve.
Other players: not yet measured.
- Everyday
Short delivery pauses in everyday use
Bridged from the reserve
Setup
No bench: the journal records when the server delivers nothing for a few seconds on an open connection. We count these pauses and whether a freeze occurred.
Result
Metric Neverlag Lume UHF IPTVX iPlayTV Delivery pauses in the period 10 not yet measured not yet measured not yet measured not yet measured Duration, median 7.3 s not yet measured not yet measured not yet measured not yet measured Duration, range 6.2–9.4 s not yet measured not yet measured not yet measured not yet measured Bridged without a freeze 10 of 10 not yet measured not yet measured not yet measured not yet measured Ten pauses between six and nine seconds, all bridged from the reserve. That is exactly the everyday case the reserve is there for.
Other players: not yet measured.
- Everyday
4K: a switch instead of a freeze
Quality switches
Setup
Everyday: if 4K doesn’t get through, the player steps down to the stable tier with a notice and offers a way back. We count automatic switches, the freeze before them and false switches.
Result
Metric Neverlag Lume UHF IPTVX iPlayTV Automatic switches, Mac, 23 August–7 September 4 not yet measured not yet measured not yet measured not yet measured Freeze before the switch 1.5–2.0 s (three times), 15.2 s (once) not yet measured not yet measured not yet measured not yet measured Switch to the same tier, different source 3 of 4 not yet measured not yet measured not yet measured not yet measured False switches, Apple TV, since 5 September 0 (re-measured over 332 s) not yet measured not yet measured not yet measured not yet measured In three of the four switches on the Mac there was no lower tier; Neverlag switched to another source of the same tier and wrote “4K → 4K” to the journal at the time. That was ambiguous and has read “other source” since 2 September.
On 5 September 2026 the Apple TV app stepped down from 4K to HD 9 times in one evening for no good reason: the trigger was dropped frames in the display, not in the stream. Since the evening of 5 September only the stream counts; re-measured: 0 dropped frames in 332 seconds, no switch.
One limit today: 4K HDR on Apple TV. The stream arrives cleanly and the decoder delivers every frame — but converting the HDR picture for the screen still runs on the processor, and at 4K that drops frames. 4K without HDR and 1080p run cleanly. The GPU renderer, which puts the picture straight on screen, is next.
Other players: not yet measured.
- Bench
Two devices, one account
Displacement, waiting, user notice
Setup
Two providers, both allow one connection. Playback is running; then a second device opens a connection to the same account — once to the same channel, once to a different one. We measure what happens to the first connection.
Result
Metric Neverlag Lume UHF IPTVX iPlayTV Providers 2 not yet measured not yet measured not yet measured not yet measured Cases 4 not yet measured not yet measured not yet measured not yet measured First connection ended by the provider 4 of 4, after 3–9 s not yet measured not yet measured not yet measured not yet measured Recording over the running playback connection, everyday, 1 September 44 minutes, 0 errors not yet measured not yet measured not yet measured not yet measured Both providers count connections, not devices — and the most recent connection wins: whoever comes last throws the other out. Until 8 September the one thrown out reconnected immediately, threw back, and two Neverlag devices on one account threw each other out every second.
Since 8 September the second device waits instead of displacing back, and tells you another device is watching right now. Measured on the bench against a simulated provider, not yet with two real devices.
Recording and playback share one connection: on 1 September 2026 a recording ran for 44 minutes over the connection of the running playback instead of a second one — no error because of the limit.
Other players: not yet measured.
The numbers come from the journal that every Neverlag installation writes locally. You’ll find yours in the app under Diagnostics.
What Neverlag does differently Questions and answers Get Neverlag