I had llvm issues with Endeavour OS Arch Linux. I had to manually download a related package called LLD to get it to work. But I kept having weird package issues. So although @Mitzsch recommends Arch Linux, make sure it’s actually Arch Linux and not a Linux distro based on Arch.
Thanks for the info. Yes, I’ve used Arch Linux before as well as pretty much all other major Linux distros. I was a little amazed that building this project under a similar environment yielded different results. Having more explicate build options would result in a larger compatibility rather than relying on precedence of the OS. At least the fix is a simple one linker parameter addition.
I’ll spin up an instance of Arch Linux and give that a try.
[scott@archlinux ~]$ neofetch
-` scott@archlinux
.o+` ---------------
`ooo/ OS: Arch Linux x86_64
`+oooo: Host: KVM/QEMU (Standard PC (Q35 + ICH9, 2009) pc-q35-7.2)
`+oooooo: Kernel: 6.8.9-arch1-2
-+oooooo+: Uptime: 1 hour, 23 mins
`/:-:++oooo+: Packages: 246 (pacman)
`/++++/+++++++: Shell: bash 5.2.26
`/++++++++++++++: Resolution: 1024x768
`/+++ooooooooooooo/` Terminal: /dev/pts/2
./ooosssso++osssssso+` CPU: AMD Ryzen 7 5700X (8) @ 3.393GHz
.oossssso-````/ossssss+` GPU: 00:01.0 Red Hat, Inc. QXL paravirtual graphic card
-osssssso. :ssssssso. Memory: 1949MiB / 7939MiB
:osssssss/ osssso+++.
/ossssssss/ +ssssooo/-
`/ossssso+/:- -:/+osssso+-
`+sso+:-` `.-/+oso:
`++:. `-/+/
.` `/
Just built llvm, rustup, llvm-clang and mpv-ntruehd without any errors using Arch Linux distro.
Good times and thanks.
1 Like
Just a quick follow up and FYI. If you are compiling this project using GCC than you should have at least 2 GB per core or you will run out of memory during compilation (unless you have a large swap drive). The Clang build is able to get away with only 1 GB per core.
Follow up. The building repository works very well.
I will initiate a new build every 5 five days or so - I think that’s enough.
I will probably not publish old-truehd builds - or to be precise I need to find a way not to overwrite the previous build… If someone wants an old-truehd build send me a PM… (I compile them regularly as I’m only using them)
2 Likes
Thanks for keeping these updated! It would be good to have access to a couple previous builds in case anything breaks in the latest.
I just realized that if I install your build and later run updater.bat it doesn’t download your latest build, but instead downloads and overwrites your build with zhongfly’s latest build. I noticed this after updating about an hour ago and starting to experience some TrueHD passthrough issues. Looks like /installer/updater.ps1 is pointing to zhongfly’s github repo.
yup, exactly, that is to be expected to be honest. I have not changed those things due to time limitations. The updater.bat/.ps1 is pulled from a different repo that I need to fork and modify … Again due to time limitations, I have not done this yet. Will come. So in the meantime please download it from the github page.
Ok will do.
New releases will now feature the corrected updater.ps1
If you don’t want to download a new package featuring this, just download the file => mpv-packaging/mpv-root/installer/updater.ps1 at master · mitzsch/mpv-packaging · GitHub
and put it in the "*mpv\installer" folder. (overwrite the old one…)
1 Like
I’m not sure if I’m the only one seeing this, but Dolby ATMOS audio, at least in MP4’s and M2TS transport streams appears to be broken with your recent releases.
Here are some details:
Works properly with 64bit-v3/mpv-x86_64-v3-20240609-git-d2bd77a
Note this is not your build, it’s an un-modified release I just downloaded.
D:\Apps\mpv_default2>mpv.com --no-config --log-file=D:\libplacebo_trc2.txt “V:\Demo\2K\Pan_2.40.m2ts”
(+) Video --vid=1 (h264 1920x1080 24.000fps)
(+) Audio --aid=1 (truehd 8ch 48000Hz)
Audio --aid=2 (ac3 6ch 48000Hz)
Audio --aid=3 (eac3 8ch 48000Hz)
AO: [wasapi] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 yuv420p
AV: 00:00:20 / 00:01:45 (20%) A-V: 0.000 Cache: 31s/150MB
Exiting… (Quit)
The log file:
libplacebo_trc2.txt (92.5 KB)
Fails with your 64bit-v3/mpv-x86_64-v3-20240610-git-641cdab and, as far as I can tell all recent releases. I haven’t updated since late last year, so I really don’t know when this issue actually started. On your releases from last year I wasn’t seeing this.
D:\Apps\mpv_default>mpv.com --no-config --log-file=D:\libplacebo_trc1.txt “V:\Demo\2K\Pan_2.40.m2ts”
Video --vid=1 (h264 1920x1080 24 fps)
Audio --aid=1 (truehd 8 ch 48 kHz)
Audio --aid=2 (ac3 6 ch 48 kHz)
Audio --aid=3 (eac3 8 ch 48 kHz
Log Name: Application
Source: Application Error
Date: 6/10/2024 1:02:24 PM
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: HDPC3
Description:
Faulting application name: mpv.exe, version: 2.0.0.0, time stamp: 0x6666884f
Faulting module name: AcLayers.DLL, version: 10.0.19041.3636, time stamp: 0x2ca84e8d
Exception code: 0xc0000005
Fault offset: 0x0000000000009ec7
Faulting process id: 0x10c8
Faulting application start time: 0x01dabb6058c7ddf3
Faulting application path: D:\Apps\mpv_default\mpv.exe
Faulting module path: C:\WINDOWS\SYSTEM32\AcLayers.DLL
Report Id: 2ca2b338-c60b-4ab2-9b46-73fb8bfc4b59
Faulting package full name:
Faulting package-relative application ID:
Event Xml:
1000
0
2
100
0
0x80000000000000
22286
Application
HDPC3
mpv.exe
2.0.0.0
6666884f
AcLayers.DLL
10.0.19041.3636
2ca84e8d
c0000005
0000000000009ec7
10c8
01dabb6058c7ddf3
D:\Apps\mpv_default\mpv.exe
C:\WINDOWS\SYSTEM32\AcLayers.DLL
2ca2b338-c60b-4ab2-9b46-73fb8bfc4b59
The log file:
libplacebo_trc1.txt (14.2 KB)
Not sure what’s happening, it took me a while to isolate the the file having an ATMOS audio track.
Can you please test older builds that are still downloadable from the Github page?
I will need to check on my end but it seems its not passthrough releated as the issue also occurs with -no-config. (So the ffmpeg changes aren‘t the problem - most likely)
No, they’re not. As a matter of fact. I’m not even sure it’s an MPV issue at all.
Note I am on a Win 10 system, which also has JRiver and Zoomplayer installed.
Ok, you probably won’t believe this, simply moving all the exact same files from the sub directory (mpv_default) that they have been in for several years now to a new sub directory mpv_defaut2) cleared the problem.
Based on where the error is happening, it looks a lot like a D3Dcompiler issue. Possibly, something in the registry somewhere is referencing mpv_default. I don’t know, it’s wierd.
So your latest release works fine.
Please excuse the false alarm.
1 Like
I switched to once a week for builds - I hope that’s fine.
Any other feedback? 
2 Likes
There isn’t much happening with MPV and even less so with FFMPEG which is strange because FFMPEG used to get updated almost daily. So this makes sense. The changes are mainly minor bug fixes and tidy up. But if something major does occur I wouldn’t mind an off schedule update
Hi @Mitzsch ,
Plex Desktop Version 1.98.2.208-0cf517e0 it seems d cycle deband does not work anymore with mitzsch/mpv-winbuild 2024-08-05 18:50 version for me! But with mitzsch/mpv-winbuild 2024-07-28 07:32 deband cycle works fine! I would appreciate if you could please fix this.
Must be a regression on the mpv code side. I haven´t touched it. Can you please also test with plain mpv?
In the meantime, I will generate another build.
1 Like
Thank you @Mitzsch it seems that with mitzsch/mpv-winbuild 2024-08-08 12:50 the problem is solved. 
1 Like
#Edit:
Rephrased the first post so it reflects the changes and fixes better.
Would you mind running the non-v3 compile for the latest build?
