- Separate stream failures from mpv configuration problems with a clean direct-URL test.
- Tune HLS cache, live-edge distance, and format selection without introducing excessive latency.
- Use logs and playback statistics to distinguish buffering from decoding or rendering delays.
- Confirm the Symptom With a Minimal Clean mpv Command
- Check Options and Customizations Directly Related to HLS Playback
- Check the Network, Operating System, and External Tools
- Use mpv Logs and Runtime Information
- Run a Clean Temporary Test Before Making Permanent Changes
- Quick Fix Checklist
- Frequently Asked Questions
mpv HLS stream buffering usually appears as a slow start, repeated pauses, a frozen picture while audio continues, or playback that never catches up to a live broadcast. The most likely causes fall into a few categories: an unstable stream server, insufficient network throughput, an overly demanding HLS variant, a cache configuration that does not suit the stream, playback too close to the live edge, or an mpv customization interfering with demuxing or decoding. The fastest way to find the cause is to reproduce the problem with a clean command, test the direct HLS URL, and change only one variable at a time.

Start with free Canva bundles
Browse the freebies page to claim ready-to-use Canva bundles, then get 25% off your first premium bundle after you sign up.
Free to claim. Canva-ready. Instant access.
1. Confirm the Symptom With a Minimal Clean mpv Command
Start by separating an mpv configuration problem from a stream or network problem. Open PowerShell, Command Prompt, Terminal, or your preferred shell and run mpv without loading your normal configuration:
mpv --no-config "https://example.com/path/stream.m3u8"
Replace the example address with the actual direct HLS manifest URL. Quoting the URL is important because query strings can contain characters that a shell interprets. On Windows, confirm that the command invokes the intended mpv executable rather than an older copy elsewhere in your PATH.
Watch the playback for longer than the usual time needed to trigger buffering. A successful clean test starts within a reasonable period, builds some cache, and continues without recurring pauses. If that happens, stop changing network and cache settings. Your normal configuration, profile, script, or selected track is probably responsible.
If the clean command still buffers, test the same URL on another network or device when possible. Buffering that follows the URL across devices points toward the server, CDN, manifest, or selected rendition. Buffering that occurs only on one computer points more strongly toward its network path, mpv build, decoder, GPU, or operating system environment.
1.1 Distinguish buffering from a decoding problem
Network buffering and slow decoding can look similar, but their indicators differ. Buffering commonly produces cache-related status messages and pauses while mpv waits for data. A decoding or rendering bottleneck more often causes dropped frames, high CPU or GPU load, audio and video desynchronization, or stuttering despite downloaded data being available.
Press i during playback to open mpv's statistics overlay. Depending on the mpv version and active page, it can show cache, dropped-frame, decoder, and timing information. If the cache repeatedly drains before every pause, investigate delivery and cache behavior. If the cache remains populated while frames are dropped, focus on decoding, shaders, HDR processing, scaling, and video output.
2. Check Options and Customizations Directly Related to HLS Playback
Once the minimal test establishes a baseline, compare it with your normal launch method. mpv can receive settings from command-line options, the main configuration file, profiles, input bindings, scripts, front ends, and media-specific configuration files. Any of these can change network, demuxer, track, output, or decoder behavior.
2.1 Review demuxer cache options
HLS is delivered as a sequence of media segments referenced by a manifest. mpv and its underlying demuxing components must retrieve those segments quickly enough to keep playback supplied. A cache can absorb short network or server delays, but it cannot repair sustained bandwidth shortages or a server that stops sending segments.
Run this conservative test:
mpv --no-config --cache=yes --demuxer-readahead-secs=20 "https://example.com/path/stream.m3u8"
If short stalls disappear, readahead was useful for that stream. Success means the cache stops repeatedly reaching empty during ordinary playback. Once playback is stable, stop increasing the value. Excessive readahead can increase memory use, startup delay, and live-stream latency.
The byte limit can also constrain how much demuxed data is retained. For a high-bitrate stream, test a larger limit temporarily:
mpv --no-config --cache=yes --demuxer-max-bytes=256MiB --demuxer-readahead-secs=20 "https://example.com/path/stream.m3u8"
This is a diagnostic value, not a universal recommendation. A lower-powered or memory-constrained system may need less. If increasing the byte limit makes no measurable difference, return to the default rather than accumulating unnecessary options.
2.2 Understand HLS live-edge behavior
A live HLS playlist normally exposes a moving window of recent segments. Starting very near the live edge minimizes latency, but it leaves little protection against delayed segment publication, network jitter, or CDN inconsistency. A player can appear to buffer even when average bandwidth is adequate because the next segment is not yet available.
To test this, seek slightly backward after the live stream starts, if the playlist permits seeking. If playback becomes stable several seconds behind the edge, the problem is likely live-edge fragility rather than basic decoding. The practical fix is to tolerate more delay, use a less aggressive low-latency rendition, or ask the stream operator to examine segment publication and CDN timing. Do not keep enlarging mpv's cache if the server simply has not published the next segment.
2.3 Check HLS format and variant selection
A master HLS playlist can advertise several renditions with different resolutions and bitrates. Automatic selection may choose a variant that exceeds your sustained connection speed or decoding capacity. For reliable playback, available throughput must remain comfortably above the rendition's actual bitrate, including bursts and protocol overhead.
If you open a site page through mpv and yt-dlp, inspect the formats first:
yt-dlp -F "https://example.com/video-page"
Then test a lower format through mpv with an appropriate yt-dlp format expression:
mpv --no-config --ytdl-format="best[height<=720]" "https://example.com/video-page"
Format availability varies by site, so no single expression fits every source. If the lower rendition stops buffering, the original format demanded more throughput or decoding performance than the system could sustain. Stop adjusting cache values and select a suitable format instead.
When you already have direct variant playlist URLs, test a lower-bandwidth variant directly. This removes website extraction and automatic selection from the experiment.
2.4 Examine profiles, input bindings, and scripts
Search mpv.conf, input.conf, script options, and profile sections for settings related to cache, demuxing, yt-dlp, tracks, video output, hardware decoding, shaders, or network behavior. Do not delete the configuration folder. Rename or disable one suspect file temporarily, or continue using --no-config while narrowing the difference.
Use --show-profile to print a named profile's contents:
mpv --show-profile=profile-name
Check automatic profiles as well as profiles selected by a launcher or input binding. A script can also change properties after startup, so a command-line value may not remain in effect.
Screenshot settings rarely cause HLS buffering by themselves. However, a stuck input binding or script that repeatedly captures screenshots can create disk and rendering load. Confirm that screenshot messages are not appearing continuously and that the destination directory is writable.
2.5 Test tracks, subtitles, output, and hardware decoding
Subtitle rendering, complex ASS effects, heavy shaders, HDR tone mapping, interpolation, and high-resolution scaling can make a network stream stutter even when its data arrives on time. Test without subtitles and custom shaders:
mpv --no-config --sid=no "https://example.com/path/stream.m3u8"
If needed, compare software decoding with automatic hardware decoding:
mpv --no-config --hwdec=no "https://example.com/path/stream.m3u8"
mpv --no-config --hwdec=auto "https://example.com/path/stream.m3u8"
Keep whichever mode is stable on your hardware. Hardware decoding support depends on the codec, pixel format, driver, platform, and output path. Success means dropped frames and decoder delays decline while the network cache remains healthy.
HLS can include multiple audio, video, and subtitle tracks. Use the statistics overlay or console output to inspect the selected tracks. Temporarily selecting a simpler audio track or disabling subtitles can reveal a malformed rendition or expensive subtitle stream. If only one track combination fails, the overall network connection may not be the cause.

3. Check the Network, Operating System, and External Tools
3.1 Measure sustained network throughput
A speed test is useful but incomplete because it may use a nearby server rather than the HLS provider's CDN. Test at the same time of day and on the same connection where buffering occurs. Wi-Fi interference, VPN routing, packet loss, overloaded proxies, and corporate filtering can all reduce consistent segment delivery.
- Try a wired connection or move closer to the wireless access point.
- Temporarily compare playback with and without an authorized VPN or proxy.
- Pause large downloads, cloud synchronization, and other high-bandwidth traffic.
- Test a lower-bitrate rendition instead of relying only on a speed-test result.
- Compare another known-good HLS stream to isolate the original server.
Success means segment downloads remain ahead of playback and the cache no longer drains. If every device buffers only on one stream, report the issue to its operator with timestamps and the affected rendition.
3.2 Verify yt-dlp and the direct HLS URL
When mpv opens a webpage rather than an .m3u8 URL, yt-dlp may be responsible for extracting the playable address. An extractor failure, expired signed URL, authentication requirement, or unavailable format can be mistaken for an mpv player issue.
Run yt-dlp separately with the page URL and review its output. Use an official installation method or the project's documented release channels. Avoid random binaries and codec packs. If yt-dlp returns a direct HLS URL, test that URL immediately with mpv --no-config. Signed addresses may expire, so an old copied URL can fail even though a newly extracted one works.
If the direct URL plays correctly but the page URL does not, focus on extraction, cookies, authentication, or format selection. If both buffer identically, investigate the HLS delivery path and rendition.
3.3 Check permissions, paths, drivers, and backends
Operating system permissions are less likely to cause intermittent HLS buffering than total startup failure, but they matter when mpv writes logs, cache-related files, screenshots, or script data. Choose writable paths and quote filenames containing spaces.
GPU driver or display-server problems can cause stutter that resembles buffering. Compare hardware and software decoding, disable expensive shaders, and test the default video output before forcing a specific output driver. Linux users can compare supported Wayland and X11 sessions when the issue is clearly presentation-related. Windows and macOS users should prefer current GPU drivers or operating system updates from official vendors.
Audio backend failures usually produce audio initialization errors rather than an empty network cache. If video proceeds while audio repeatedly resets, test the default audio output and remove forced device selections. Keep the investigation tied to evidence in the terminal rather than changing unrelated backends preemptively.
4. Use mpv Logs and Runtime Information
Start mpv from a terminal so errors remain visible. For more detail, write a log while reproducing one buffering event:
mpv --no-config --msg-level=all=v --log-file=mpv-hls.log "https://example.com/path/stream.m3u8"
A verbose log can contain the full stream URL, including temporary tokens or authentication parameters. Remove sensitive data before sharing it publicly.
Look for repeated reconnects, HTTP errors, timeouts, slow segment retrieval, demuxer warnings, decoder failures, dropped frames, or script errors. One isolated warning may be harmless. Repeated messages aligned with every stall are more useful.
The --msg-level option can target noisy components after the broad test. Available message prefixes can vary, so consult the manual associated with your installed build rather than copying an unsupported category blindly. The --log-file option is particularly valuable when a graphical launcher closes the console.
Use --show-profile=NAME to inspect a profile and the statistics overlay to observe playback. To inspect tracks, use the overlay, terminal identification output, or mpv's track-list property through its console or IPC interface. If an IPC controller changes cache or track properties, repeat the test without that controller.
5. Run a Clean Temporary Test Before Making Permanent Changes
A disciplined comparison prevents a simple mpv troubleshooting task from turning into a confusing collection of permanent tweaks. Use this sequence:
- Run the direct HLS URL with
--no-config. - Observe cache behavior, dropped frames, selected tracks, and terminal messages.
- Test a lower-bitrate variant.
- Test modest demuxer readahead.
- Compare
--hwdec=noand--hwdec=autoif frames are dropping. - Restore your normal configuration in small groups.
- Stop when the single responsible option, script, profile, rendition, or network condition is identified.
Do not combine a new cache size, output driver, hardware decoder, subtitle mode, shader chain, and yt-dlp format in one command. If the result improves, you will not know which change mattered. A clean successful test should play beyond the previous failure point without cache exhaustion, repeated reconnects, or excessive dropped frames.
6. Quick Fix Checklist
- Quote the URL and test it with
mpv --no-config. - Test the direct
.m3u8URL instead of the webpage. - Confirm the stream is stable on another device or network.
- Choose a lower-bitrate HLS variant when throughput is marginal.
- Try
--cache=yes --demuxer-readahead-secs=20as a temporary diagnostic. - Move slightly behind the live edge when the playlist permits it.
- Compare software decoding with
--hwdec=auto. - Disable custom shaders, complex subtitles, and scripts temporarily.
- Inspect profiles with
--show-profile. - Capture a verbose log and correlate errors with each stall.
- Update mpv and yt-dlp only through trusted, documented sources.
- Stop changing settings once playback is consistently stable.
7. Frequently Asked Questions
7.1 Why does mpv buffer only on one HLS stream?
The stream may have an unstable origin, delayed segment publication, a problematic CDN route, malformed segments, or variants whose advertised bandwidth does not reflect their peaks. Test another HLS source and the affected stream on another device. If the problem follows only that stream, local mpv changes are unlikely to provide a complete fix.
7.2 Will a larger cache always fix HLS buffering?
No. More readahead can absorb short interruptions, but it cannot overcome sustained throughput below the stream bitrate. It can also increase startup time, memory use, and live latency. Increase it modestly, verify the result, and stop when the cache remains healthy.
7.3 Why does a live stream work after I seek backward?
You have created distance from the live edge. That delay gives mpv more time to obtain upcoming segments and protects against server publication jitter. The tradeoff is higher latency. This result strongly suggests a live-edge delivery problem rather than a local-file decoder problem.
7.4 Why is a webpage URL slow while the direct HLS URL works?
The webpage path adds extraction, format selection, authentication, and possibly yt-dlp processing. Test yt-dlp separately, refresh expired signed URLs, and verify the selected format. Stable direct playback indicates that mpv's core HLS playback path is functioning.
7.5 Can subtitles, HDR, or shaders cause apparent buffering?
Yes, but they usually cause rendering delays or dropped frames rather than true network cache exhaustion. Disable them temporarily and inspect the statistics overlay. If the cache stays full while playback stutters, optimize the video-processing path instead of enlarging the network cache.
7.6 When should I stop troubleshooting mpv?
Stop changing mpv settings when a clean direct-URL test is stable or when the same stream fails across multiple players, devices, and networks. In the first case, restore customizations gradually. In the second, collect timestamps, rendition details, and sanitized logs for the stream provider because the server or CDN is the likely cause.