Uptime percentages hide their own meaning until you convert them. A year holds 525,600 minutes, so 99.99% leaves about 53 minutes of downtime, 99.9% leaves roughly 8.8 hours, and 99% leaves over 87 hours. Those three claims look almost identical on a sales page and describe completely different products. Ask for the figure, do the conversion, and then ask the second question that matters more: is downtime measured across the whole platform or per channel group. A service can be up while the group you watch is not, and that distinction is where most disputes start.

1. 199.99% = ~53 minutes a year; 99.9% = ~8.8 hours; 99% = ~87 hours
2. 2Ask whether uptime is measured platform-wide or per group
3. 3A number you can convert beats any adjective on a sales page

By testing when the network is under strain. Any service looks stable at two in the afternoon; stability is a claim about peak hours, so a test off-peak proves nothing. Pick the busiest slot you actually watch, usually a weeknight around eight or a weekend event, and run three checks. Leave one channel untouched for twenty minutes. Start a second stream on another device. Open channels from three separate groups. A service that clears all three during peak has demonstrated capacity; one that clears them on a Tuesday afternoon has demonstrated nothing.

1. 1Test at peak, never off-peak
2. 2Twenty unbroken minutes on one channel
3. 3Three different groups plus a second device

Scope answers this before any setting changes. One dead channel is a source fault at that feed. A whole group failing together is server-side, on the machine holding that group. Everything failing at once implicates your line, your player or an expired session. Then run the cheapest test available: switch away from the frozen channel and back. If it recovers immediately, the session stalled and bandwidth was never the constraint, which rules out the advice you were about to follow. Two settings genuinely help on the local side: buffer set to none, and a public DNS resolver on the device.

1. 1One channel, one group, or everything: three different faults
2. 2Recovery on switch-back means the session stalled, not your line
3. 3Buffer to none and a public DNS resolver are the two settings that help

A live channel arrives as roughly six-second segments that your player queues a little ahead of playback. Any interruption shorter than that queue passes unseen. Anything longer becomes a visible freeze, which is why a two-second network dip is invisible and a twelve-second one is not. Separately, player apps hold the full visible channel list in memory, and above roughly 18,000 entries they slow and crash on modest hardware, producing what looks like instability but is a memory problem. Hiding groups you never open fixes that outright. Post-update regressions are a third recurring cause worth checking before blaming the service.

1. 1Interruptions shorter than the buffer are invisible; longer ones freeze
2. 2Above ~18,000 visible channels, players destabilize on TV hardware
3. 3A new app version is a real suspect after a sudden change in behavior

Oversold capacity. If a service takes on more concurrent viewers at peak than its edge servers were provisioned for, everyone on that edge buffers together, and no buffer setting, DNS change or router reboot touches it. Blaming home internet by default is the standard evasion in this category and it is worth refusing. The honest response is to treat capacity as a purchasing question rather than a support question: ask what uptime the service publishes, ask how many connections your plan allows so you are not over-running your own limit, and test at peak before committing to a year.

1. 1Peak-hour edge congestion is server-side and unfixable locally
2. 2Check your plan's connection count before calling it instability
3. 3Capacity is something you buy, not something you configure