When the two parameters demuxer-max-bytes and demuxer-readahead-secs are enabled, switching to a TrueHD audio track requires a 50-second wait before audio starts playing.

[yosh-wang]

mpv Information

mpv v0.41.0-922-gf4d13e1c2 Copyright © 2000-2026 mpv/MPlayer/mplayer2 projects
built on Aug 11 2026 15:01:21
libplacebo version: v7.371.0 (v7.360.0-109-g4d82c68-dirty)
FFmpeg version: N-126085-g98e45d607
FFmpeg library versions:
libavcodec      63.7.100
libavdevice     63.2.100
libavfilter     12.3.101
libavformat     63.5.101
libavutil       61.5.100
libswresample   7.2.100
libswscale      10.2.100

Other Information

- Windows version: Windows 11 Enterprise 24H2 [Version 10.0.26100.7171]
- GPU model: NVIDIA GeForce GTX 1660 SUPER, Driver version: 610.88
- Source of mpv:
- Latest known working version:
- Issue started after the following happened:

Reproduction Steps

Problem Description

1. Scenario 1

mpv.conf settings:

#demuxer-max-bytes=500MiB
#demuxer-readahead-secs=60

1.1 Same MKV file, audio track switch during playback
1.2 After switching, audio starts within about 2 seconds and plays normally.

Log1:
output-Sound.from.output.is.working.txt

[mkv] refresh track 6 (audio)
[cplayer] delaying audio start 2372.960000 vs 2370.827000, diff=2.133000

2. Scenario 2

mpv.conf settings:

demuxer-max-bytes=500MiB
demuxer-readahead-secs=60

1.1 Same MKV file, audio track switch during playback
1.2 After switching, there is no sound for 40~50+ seconds. Sound only comes back after that time.

Log2:
output-No.sound.from.output.txt

[mkv] refresh track 10 (audio)
[mkv] can't issue refresh seek
[cplayer] delaying audio start 2598.188000 vs 2554.718000, diff=43.470000

3. Scenario 3

mpv.conf settings:

demuxer-max-bytes=500MiB
demuxer-readahead-secs=60

1.1 Same MKV file, audio track switch during playback
1.2 After switching, there is no sound for 40~50+ seconds.
1.3 At this point, manually dragging the progress bar brings the sound back immediately.

Log3:
output-No.sound.from.output.until.you.drag.the.progress.bar.txt

[cplayer] Run command: seek, target="5.000000"
[mkv] queuing seek to 2561.971000
[mkv] execute seek (to 2561.971000 flags 32)
[mkv] seek done
[cplayer] hr-seek, skipping to 2561.971000

Video Information (MediaInfo):
变形金刚1.Transformers.2007.UHD.Bluray.REMUX.2160p.HEVC.DV.HDR.TrueHD.7.1.Atmos.20Audios@oSpecialCN.mkv.MediaInfo.txt

The three full log files have been attached.

We observed the following:

1. Without cache limits enabled, switching to a TrueHD audio track produces sound in about 2 seconds. Is this considered normal behavior? Is this expected?

2. With cache limits enabled, switching to a TrueHD audio track results in about 50 seconds of silence, and manually dragging the progress bar restores it immediately. We would like to kindly ask: is this a bug in the mkv demuxer, or is it expected behavior under the current design?

If this issue could be addressed, we would really appreciate it. If not, would you happen to know any workaround we could use for now?

---

Another test:：

4. Scenario 4

mpv.conf settings:

demuxer-max-bytes=500MiB
demuxer-readahead-secs=60

4.1 Different MKV file (大话西游之月光宝盒, 1080p, DTS-HD MA, 2 audio tracks, ~50GB)
4.2 Audio track switch during playback works normally. Sound starts within about 0.3 seconds.

Video Information (MediaInfo):
仙履奇缘.1995.1080p.BluRay.Remux.AVC.DTS-HD.MA.5.1 -WuKe.mkv.MediaInfo.txt

Log4:
output-切换音轨后立马出声音.txt

[mkv] refresh track 2 (audio)
[mkv] refresh seek to 1096.680000
[cplayer] starting audio playback

One thing that confuses me about Scenario 4: under identical cache settings (demuxer-max-bytes=500MiB and demuxer-readahead-secs=60), DTS-HD MA track switching works within ~0.3s, while TrueHD track switching results in ~50s of silence. This suggests the issue is not merely "cache limits cause delays" — it seems more specific to TrueHD streams. Is there any initial assessment from the developers on whether this is a demuxer-level quirk specific to TrueHD (or Atmos) in MKV?

---

5. I continued testing with other videos and found the key issue point.

Working audio tracks:

• DTS-HD MA → Normal ✅
• DTS → Normal ✅
• AC3 → Normal ✅
• Other common encoding formats → Normal ✅

Problematic audio tracks:

• TrueHD → Not working ❌
• TrueHD Atmos → Not working ❌

output-No.sound.txt
output-Sound.txt
output-Sound2.txt

---

I carefully read all instruction and confirm that I did the following:

• I tested and confirmed that the issue exists with the latest release version or newer.
• I provided all required information including system and mpv version.
• I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
• I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
• I attached the full, untruncated log file.
• I attached the backtrace in the case of a crash.

[yosh-wang]

@kasper93 @llyyr, I hope you don't mind the ping. I'm not entirely sure if this is a bug or by design, so I was hoping one of you could kindly share your perspective when you have a moment.

---

Behavior Comparison

Cache Settings	TrueHD Track Switch Delay
Disabled (#demuxer-max-bytes and #demuxer-readahead-secs commented out)	~2 seconds
Enabled (demuxer-max-bytes=500MiB and demuxer-readahead-secs=60)	~40–50 seconds

So the issue is not that the cache causes a delay from zero — it's that it amplifies the delay from ~2s to ~50s, specifically for TrueHD/Atmos tracks.

---

Audio Format Test Results (under the same cache settings)

Status	Audio Formats
✅ Working fine	DTS-HD MA, DTS, AC3, other common formats
❌ Problematic	TrueHD, TrueHD Atmos

This suggests the issue is specific to TrueHD streams, rather than a general cache problem.

---

I've attached full logs and MediaInfo in the original description. If there's any additional debug info I can provide (e.g., more detailed traces or specific test samples), please let me know — I'm happy to help narrow it down further.

Much appreciated!