Why your IPTV cuts out every 30 seconds (we measured it)
“It cuts out every half minute” is the most repeated complaint in support, and it almost always comes with “and I have 600 Mbps fibre”. Both things are true at once. To understand why, instead of theorising, we attached an analyser to the stream of a commercial IPTV panel and logged, second by second, how many bytes arrived and when.
We are not going to name the provider or the channel: that is not the point, and the pattern we saw repeats across many panels. What matters is the behaviour, because it explains the stalls better than any “restart your router”.
What we measured
We opened a live channel (MPEG-TS over HTTP, H.264 1080p, around 6 Mb/s declared average rate) and logged incoming traffic for several minutes at a time, repeating the test at different hours. The test line was a fibre connection with nothing else running, over Ethernet, to take Wi-Fi out of the equation.
Translated into what the player sees, the server does three different things:
- It starts at full speed. The first 4-5 seconds arrive at 20-25 Mb/s, about four times the channel's rate. That is the server flushing what it has accumulated so the player can start as soon as possible. Fine.
- Then it drops to “a bit more than real time”. Data arrives about 20 % faster than the video consumes it. In theory that is enough for the buffer to grow slowly.
- But it stops. Every 10-30 seconds, the server stops sending entirely for 2.4 to 6.3 seconds. Zero bytes. Then it resumes with a small burst and carries on.
The content arrives intact
This point matters and we did not expect it: nothing is lost during the gaps. When we analysed the stream that arrived, the MPEG-TS timestamps (PTS/DTS) are continuous, with no discontinuities or jumps. In other words, the server does not drop video: it holds it and sends it later. The video is complete; it just arrives in fits and starts.
That rules out the usual explanation of “the provider is losing packets”. It is not losing them: it is delivering them late. And the difference is huge, because a loss problem cannot be fixed in the player, while a delay problem can.
Why it stalls with 3 s and not with 10 s
The buffer is the video the player holds ahead of what you are watching. Now combine that with the numbers above:
| Configured buffer | What happens during a 6.3 s gap | Measured result |
|---|---|---|
| 3 s | The buffer runs dry after 3 s; 3.3 s remain with nothing to show | Visible stall on every long gap |
| 10 s | The buffer drops to 3.7 s and refills with the following +20 % | Not a single stall during the test |
With a 3-second buffer, every gap longer than 3 seconds becomes a loading spinner. Since the gaps occur every 10-30 seconds and several exceed that threshold, the result is exactly the symptom: it cuts out every half minute, even though the connection's average speed is more than enough.
With 10 seconds, the longest gap we saw (6.3 s) is absorbed whole and the +20 % delivery afterwards refills what was consumed before the next one. Same session, same channel, same network: zero stalls.
Why simply setting 20 s all the time is not the answer
Because the buffer is paid for at start-up: the player has to accumulate those seconds before showing a picture, and zapping goes from under a second to several. A high fixed buffer fixes this channel and spoils the experience on the ones that arrive fine. So the right setting is not “more”, it is “more only when needed”.
What Kraid does: adaptive buffer
Based on this measurement, the Kraid IPTV engine behaves like this:
- It starts short. It uses the server's opening burst to start as soon as possible; channel changes stay under a second.
- It measures while playing. It watches how long each chunk takes to arrive and how much buffer is left ahead.
- It raises the buffer by itself when it detects delivery gaps, up to the maximum you have configured (20 s). It does not drop it back abruptly: if the channel pauses again, it is already prepared.
- It reconnects until the signal returns if a gap turns into a real connection drop, with growing waits so as not to hammer the server.
The practical effect is that on channels that arrive fine you notice nothing, and on those that arrive in bursts the buffer grows during the first seconds and the gaps stop being visible.
Which setting to change
If you use Kraid and one specific channel still stalls, open Settings → Playback → Buffer and raise the maximum (presets go up to 20 s). The engine will still start short; you are only giving it more room to grow on the channels that need it. If you use another player with a fixed buffer, try 10 s as a starting point: it is the value that removed the stalls in our measurement.
And before touching anything, make sure the problem is this one and not another: if it stalls only on the TV and not on the phone, or only at certain hours, the cause is different. The full diagnosis is in why IPTV buffers and stutters.
How to tell whether your channel behaves like this
- Raise the buffer to 10 s (or the maximum) and watch the same channel for 5 minutes.
- If the stalls disappear, the server delivers in bursts: leave the adaptive buffer on and forget about it.
- If they continue unchanged, delivery is not the problem: check Wi-Fi, codec and the connection limit.
Frequently asked questions
Why does my IPTV cut out every 20 or 30 seconds when I have fibre?
Because the problem is not your speed: it is how the server delivers the data. On the panel we measured, video arrives in bursts separated by 2.4 to 6.3 second gaps with no bytes at all. If the player only keeps 3 seconds ahead, every long gap leaves it with nothing to show.
How much buffer do I need so it stops cutting out?
In our measurement, more than the longest gap observed: with 3 s it stalled and with 10 s it did not stall once during the whole test. Setting 20 s permanently is not ideal either, because channels take longer to start and zapping gets slow; the best option is a player that raises it by itself when it detects gaps.
Is it the provider's fault or the player's?
The gaps are generated by the provider's server (how it serves the stream, or its load). The player cannot avoid them, but it can absorb them with enough buffer. A player with a short fixed buffer turns every gap into a stall; one with an adaptive buffer does not.
Does raising the buffer make zapping worse?
Yes, if you raise it by hand and permanently: the channel has to accumulate those seconds before it starts. That is why Kraid starts with a short buffer and only grows it on channels where it measures gaps; on channels that arrive smoothly, channel changes stay under a second.
A buffer that adapts by itself
Kraid IPTV measures how the stream arrives and raises the buffer only when needed, up to 20 s. Three engines, automatic reconnection until the signal returns and transcoding on Windows. Free for 7 days, no registration.
Download Kraid IPTV freeLegal notice: Kraid IPTV is a generic media player. It does not include, sell or link to any content, channel or playlist. Users are responsible for the sources they add and for holding the rights needed to watch them. Learn more.