The provider's server encodes a channel's video into a continuous sequence of short segments and publishes them as they're generated. Your player app requests those segments over the internet, holds a short buffer of them, and plays them back to back so the picture looks continuous. Because each segment is roughly 6 seconds long, a network stall that lasts longer than your buffer produces a visible freeze, while shorter interruptions usually recover without you noticing. This is fundamentally different from a downloaded file: there's no full copy sitting on your device, just a rolling window of the last few seconds.

Live channels run on a schedule you can't skip ahead of past a limited buffer, shown through an EPG that lists the current and next program. On-demand titles sit in a separate library, start whenever you press play, and have no fixed schedule at all. The two need different things from your connection: live needs steady real-time bandwidth throughout, while on-demand tolerates brief dips since it can buffer ahead before you ever notice one. A catalog description that lumps both together into one number obscures which kind of content you're actually getting most of, and that gap matters more than the total.

About 5-8 Mbps sustained for 1080p, using roughly 3 GB of data an hour, and about 15-25 Mbps for 4K, using roughly 7 GB an hour. HEVC encoding, used on much of today's 4K content, cuts that bitrate need roughly in half compared with older H.264 encoding, which is part of why two 4K claims can behave very differently on the same connection. These numbers need to hold continuously while you watch, not just as a one-time speed test result, since live streaming has no buffer-ahead cushion the way on-demand playback does.

Start by checking the scope: one channel points to a source-side problem, a whole group points to a server-side fault, and everything at once points to your line, player, or session. Switching away from the channel and back is the cheapest test available — recovery on switch-back means the session itself stalled, which rules out bandwidth as the cause. Some buffering is genuinely oversold provider capacity that no device setting fixes, which is a real reason to check a service's published uptime rather than assume the fault is always local.

1. 1Check scope first: one channel, one group, or everything
2. 2Switch away and back to test whether the session stalled
3. 3Set buffer to minimum and use a public DNS resolver
4. 4Check published uptime for provider-side capacity issues