On-demand has a whole file on the far end, so a player can read ahead as far as it likes and a slow patch disappears into the buffer. Live has no future to read: the newest segment only exists a few seconds before you need it. The player is therefore always running near the edge, holding a handful of six-second chunks. When a segment arrives late, there is nothing to fall back on and the picture stops. Everything that makes live feel fragile follows from that one constraint, including why the same line can stream a movie flawlessly and stutter on a live feed ten minutes later.

1. 1On-demand can read ahead; live cannot read what does not exist yet
2. 2A stall longer than the buffer is a visible freeze, not a spinner

Check scope before you touch a setting. One channel frozen with everything else running is a source problem on that feed. A whole category dark at once is server-side on that group. Everything down at once is your line, your session or your login. Then run the switch-away test: change channel and come straight back. If it plays immediately, the session stalled and your bandwidth was never involved, so leave the router alone. That single test is the cheapest and most discriminating check available for live playback, and almost nobody publishes it in a troubleshooting list.

1. 1One channel: source. One group: server-side. Everything: line or session.
2. 2Recovery on switch-back rules out bandwidth in about five seconds

The guide is the heaviest thing a live player does. It holds every visible channel in memory with its programming data and rebuilds the layout each time you open it. Past roughly 18,000 visible channels, players on stick and box hardware begin to stutter, delay the guide by seconds, or crash on launch. During live viewing this shows up as the guide taking longer to appear than the channel takes to load, which is a strange but very common report. Hiding unused groups and building a favorites list of the channels you watch live fixes it more reliably than any hardware upgrade.

1. 1Favorites lists load far faster than a full guide rebuild
2. 2Guide slowness with clean video points at memory, not bandwidth

Because it is the one thing that cannot be watched later without being spoiled, and because a whole audience arrives on the same feeds in the same minutes. Peak concurrency is where undersized capacity becomes visible, so a service that looks perfect on a Tuesday afternoon can stumble on a Saturday evening. Judge accordingly: test during the hours you actually watch, on the kind of feed you actually watch, not at midday on a documentary channel. If someone will not let you test at your own peak hour, that refusal is itself information about what they expect you to find.

1. 1Test at your own peak hour, not at a convenient one
2. 2Refusing any trial at all is a recognized warning sign

Oversold capacity. If a live channel stalls at the same time each evening, over ethernet, on a second device, and on a second network, you have run out of local variables. No buffer size, DNS resolver or decoder setting reaches a server that is carrying more viewers than it was built for. Pretending otherwise is how troubleshooting guides waste an afternoon. The honest response is to ask any service what uptime it publishes and to test that during peak hours. Our target is 99.99%, which works out at roughly 53 minutes of downtime across an entire year.

1. 1Four eliminations later, the fault is upstream and you should say so
2. 299.99% uptime equals about 53 minutes a year