Wi-Fi & Network
Streaming keeps buffering on one TV
Fix buffering on one TV when the internet is 'fast' — the per-stream bandwidth that actually matters (4K ≈ 15 Mbps), the 2.4GHz/distance/mesh trap, and the wired test that localizes it.
Problem summary
Buffering is governed by sustained per-stream throughput at the device, not the headline speed-test number — each service runs an adaptive bitrate ladder and steps down when throughput or buffer health drops (Netflix recommends roughly 3 Mbps for HD, 5 for Full HD, 15 for 4K). When 'my internet is fast' but one TV buffers, the TV is usually on 2.4 GHz, far from the AP, or on a saturated mesh hop. The fastest diagnostic is a wired test: Ethernet to that device removes Wi-Fi as a variable and tells you whether the problem is local Wi-Fi or the WAN.
Run the streaming app's built-in network/speed check on the TV.
Run the streaming app's built-in 'check network' / fast.com on the TV.
The on-device test shows the real throughput at the TV.
Stop blaming Wi-Fi once a wired test still buffers.
Layer path
Step-by-step runbook
Start here. Do each check in order, compare it to the expected result, and stop when the evidence explains the failure or the safe stop point applies.
Measure at the device
Check: Run the app's network check on the buffering TV.
Expected result: You have the real throughput there.
If not: Compare it to ~15 Mbps for 4K.
Test wired
Check: Connect that device/spot to Ethernet and replay.
Expected result: Smooth wired isolates the fault to Wi-Fi.
If not: Still buffering wired → WAN/device.
Fix the Wi-Fi path
Check: Move to 5/6 GHz, closer to the AP, or improve the mesh node.
Expected result: Throughput at the TV rises above the 4K need.
If not: Wire the TV if Wi-Fi can't be fixed in place.
Check concurrency
Check: Count simultaneous 4K streams vs the plan.
Expected result: Total demand fits with headroom.
If not: Stagger streams if the plan is saturated.
Escalate WAN if needed
Check: If it buffers even wired, test/restart the WAN and check service status.
Expected result: WAN throughput supports the streams.
If not: Contact the ISP if the WAN underperforms the plan.
Safe stop: Stop blaming Wi-Fi once a wired test still buffers.
Decision tree
If: Wired playback is smooth, Wi-Fi buffers
Then: Local Wi-Fi (band/distance/mesh), not the ISP.
Action: Get the TV on 5/6 GHz, closer, or wired.
If: Buffers even when wired
Then: WAN/ISP or a device/app issue, not Wi-Fi.
Action: Test the WAN; restart the router; check the device/app.
If: Only one room buffers
Then: Coverage/mesh hop for that room.
Action: Improve the node serving the room or wire it.
If: All TVs buffer at peak usage
Then: Total concurrent bandwidth exceeds the plan.
Action: Stagger streams or upgrade the plan.
Safe stop: Stop expecting many simultaneous 4K streams on an undersized plan.
If: On-device test is fine but it still buffers
Then: App/device or a transient CDN/route issue.
Action: Restart the app/device; retry; check the service status.
Evidence table
| Symptom | Evidence to collect | Likely layer | Next action |
|---|---|---|---|
| One TV buffers, others fine | On-device speed test + band/signal | Weak local Wi-Fi path | Move to 5/6 GHz / closer / wired. |
| Smooth wired, buffers on Wi-Fi | Wired-vs-wireless comparison | Local Wi-Fi throughput | Improve Wi-Fi or wire the device. |
| Buffers even wired | WAN speed test at the device | WAN/ISP or device issue | Test WAN; restart router; check device. |
| One room only | Serving mesh node backhaul | Coverage/mesh hop | Move/wire the node. |
| Everything buffers at peak | Concurrent stream count vs plan | Aggregate bandwidth exceeded | Stagger streams / upgrade plan. |
Commands and settings paths
On-device network check
Run the streaming app's built-in 'check network' / fast.com on the TV.
Where: On the streaming device itself
Expected: Real throughput at the TV (compare to ~15 Mbps for 4K).
Failure means: A low number explains the buffering at that device.
Safe next step: Compare to a router-side test to localize.
Wired isolation test
Connect the device (or a laptop in that spot) to Ethernet and replay.
Where: At the TV's location
Expected: Smooth wired playback = local Wi-Fi is the problem.
Failure means: Still buffering wired = WAN/ISP/device, not Wi-Fi.
Safe next step: Use the result to pick the next fix.
Band/signal check
In the router/mesh app, check the TV's band, link rate, and serving node.
Where: In the router/mesh admin app
Expected: The TV is on 5/6 GHz with a healthy link rate.
Failure means: 2.4 GHz / weak link / distant node throttles it.
Safe next step: Move it to a better band/node or wire it.
Hardware and platform boundary
Change only when
- Wire the heaviest-use TVs (or add a well-placed mesh node with wired backhaul) before upgrading the internet plan — local Wi-Fi is the usual bottleneck, not the WAN.
Evidence that matters
- Sustained per-stream throughput at the device (≈15 Mbps for 4K), a strong 5/6 GHz path or wired link, and plan headroom for concurrent streams.
Evidence that does not matter
- The headline ISP plan number — a gigabit plan doesn't help a TV on weak 2.4 GHz.
Avoid
- Upgrading the internet plan to fix a single TV that's simply on a weak Wi-Fi path.
Related tool/checklist
Use the linked tool when you need a guided plan from your exact symptoms instead of a static checklist.
Wi-Fi dead spot troubleshooterRelated problems
Last reviewed
2026-06-03 · Reviewed by HomeTechOps. Built from 2026-06 research verified against Netflix's current speed recommendations (3/5/15 Mbps — 4K is 15, not the older 25) and buffering guidance. The operator differentiator is per-stream-throughput-at-the-device plus the wired isolation test, not the headline plan speed.
Sources/assumptions
- Assumes one streaming device buffering while other devices/rooms are fine, on a home network with a working internet connection.
- Per-stream speed figures are Netflix's current recommendations (3/5/15 Mbps); 4K is 15 Mbps, not the older 25 figure. Multiple simultaneous 4K streams add up.
Source-backed checks
HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.