Server Version#:1.59.1.3398-dab42972
Player Version#:1.30.0.6486
I have a library of blu-ray rips created using MakeMKV. I have tested playing the files back through both Plex For Windows and Plex HTPC. Both have a playback issue with DirectPlay Dolby TrueHD passthrough.
At random intervals, audio will either have a microstutter where no audio plays for a brief moment, or audio will garble and distort. When I skip back, the errors never duplicate.
I have an i7 10700k CPU, 3080 GPU. The files are stored via USB 3.0 10TB hard drives. I am connected via HDMI to a Yamaha RX-A8A receiver. The files play flawlessly via VLC. I have gone through extensive troubleshooting to isolate the issue to Plex including re-ripping files.
I have tried a number of different settings combinations, including toggling hardware decoding, various Video Playback Quality settings, Refresh Rate Skipping, DirectStream, and various transcoder settings that should not apply in this case. I have also deleted codecs and reinstalled the software. The issues seems similar to an old topic that was never resolved, to my understanding.
Any tips? Or can the issue be investigated for a future update?
When you are only seeing this behavior with truehd tracks then this sounds like you are very likely suffering from the same issue described here => Dolby TrueHD passthrough - modified mpv build
Maybe you can try such a modified mpv.dll and test again?
VLC does not show this issue because it uses a very outdated version of ffmpeg (last time i tested vlc), before changes were made to the truehd passthrough logic.
I’ve been using your modified mpv-2.dll files and seen some hitching eliminated by your build, but not all of it. Some hitching leaves a log entry that discusses Unusual frame timings, and some do not. The hitching that leaves a log was fixed by your modified mpv, the ones that do not persist.
I noticed that your thread initially started with audio completely failing after seeking within tracks, which is an issue I have not encountered. These are more random, and do not reproduce when the same section plays twice. Do you ever get errors like that?
Can you think of any way I could capture why the audio is goofing, either with different log settings, etc?
And there is the problem. When there are no log entries made anything could be the reason but I guess mpv/ Plex HTPC is not at its fault (it would have written something to the log.) But somehow it is strange that you also get dropouts with my build and not with VLC. Both use the same ffmpeg logic. Have you tried playing your files with the mpv cli application? (upstream or my testing build - the last one provided also features the mpv.exe/com version)
Luckily not, on some earlier versions of linux I was getting random audio dropouts but this was like three or four years ago and was due to bad drivers.
What you can try is creating an mpv log that is written along the Plex HTPC one.
Add log-file="C:\path\to\mpv.txt" to your mpv.conf and run Plex HTPC until you “see” the issue again. Hopefully, something is printed there.
Do note that in certain hardware, NVIDIA GPUs/drivers will drop audio under certain conditions. It often presents randomly but some content produces it more than others. I have an episode which has periodic black frames with white text for about a second several times during the intro (showing actor names). The audio would drop several times in this sequence but not always in the same set of times. It also did it with PCM audio as well as passthrough.
The solution was to change the NVIDIA control panel setting to set the power level to maximum performance instead of the default of optimal (names may be slightly off as I’m recalling this from memory).
I appreciate the tips on the Nvidia Control Panel settings. I already had it set to prefer maximum performance.
I may have found the issue through different troubleshooting. I have a number of video games that use Dolby Atmos, so I have Dolby Access installed to enable spatial sound for Windows. I turned my Windows sound setting to normal 7.1 to see if that would fix it; while it did go much longer than normal before encountering the sound drop again (~3 hours vs ~20 minutes), the main breakthrough with that settings switch is that Plex decided to log something when I encountered the audio glitch this time:
Dec 31, 2022 14:51:10.249 [10208] ERROR - [Web] Did not move header “accept” to query string. This can result in an unnecessary OPTIONS preflight request.
Dec 31, 2022 14:51:10.250 [10208] DEBUG - Enabling OS screensaver
Dec 31, 2022 14:51:16.914 [5788] DEBUG - [MPVEngine/mpv] ao/wasapi: OnPropertyValueChanged triggered on device {0.0.0.00000000}.{7d783d68-518c-4ffb-9347-65a7b1ec2ab6}
Dec 31, 2022 14:51:16.914 [5788] DEBUG - [MPVEngine/mpv] ao/wasapi: Changed property: {1e94c58f-3e40-4ddb-b10c-a86d8b870a31},2
I have a decently aggressive screensaver running in Windows because I’m paranoid about OLED burn in for my home theater setup. I know wasapi is how Windows does passthrough audio, so while I don’t understand exactly what those log entries mean, I disabled my screensaver and got through 2 full movies without a single audio error. One was a TrueHD Atmos file and one was a DTS-HD MA 5.1 file. I also believe my spatial audio setting was activated for the movies being played, though I don’t remember exactly when I switched it back on.
I will give it a few more days to see if the screensaver messing with the exclusive audio session was the culprit. Depending on how Plex or MPV address OS screensavers, that may be the difference for why VLC has not had the same problem.
