The player is not broken, it has run out of stream. Live delivery works by fetching short segments, each around six seconds, in a continuous chain. The player keeps a small reserve and plays from it while fetching the next piece. When a segment arrives late by more than the reserve, playback stops until the chain catches up. That mechanism explains behaviors people find mysterious: a freeze of exactly a few seconds, audio continuing briefly after the picture stops, and a recovery that arrives without you doing anything. Once you know the picture freezes because the reserve emptied, the useful question becomes why a segment was late, not what setting to change next.

1. 1Freeze equals a segment arriving later than the reserve lasts
2. 2Short, repeating freezes are a delivery pattern, not a device fault

Switch to another channel, count to five, and switch back. If the picture is clean on return, the session had stalled and the reconnect rebuilt the segment chain. That result rules bandwidth out completely, because a connection that genuinely could not carry the stream would fail again immediately on the return. This is the single most discriminating test in the whole topic and virtually nobody publishes it. If the freezing resumes within seconds of switching back, the delivery rate itself is the problem and you move on to the wired test. Two outcomes, two entirely different next steps, thirty seconds spent.

1. 1Clean on return: stalled session, not throughput
2. 2Freezes again immediately: sustained delivery rate

Peak speed is not the number that matters, sustained rate is. A 4K stream needs roughly 15 to 25 Mbps held continuously and uses about 7 GB an hour; 1080p needs about 5 to 8 Mbps and roughly 3 GB an hour. HEVC halves those figures against H.264, which is why the same channel can freeze in one encoding and not another. A Wi-Fi link that peaks at 200 Mbps and dips for two seconds when the microwave runs will still freeze a 4K stream, because the dip is longer than the reserve. Test wired once. If wired is clean and Wi-Fi is not, you have your answer.

1. 1Sustained rate matters, peak speed does not
2. 2HEVC needs about half the bitrate of H.264
3. 3One wired test settles the Wi-Fi question permanently

Two changes reliably help, and neither is a cache clear. Set the player's buffer to none or minimal so it stays close to live and reacts fast to a stall instead of accumulating delay. Set the device to a public DNS resolver so segment requests resolve consistently rather than stalling on an ISP resolver. Then trim the visible channel list: players hold the whole list in memory and destabilize above roughly 18,000 visible channels, and hiding unused country and language groups removes a class of stutter that looks exactly like network trouble. Also check whether the app updated recently, since post-update regressions reset buffer and decoder defaults.

1. 1Buffer: none or minimal
2. 2Resolver: public DNS on the device, then reboot
3. 3Hide unused groups to stay well under ~18,000 visible channels

Some freezing is oversold capacity on the provider side. When a group freezes between 7pm and 11pm and runs clean at midday, more viewers are being served by that node than it was sized for, and no buffer setting, resolver change or ethernet cable touches it. Pages that promise a device-side fix for every case are padding a list. The honest response is to make it a purchasing question: what uptime does the service publish, and what happens during large live events, which is the moment people judge and drop a provider. We publish 99.99%, about 53 minutes a year, and you should ask any service for a comparable figure.

1. 1Clock-like, group-wide freezing at peak hours is capacity
2. 2Ask for a published uptime figure, not an assurance