This is the first question, and most pages skip it. Live channels arrive as a continuous run of short segments from a streaming server. On-demand titles are individual files fetched by byte range from storage, often on separate infrastructure. Those two paths can fail independently, which is why a catalog of 219,577+ titles can go dark while live TV keeps running on the same account. If live works, your credentials, your line and your bandwidth are all proven, and every generic fix about restarting the router is wasted effort. If live also fails, stop reading this page and diagnose the connection or the session instead, because you have a different fault.

1. 1Live plays, movies fail: catalog path
2. 2Both fail: line, session or player

Scope decides everything. Open three titles: one recent release, one older title, and one from a different category such as a series episode. If all three fail instantly with no loading spinner, the catalog endpoint or your access to it is the fault, and it is server side. If one whole category fails while others play, that category's storage or its links are the problem, which is still server side but narrower. If a single title fails while its neighbors play, that title's source file is dead or missing. Reporting the exact title to support at that point gets it replaced. Reinstalling the app fixes none of these three.

1. 1Three titles, three categories, thirty seconds
2. 2A single dead title is worth reporting, not troubleshooting

Because playback of a file is byte-range based. The player asks for a specific region of the file, and if that region is corrupt, truncated, or was never fully transferred to storage, the read fails at exactly the same place every attempt. That repeatability is the diagnostic. A bandwidth stall dies at random points, moves depending on the time of day, and clears when the network calms down. A file fault lands on the same timestamp on every device you try. Seek past the point by a minute or two: if playback resumes cleanly beyond it and always dies there on the way through, the file is damaged and no setting on your end repairs it.

1. 1Same timestamp every time: broken file
2. 2Random points that move with the hour: capacity or line

Two mechanisms produce that. The first is a container the device cannot index quickly, commonly a large HEVC file in a wrapper the hardware decoder handles but the seek logic does not, so the player restarts the read instead of jumping. The second is progressive playback without proper byte-range support on the connection, where every seek re-requests the file from the beginning. Toggling the player's decoder between hardware and software usually distinguishes them: if software decoding fixes seeking but the picture stutters, the file's codec is beyond the device's decoder. HEVC runs at roughly half the bitrate of H.264 for the same picture, which is exactly why catalogs use it and why weaker devices struggle with it.

1. 1Toggle hardware and software decoding to separate codec from transport
2. 2HEVC saves bandwidth and costs decoder headroom

Buffering on a title that plays fine in the morning and stalls at nine in the evening is oversold capacity, and no buffer setting, DNS change or app reinstall touches it. Say that plainly rather than blaming a reader's router. What you can do is treat it as a purchasing question: ask any service what uptime it publishes and whether it will let you test before you commit. We publish 99.99%, which is about 53 minutes of downtime across a year, and a $5 24-hour trial exists so you can load the catalog on your own hardware, at your own peak hour, before paying for a term.

1. 1Evening-only stalls are capacity, not configuration
2. 2Test at your own peak hour, not at noon