Aim Digitalise › Guide

Your stream buffers at 9 pm and nowhere else: how to find the real cause

A stream that plays perfectly at 3 pm and falls apart at 9 pm is not a random fault. It is a specific one, and the list of candidates is short: the shared capacity on your line at peak, the Wi-Fi hop between the router and the box, the box's ability to decode what it is being sent, and the source itself. This guide is about identifying which one you have before you touch a single setting, because the fixes do not overlap: the change that solves a congested line does nothing for a decoding problem, and vice versa.

Three different failures people all call buffering

• It freezes, a spinner appears, then it resumes. The player ran out of buffered video and had to wait. This is a throughput or jitter problem, and it is the only one of the three that is genuinely about your network speed.
• The channel never opens. Black screen, or an error the moment you press it. Nothing was playing, so nothing could stall. This is authentication, a failed DNS lookup, a wrong or expired URL, or a stream that is down at the source.
• Audio is perfectly smooth but the video judders, tears or goes into slow motion. Audio and video arrive in the same stream, so a shortfall on the network stalls both together — audio, being the small part, is the last thing to break, not the first. Smooth audio with broken video means the data is arriving fine and the box cannot decode it fast enough. That is a player or hardware problem.

Write down which of these you have. If it is the third one, skip ahead to the player section; nothing you do to your router will help.

Five minutes of measurement before you change anything

1. Speed test on the streaming device, at the hour it fails. Not on your phone, not at noon. Then run the same test at 2 am. Two numbers, written down. The gap between them is the single most informative thing you will measure.
2. Ping for 60 seconds and look at loss and spread. From a laptop: ping -t 1.1.1.1 on Windows, ping 1.1.1.1 on Mac or Linux. Ignore the average. Look at whether any packets are lost and how far the worst replies sit above the best. Latency matters much less here than loss: an Xtream or M3U stream is HTTP over TCP, so every lost packet is re-sent and waited for, and throughput drops hard while that happens.
3. Check which band the box is on and what link rate it reports. The signal bars are decoration. On Android TV this is under Settings, Network & Internet, then the network name; your router's client list shows the same thing.
4. Play the same channel in VLC on a laptop plugged into the router with a cable, at the failing hour. This is the test that splits the problem in half. If the wired laptop is fine and the TV box is not, the problem is between your router and your box. If the wired laptop stalls too, your Wi-Fi is innocent.

If it only happens in the evening

Your line is not a private pipe. The last mile and the capacity behind it are shared, so a connection that measures 100 Mbps at 2 am can deliver a fraction of that at peak. Live TV suffers more than Netflix does from exactly the same conditions, because a live stream cannot pre-download ahead of itself — it can only ever hold a few seconds, so a dip that a video-on-demand app absorbs silently becomes a visible stall.

What genuinely helps: a wired connection to the box, and watching a lower-bitrate version of the same channel so that what you are asking for fits inside what the line can deliver at peak.

What does not help: rebooting the router nightly, buying a mesh system (it fixes coverage, not congestion), or upgrading to a faster plan when your 2 am test already shows plenty of headroom. If 2 am is fast and 9 pm is slow, you are not short of line rate.

Wi-Fi changes that actually move the number

• Use 5 GHz for anything in the same room or the next one. Use 2.4 GHz only when walls force it.
• On 2.4 GHz, pick channel 1, 6 or 11 and set the width to 20 MHz. In a crowded building 40 MHz makes things worse, not better, because it overlaps more neighbours.
• Get the router out of the closed TV cabinet and off the floor. The metal back of a TV and the cabinet door sit directly in the path between router and box.
• Re-check the link rate after every single change. If the number does not move, undo the change. This stops you accumulating a pile of settings that do nothing.

The wired option most people skip

A 100 Mbit Ethernet port carries a 10 Mbps stream at ten percent load, so the cheap port on a cheap box is not your bottleneck. A flat cable tucked along the skirting is unglamorous and it ends this class of problem permanently. If the ONT is in another room, a pair of powerline adapters is usually easier than drilling. If you are still deciding where things go, put the ONT and router in the open, central to the flat, at desk height or above.

Player settings: which ones do something

A buffer smooths out variation. It cannot manufacture bandwidth. If your average throughput is below the stream's bitrate, a bigger buffer just delays the same stall by a few seconds. Increase it only when your ping test showed jitter, not when your speed test showed a shortfall.

• VLC: Preferences, Show settings: All, Input / Codecs, Network caching. Default is 1000 ms; 2000–3000 ms absorbs jitter, at the cost of a slower channel change.
• TiviMate: Settings, Playback — buffer size and decoder are both there.
• IPTV Smarters and similar: the buffer control lives with the player selection, and changing the internal player often matters more than the buffer value.
• Kodi: cache size is set in advancedsettings.xml.

If audio is fine and video judders, do not touch any of the above. Switch the decoder instead — hardware to software, or to the alternate hardware decoder — and see which combination plays cleanly.

DNS and CGNAT: what they explain and what they don't

Changing your DNS to 1.1.1.1 or 8.8.8.8 can fix slow channel opens and lookups that fail outright. It rarely fixes a mid-stream stall: by then the lookup is cached and the data is already flowing. DNS explains failures to start, not failures to continue. Set it on the router so every device inherits it. On Android TV you generally have to switch the network to a static IP configuration before the DNS fields become editable, which also means fixing an address that does not clash with your router's DHCP range.

Being behind CGNAT, which is normal on many Indian home connections, does not cause buffering. It affects incoming connections to your home. Watching a stream is an outgoing connection.

When it is the source, not you

When the answer is "one channel while the rest are fine", the fix is on the provider side rather than yours: report the channel name and the time it failed. Any Xtream-based service — Strong 8K or Trex IPTV, for example — has given you a host, a username and a password, and that login is what identifies you to support. Ask them what to do about the channel, and whether anything on your side has to change.

What to send support so it is fixed in one message

Whether you are messaging your broadband ISP or your IPTV provider, send all of this at once: the channel name, the date and clock time it failed, the device and app, whether you were wired or on Wi-Fi, a screenshot of the speed test from the failing hour, and whether other channels worked at that same moment. Your Xtream host and username are safe to share if support asks for them. Your password is not: nobody needs it to diagnose a stall, and a provider who issued your line already has the account. Check a screenshot before you send it, too — a player's settings screen usually has the password on it. Without that list, the first replies will simply ask you for it.

If your evening problem turns out to be that the household is on mobile data rather than a fixed line, the arithmetic in the hotspot data guide is the next thing to read.