New build, also includes github patch for the overlay to be working with metadata passthrough enabled:
mpv-dev-x86_64-v3-20221202-git-77e7f5d
This is just the file at a certain point in time which constitutes several commits in difference. Realistically we can’t actually look at it without it being constrained to only the differences specific to what you need.
Well, I´m not sure if I understand your reply correctly… (translation-wise) Do you mean the spdifenc.c file is useless without the diff? If that is the problem I can create a small GitHub repo with all the necessary changes needed if you like. Just let me know!
Also, did you receive my sample file? Have you been able to test the behavior on your end with the sample?
The spdifenc.c is almost entirely what it was in commit 827bdc8418 (See the file at this commit on FFmpeg’s github repo). There have been 6 commits since then.
The best way to get us (and really FFmpeg developers because you’d really want them) to look at it is to close that repo into your github account. Then make commits (or revert specific commits) to make the file what you want. Then you have constrained your changes to exactly what is necessary.
I have and shared it internally.
1 Like
This sounds doable! I will do so over the weekend! 
Recently I’ve noticed some sound drops for the first time since I’m using Plex HTPC with Dolby TrueHD content. I’m using PlexHTPC-1.30.1.3391-8c2e653b-x86_64 and I wanted to try the modified dll from mpv-dev-x86_64-v3-20221202-git-77e7f5d-old-truehd-spdifenc.zip. I’ve copied the mpv-2.dll to “C:\Program Files\Plex\Plex HTPC” but now I’m getting “An unknown player error occurred.” whenever I wanna start something. Can someone please point me to what I did wrong? I’ve attached my logs from the failed attempt. After replacing the mpv-2.dll with the original one from the Plex setup, everything works fine again.
Thanks!
Plex HTPC.log (351.0 KB)
You are probably missing the tls-ca-file line in your mpv.conf file. (Your log proves this) Instructions can be found here => HTPC Tips and Tricks - #3 by gbooker02
Thank you, it was indeed missing. But even after adding it, Plex still won’t start playback. I can see in the logfile, that the tls-ca-file path is set now (and the path is correct), but I still get an error.
Plex HTPC.log (351.7 KB)
This is very weird. Somehow FFmpeg is not able to resolve your server’s address.
ffmpeg: tcp: Failed to resolve hostname 192-168-178-4.33a5a84e513f43afa47653c41086db36.plex.direct: The name does not resolve for the supplied parameters
Does it work with the shipped mpv.dll? Can you please reinstall Plex HTPC (also please delete the plex htpc folder in the AppData dir) and try again? First with the shipped mpv.dll and then if working with my provided one.
@gbooker02
I hope this is fine now =>
If needed I will make necessary changes to the -upstream-patches tree…
I actually did all that already before posting my last log, deleted the Plex HTPC directory, reinstalled, tested with the original dll (worked fine), replaced with modified dll and I get the error.
Can you please try it again with a different cacert.pem file? The file can be downloaded here => https://curl.se/ca/cacert.pem
I’m still getting the same error with this cacert.pem:
Plex HTPC - modified.log (271.6 KB)
For comparison, here is the log after copying back the original dll and cacert.pem, where playback is working again:
Plex HTPC - original.log (587.1 KB)
Hm, can you try an older build of my mpv builds?
Another thing I found in your logs with the modified build is:
"allowDirectPlay": false,
"allowDirectStream": true
Do you have them enabled in the settings?
Maybe can you also try plex htpc with the modified mpv build on a different machine?
I’m really at a loss here. I’ve tried some older builds of the dll, all with the same result. I’ve installed Plex HTPC on another machine and there it works with the modified dll. So I did another fresh install of Plex HTPC on my HTPC, even deleted the %localappdata%\Plex HTPC folder, did a complete reinstall of the graphics driver but I’m still having the same problems.
As to “allowDirectPlay” and “allowDirectStream”, both are enabled in the GUI settings and I’m not changing any settings while switching between the modified and the original dll.
Plex’s MPV resolves plex.direct names without needing DNS servers. We do this because so many routers refuse to resolve DNS to RFC 1918 IP spaces in a naive attempt at DNS-rebinding protection. Likely there is some setting in your router denying resolving these DNS names.
2 Likes
This isn’t what I mean. You essentially did the same thing in Github.
Maybe this is clearer:
The file libavformat/spdifenc.c is identical at both of the commits identified by the red and green arrows. You effectively reverted 9 commits. Is it necessary to revert all 9 of those commits?
What I (and any other dev) is asking for is to start with the most recent version of the file and make the minimal changes necessary to that version to accomplish what you need. If I were to guess you intend to revert the commits on Feb 20, 2020 but that isn’t clear from the information you’ve provided thus far. If that is really the case, then you should use git revert on each of those commits (in reverse order) and push that to a branch.
1 Like
Well, I guess only two truehd-related commits made by anssih (Feb 20, 2020) need to be reverted. The one from anssih avformat/spdifenc: make hd_buf an array and the one from mkver avformat/spdifenc: Fix leak upon error I´m not sure. The one from mkver makes changes to the array function added by anssih. In my current spdifenc file I have reverted those commits but I will test them added back. Maybe those commits don’t need to be reverted. The other 5 commits I have in my file.
git revert actually was the function I was looking for. It is not in the web version of github that I had only access to. If testing is successful I will set up github cli again and revert the necessary commits.
Build for testing (also includes mpv debug and mpv cli):
https://drive.google.com/file/d/1ePYN4mMQi14zzVOA0A5sQtqevbGMak10/view?usp=share_link
Equals => https://github.com/mitzsch/FFmpeg/tree/old-truehd-spdifenc-logic-upstream-patches-2
(essentially only commit avformat/spdifenc: fix handling of large TrueHD frames · FFmpeg/FFmpeg@36e156b · GitHub and avformat/spdifenc: fix TrueHD streams over 48kHz · FFmpeg/FFmpeg@56df829 · GitHub
are reverted)
Normal modified build:
https://drive.google.com/file/d/1zeXia8O_6p2RTukDupCFtvEvWbd86TNp/view?usp=share_link
Is there an official commit for this patch? Maybe (also if wanted) I can try to patch my build with this one.
Please try this one on the machine you are seeing the problem with =>
- open a terminal and run this
nslookup 192-168-178-4.33a5a84e513f43afa47653c41086db36.plex.direct - it should return 192.168.178.4 if not then there is something wrong.
1 Like
I found a reproducible sound bug in my Doctor Strange 4K rip that Mitzsch’s work fixes. Upon starting the movie from scratch without his fix, the sound always drops for a split second before the first cymbal crash of the Marvel theme; my Plex log contains the Unusual frame timing warning discussed in the thread already. Pressing the back arrow and playing through does not produce the glitch again. Installing the updated mpv-2.dll file eliminates the sound glitch and the corresponding log entry.
Sadly, I am still encountering similar sound glitches elsewhere even with the modified mpv that do not show the Unusual frame timing error in the log and do not reproduce easily; they seem to happen at random. I don’t know if this is relevant, and I jumped in and out of Plex a number of times reproducing/testing the Doctor Strange error such that I lost the log, but I saw something to the effect of “failing to fallback to a secure connection” as one of the final entries of the log before I closed the application after experiencing one of these random audio glitches. Would that create sound glitches outside of the TrueHD passthrough issues described in this thread or is that a coincidence? I can try to look for it again next time and upload a log.
