Every step adds a little
The delay is not one thing. It accumulates.
Encoding. Video compression works by describing how each frame differs from those around it, which means the encoder must hold several frames before it can finish any of them. Unavoidable, and typically a second or two.
Segmenting. Where a stream is delivered as short files, a segment cannot be published until it is complete. Six-second segments mean the newest available content is up to six seconds old before anything is even requested. This is the largest single contributor for HLS, and the reason it is discussed in HLS vs MPEG-TS.
Distribution. Moving content through delivery infrastructure adds a modest amount.
Player buffering. Your player deliberately holds several seconds in reserve so a brief interruption does not become a visible freeze. That reserve is, by definition, delay.
Together these commonly produce twenty to sixty seconds behind the live event.
Why broadcast is ahead
Terrestrial and satellite television are not instant either — they carry their own encoding delay. But they skip segmenting entirely and need almost no player buffer, because the signal either arrives or it does not.
Streaming trades that immediacy for resilience. The buffer is what lets a stream survive a network wobble, and it is also what puts you behind. There is no arrangement that gives both.
Satellite in particular can also be a few seconds behind terrestrial, which is why two people watching "live" by different means rarely see the same moment together.
Why channels differ from each other
A frequent observation: two channels on the same service are not equally delayed.
Different channels are frequently encoded and packaged by different upstream operations, each with its own settings. One might use two-second segments and another ten. That alone is an eight-second difference before anything else varies.
Nothing is wrong when this happens, and there is no setting on your side that equalises it. It is a property of how each channel is produced.
What you can reduce, and what you cannot
Most of the delay is upstream and fixed. A small part is yours.
Worth trying
- Buffer settings, where your player exposes them. Reducing them cuts delay directly. The trade is real: a smaller buffer means less protection, so a connection that wobbles will start showing interruptions. Reduce gradually and stop at the first sign of stutter.
- A wired connection. Not because it is faster, but because it is steadier, which lets a smaller buffer work reliably.
- A different player. Buffering defaults vary considerably between apps, and some are noticeably more aggressive than others.
Not worth trying
- A faster connection. Encoding and segmenting delay are unaffected by bandwidth.
- Router changes. These help stability, which is worth having, but do not shorten the pipeline.
Measuring how far behind you are
Worth doing before you change any settings, because it separates an ordinary delay from something actually going wrong.
- Against radio. Radio commentary on the same event is usually within a second or two of live. Play it alongside the stream and count the gap. This needs nothing you do not already have, and it is the method most people find easiest.
- Against a second source. If there is terrestrial or satellite in the house, put the same channel on both and count the difference.
- Against an on-screen clock. Some news channels carry a running clock. Compare it against a phone that is set by network time.
Twenty to sixty seconds is ordinary and not worth reporting. What is worth reporting is a delay that grows the longer you watch: that usually means the player is accumulating buffer it never spends, which is a different fault from ordinary latency and is dealt with in the buffering guide. A restart of the player clears it, and if it returns each session the buffer setting is set too high for the connection.
Where the buffer setting tends to live
Not every player exposes one, and the naming is inconsistent. TiviMate keeps its buffer controls with the other playback settings. VLC calls the same idea network caching and works in milliseconds, so 1000 is one second. Kodi puts its cache behind advanced configuration rather than the ordinary settings menu. Several of the Smarters-style players offer a decoder or playback option that changes buffering behaviour without naming it as such, so it is worth reading the playback section in full rather than searching for the word buffer. Our player comparison covers which apps give this level of control on which platform.
Living with it during sport
This is where delay becomes genuinely annoying, and the practical answers are behavioural.
Notifications are the main culprit — a score alert arriving before the play does. Muting sports apps and social feeds during a match removes most of the problem.
If several people are watching in different rooms on different means, it is worth accepting that they will not be synchronised. And a stream that is thirty seconds behind is behaving normally; it is not a fault to report. Related considerations are covered on our IPTV for sport page.
Frequently asked questions
Why is IPTV behind normal TV?
Delay accumulates through encoding, segmenting the stream into short files, distribution and the player buffer. Twenty to sixty seconds behind the live event is normal.
Can I reduce IPTV delay?
Partly. Lowering the buffer in your player cuts delay directly, at the cost of less protection against interruptions. Encoding and segmenting delay happen upstream and cannot be changed from your end.
Why are some channels more delayed than others?
Channels are often encoded and packaged by different upstream operations with different settings. Segment length alone can account for several seconds of difference.
Will a faster internet connection reduce the delay?
No. Bandwidth does not affect encoding or segmenting time. A steadier connection helps only because it lets a smaller player buffer work reliably.