Buffering is one of the most frustrating problems in streaming. It shows up as a spinning wheel, a frozen picture while the sound carries on, or a video that restarts for a few seconds before stopping again. The usual reflex is to restart the box and blame the provider. Sometimes that is justified, often not. Rather than trying settings at random, it is better to work like a technician: observe the symptoms, form a hypothesis, and check it with a test that changes only one element at a time.
What really happens during buffering
A video player never plays data at the exact moment it arrives. It first downloads a reserve, the buffer (or cache), then starts playback by drawing on that reserve while it keeps filling it. As long as filling is faster than consumption, all is well. As soon as data arrives more slowly than the video consumes it, the reserve drains; when it is empty, the player stops to fill it again: that is the spinning wheel.
There are therefore two main families of causes:
- Data arrives too slowly or in bursts: overloaded server, congested Internet route, weak Wi-Fi, packet loss.
- The device cannot keep up: decoding too heavy, memory full, a background app hogging the processor. In this case it is more stutter than true buffering, but the two are often confused by eye.
Recognizing the symptom
| Symptom | Most likely cause |
|---|---|
| Spinning wheel, then normal playback resumes | Insufficient or irregular bitrate (network or source) |
| Choppy picture but no stops, smooth sound | Decoding too heavy for the device |
| Stops at the same time every evening | Congestion at peak hours |
| Picture breaks into blocks, then rebuilds | Packet loss, common with MPEG-TS streams |
| Clean cut and return to the menu | Stream interrupted on the server side or session expired |
Step 1: isolate the source
Start with the simplest question: does the problem affect one channel or video only, or everything you watch?
- Play other content from the same source (another channel from the same list, for example).
- Then play content from a completely different origin: a high-definition video on a major platform, or the live stream of a free channel on its official site.
If only one channel drops and the others are smooth, the cause is almost certainly on the side of the server broadcasting that stream: bitrate too high for that server, saturated source, badly encoded stream. No setting on your end will fully fix it; you can only enlarge the cache to better absorb the irregularities. If all sources drop, including the big platforms, the problem is at your end: network or device.
As a reminder, a player such as AICKO IPTV provides no content: it plays the streams and playlists you give it, and you must hold the rights to what you watch. The quality of a source depends entirely on whoever broadcasts it.
Step 2: isolate the network
To find out whether the local network is at fault, you need to remove the most fragile variable: Wi-Fi.
- Connect the device by Ethernet, even temporarily with a long cable run along the hallway. If the drops disappear, Wi-Fi is the culprit. The guide Wi-Fi, Ethernet or powerline presents lasting solutions.
- If a cable is impossible, move the device closer to the router or test with a phone placed right next to the TV to measure the signal there.
- Measure speed and latency from the device concerned, at the time the drops occur. Compare with the speeds needed shown in the article what internet speed for 4K.
- Stop other uses in the household for five minutes: consoles downloading an update, computers backing up to the cloud, security cameras uploading their video.
The role of peak hours
If everything is smooth at 3 pm and the drops appear between 8 pm and 11 pm, two hypotheses dominate: saturation of your provider's network in your area, or of the server broadcasting the stream, hit by many viewers at the same time. To tell them apart, compare with a major platform at the same moment: if it stays smooth, it is the source; if it slows down too, it is the connection. A speed test at 10 am and then at 9 pm confirms or rules out the second hypothesis.
Latency and packet loss
Decent speed with very irregular latency, or a few percent of lost packets, is enough to cause drops. This is typical of a router that chokes during a big upload, or of disturbed Wi-Fi. The phenomenon is detailed in the article latency, jitter and packet loss.
Step 3: isolate the device
If the network is flawless and the problem persists on all sources, look at the device.
- Try the same stream on another device connected in the same place: a computer, a recent phone. If it is smooth elsewhere, the original device is too limited.
- Check the codec: an HEVC or AV1 stream on a box that can only decode it in software produces stutter and heavy heating.
- Free up memory: close open apps, restart the device completely (unplug it for thirty seconds if it is a stick or box), then clear the cache of the playback app.
- Watch the temperature: an HDMI stick tucked behind the TV, pressed against its hot components, may lower its clock speed to protect itself. A short HDMI extension moves it away from the heat and often improves Wi-Fi reception too.
- Check the storage space: below 500 MB free, some Android devices become slow and can no longer write their cache.
Adjusting the player's buffer
Once the cause is identified, adjusting the cache is no miracle but it absorbs irregularities. The principle: the larger the reserve, the longer the player withstands a dip in speed, at the cost of a slightly slower start and a small delay behind live.
| Setting | Benefit | Trade-off |
|---|---|---|
| Short cache (2 to 5 s) | Fast start, small delay behind live | Sensitive to the slightest dip in speed |
| Medium cache (10 to 20 s) | Good compromise for most connections | Channel surfing a little slower |
| Long cache (30 to 60 s) | Withstands irregular sources | More memory used, marked delay behind live |
Players built on mpv, whose libmpv engine is also the one in AICKO IPTV, expose these parameters as options. As an example, here is what an mpv.conf configuration file oriented toward stability looks like, on a computer:
# Enable the cache even for network streams
cache=yes
# Amount of video to preload (in seconds)
cache-secs=30
# Maximum memory reserved for preloading
demuxer-max-bytes=150MiB
# Memory kept for seeking backwards
demuxer-max-back-bytes=50MiBOn a TV box with little memory (1 GB or less), avoid high values of demuxer-max-bytes: the app could be closed by the system. In a consumer app, these parameters often take the form of a simple choice between "low", "normal" and "high". You will find the available options on the video player page.
Other useful settings
- Lower the quality when the source offers several: going from 4K to Full HD often divides the bitrate by two or three.
- Change the decoder: switching between hardware and software decoding can fix stutter specific to some devices.
- Change the output format when the source offers the same stream in HLS and in MPEG-TS: HLS, split into segments, often copes better with an irregular connection.
Common mistakes and false good ideas
- Restarting the box at every drop. This hides the problem for a few minutes without diagnosing it. Instead, note the time and the channel at each incident: a pattern quickly emerges.
- Changing DNS to "speed up" the video. DNS only comes into play at the start of the connection; it has no effect on smoothness once playback has started.
- Installing a "booster" or memory cleaner. These apps use resources themselves and bring nothing on recent Android; some even show intrusive ads.
- Multiplying Wi-Fi extenders. Each extra wireless hop can divide the available speed; a single well-placed access point or a cable does better.
- Changing everything at once. If you change the cache, the Wi-Fi and the decoder in one go, you will never know what worked.
If the problem persists despite these steps, the frequently asked questions page lists other particular cases, such as streams that stop after a fixed time.
Summary
- Buffering occurs when data arrives more slowly than the video consumes it.
- Test another source first: if only one channel drops, the problem comes from the server broadcasting it.
- Then test over Ethernet, at the time of the drops, then on another device.
- A cache of 10 to 30 seconds absorbs most irregularities, at the cost of a small delay behind live.
- Change one setting at a time and note the time and stream of each incident.
Frequently asked questions
Why does the video only drop in the evening?
Between 8 pm and 11 pm, operator networks and broadcast servers are under the most load. If a major platform stays smooth at the same time, the saturation concerns the source; if it slows down too, it concerns your connection.
Can increasing the cache make things worse?
On a device short of memory, yes: a cache that is too big can cause the system to close the app. Increase it gradually and go back if the device becomes unstable.
The sound continues but the picture freezes: is it the network?
Not necessarily. This symptom often points to video decoding that is too heavy for the device, notably in HEVC or 4K. Try the same stream on another device or change the decoding mode.
Can a VPN eliminate the drops?
A VPN adds an intermediary and encryption; it generally reduces speed and increases latency. It does not fix weak Wi-Fi or a saturated server, and must never be used to access content you do not hold the rights to.
