This one swap answers more than an hour of setting changes. Turn on a phone hotspot, join the streaming device to it, and open the exact channel that was failing. Clean playback on cellular with a stall on the home network puts the problem in the path your house takes: the resolver your router hands out, a firewall rule, or a crowded band. Failure on both connections means the fault sits upstream of you and no wifi change will reach it. Run this before you reboot anything, because a reboot destroys the evidence and repairs roughly one cause in a dozen.

1. 1Plays on cellular, stalls on wifi: local path, resolver or band
2. 2Fails on both: upstream, so stop changing settings
3. 3Rebooted first and it cleared: you learned nothing about the cause

A speed test measures peak throughput over a few seconds. Live video cares about loss and jitter instead. The stream arrives as roughly 6-second segments and the player holds only a short buffer, so a half-second delivery gap is invisible while a gap longer than the buffer becomes a visible freeze. Wifi produces exactly that pattern: a 2.4 GHz band shared with neighbors and appliances retransmits frames, average throughput stays high, and arrival times scatter. A line reporting 200 Mbps can still drop a 6 Mbps stream. Test during the stall rather than after it clears, and watch packet loss rather than the headline number.

1. 1Throughput is an average; a freeze is a timing failure
2. 2A test run after recovery proves nothing at all

Four, and the rest of the usual list is noise. Move the device to 5 GHz when it has line of sight to the router, since the band is wider and far less crowded, and fall back to 2.4 GHz only at real distance. Set a public resolver such as 1.1.1.1 or 8.8.8.8 on the device or in the router, which removes slow and filtered lookups. Set the player buffer to none so recovery after a gap is immediate instead of delayed. Run Ethernet if the cable run is possible at all, because it removes retransmits, interference and band choice in a single move.

1. 15 GHz within line of sight, Ethernet wherever a cable reaches
2. 2Public DNS resolver on the device or the router
3. 3Player buffer set to none, not to a larger value
4. 4Turn off band steering and QoS reordering while testing

Post-change regressions are a distinct recurring cause and they get misread as service faults constantly. A replacement router or an ISP firmware push resets DNS to the provider's own resolver, switches IPv6 on, and enables band steering and traffic shaping that reorder packets. A new network name also moves a device from 5 GHz to 2.4 GHz without telling anyone. App updates produce the same shape of problem on the device side, where a player that ran for months starts dropping streams after a version bump. If the trouble started within a few days of any change, undo that change first. The timeline is stronger evidence than any speed test.

1. 1New router or firmware: check DNS, IPv6 and band steering
2. 2New app version: roll back or clear its data before blaming the line

Concede this early, because most fix lists will not. Some stalling is oversold capacity on the service side and no device setting reaches it. The signature is a failure that tracks the clock rather than your network, every evening or every time a big live event starts, and that follows you onto cellular. You cannot repair that from a router page. What you can do is treat published uptime as a buying criterion rather than a slogan. IP4KTV runs at 99.99%, which works out to about 53 minutes of downtime across a full year. Ask any service for that number before you pay it.

1. 1Same hour every night, on every connection: capacity, not your wifi
2. 299.99% uptime is about 53 minutes a year, and it is checkable