The logs showed two discontinuities in the audio timings but both were very large and obviously the result of a seek (both times the preceding logs lines talk about MPV seeking)
If you play the same file from the beginning, does it drop again? If you do hear a drop in the future, it’s very helpful to note the wall clock time (and make sure your computer’s clock is accurate). It helps to narrow down which section of the logs should be examined.
Part of the reason why I do the seek is to both confirm I actually heard a glitch, and also to make a log entry that timestamps where it happened. The recording that I uploaded was real time of my viewing, so that last seek in the log occurred ~5 seconds after the audio drop. I will admit that I don’t know really how to read these logs, but similar to my prior experiences, it doesn’t look like anything out of the ordinary is presenting in the log, and that is very typical.
I have not ever rewatched a TV episode from the beginning to see if it skips in the same place, but I’m willing to try that. The Doctor Strange clip I uploaded earlier ALWAYS skipped at around the 9 second mark, just before the first cymbal crash of the Marvel fanfare using the vanilla Plex mpv. Both Mitzsch’s rollbacks as well as your fix eliminated that issue, so there may be something to that. I’ll get back to you. I have already eliminated re-starting the player then seeking to just before the drop point being able to recreate the issue, so now I’ll play through the episode from scratch and see what happens.
I restarted the episode from the beginning and did not get any audio drops… Here’s the log regardless.
Completely uneducated question, but anecdotally, it did seem like the audio drop I experienced most recently was a shorter gap than the usual drops I would experience previously, maybe the difference between 1/10th of a second vs 1/4th of a second. If adding some padding to this most recent fix greatly reduced the frequency of the issue occurring and possibly made the blip shorter, could adding more padding help or would that start to break things?
2 more logs attached:
Build (mpv-dev-x86_64-v3-20230114-git-6cdce9e-old-truehd-spdifenc+commits.zip)
Film: Star Trek 2009, 4K HDR. (seems to have audio issues consistently in the first few minutes)
In both logs this is a fresh open of plex htpc, select film, play from begging and wait. Next input was to exit the film.
Log1:
Started playing: 23:07:19
Glitch 1: 23:08:28
Glitch 2: 23:09:16
Stopped: 23:09:29
Log2:
Started playing: 23:16:01
Glitch 1: 23:18:02
Glitch 2: 23:18:24
Glitch 3: 23:21:26
Stopped: 23:21:37
The only thing i can see in the logs at any of the glitch times is one instance of:
Feb 23, 2023 23:08:28.025 [5264] WARN - [MPVEngine/mpv] ao/wasapi: Under-run: Device delay: -14.4 us
I have been testing further this afternoon and have found that the audio issues I get consistently with Star Trek at the start of the film go away if I turn hardware acceleration off.
I have tested this multiple times now on and off, and with it off i can play 10 minutes of the film with no issue and with it on I get issues in the first couple of minutes.
It is still only a few films I am getting any issues with at all with the build above.
FF and RW is slower with hardware acceleration off.
I may watch Start Trek tomorrow fully and see if HW Acceleration off works for the whole film.
The padding is the amount that the codec requests exist between units of compressed audio. What I changed was to increase the allowed padding from 1/2 of a MAT frame to 2 MAT frames. Whenever the requested amount exceeds this allowed value, it is logged and the logs lines that showed up in your case were unreasonably large to actually pad out as and so it assumes a stream restart (a seek) which is correct in these two cases.
I do not want to pull on this string too hard because you might as well be talking to a toddler for all I understand about this. That being said, my question/logic was this:
The only time I was ever able to consistently get an audio error AND an unusual frame time log entry was that clip of Doctor Strange I uploaded earlier. Most of the time, I would get an audio error that sounded exactly the same as the unusual frame time error, but without any log entries.
Now, both Mitzch’s reversions and your patch fixed the Doctor Strange issue. What your fix did that Mitzch’s did not is also dramatically decrease the frequency of audio drops that I’m experiencing that do not leave a log entry. I am wondering if the error I caught on camera earlier with the Dragon Ball clip could still be addressed by taking your style of tweak a little further.
I know you mentioned that you chose 2 MAT frames because other programs used that value. Understanding that I don’t know what a MAT frame is and I’m mainly asking to see if this helps with guess and check, what happens if you do 2.5 MAT frames? 3 MAT frames? If increasing from 1/2 MAT frames to 2 MAT frames eliminated a lot of unlogged drops but not all of them, is there value in exploring whether more MAT frame padding completely eliminates these unlogged audio drops or would we start to break other things going higher than 2?
Well, I just thought the same. If I understand the (corrected) code correctly the “multiply by 2” instead of “dividing by two” “expression” is this one here - defining how many MAT frames are now allowed.
- /* sanity check */
- if (padding_remaining < 0 || padding_remaining >= MAT_FRAME_SIZE / 2) {
- avpriv_request_sample(s, "Unusual frame timing: %"PRIu16" => %"PRIu16", %d samples/frame",
+ /* detect discontinuity */
+ if (padding_remaining < 0 || padding_remaining >= MAT_FRAME_SIZE * 2) {
+ avpriv_request_sample(s, "Unusual frame timing: %"PRIu16" => %"PRIu16", %d samples/frame; assuming seek",
I just tested this with “*4” but on my end, it has not changed anything, still the same dropouts. (If needed I can also provide this build).
Is there anything else that could be tried? Anything else that prevents these (presumably) buffer underruns/underflows?
Is it worth a shot to try the value 4 instead of 3 here?
- uint8_t *hd_buf[2]; ///< allocated buffers to concatenate hd audio frames
+ uint8_t *hd_buf[3]; ///< allocated buffers to concatenate hd audio frames
If it would make a difference, then you would have log entries at the time where it would. The only associated log entries I saw in your logs were immediately after a seek where padding out these multiple frames is definitively not the right thing to do but instead reset and start anew (which is what it does do in this case).
There’s more to have to change than that if you want more frame. But again, you need to be having it log the unusual frame timing message at the time for increasing the number of empty MAT frames allowed to make any difference.
Can you think of anything else going on under the hood that would explain why your change decreased the frequency of many (but not all) drop outs? Especially unlogged drop outs?
For context, I have been watching this show through Plex since mid-November of last year when I first noticed the issue. Since then, I have watched ~300 episodes and have tried a large number of troubleshooting steps both in Windows and Plex to correct the error. I only started keeping a log of the troubleshooting combinations fairly recently, but for months, I couldn’t go more than handful of episodes without an issue, sometimes multiple issues per episode. My logs always looked clean at the time stamps where the issue took place like the one I posted. After using your patch, I went 26 episodes before encountering the issue, and have since gone another 8 and counting since the issue I had. Something you did moved the ball in the right direction, I just don’t know what lol.
Well, actually, in my case those dropouts occur shortly after the line has been printed (due to a seek or the stitched together/ seamless branching parts) Maybe increasing the allowed MAT frames would fix it in this case (and in other cases)?
What was the log line? If the discontinuity is too large then adding more empty MAT frames is not going to be a solution.
Edit: I feel really silly to say this, but when Plex updated last night, it updated mpv-2.dll with it. I was experiencing issues because I was using the vanilla mpv. I’ll leave the post in case that method of finding a repeatable error is helpful to further debugging.
I went another 21 episodes without issue and encountered another glitch. Same as before, nothing in the log looks out of the ordinary (Plex.5.Log in this case, within 5ish seconds of the seek at the end). However, I did discover something interesting when reviewing that may help us here (Plex.Log).
Generally when I encounter this glitch, I can seek back 10 seconds and replay the same section without issue, which was still the case here. Because I was uncertain if I heard an error or a false positive due to the raucous sound effects of the scene, I replayed the scene 15-20 times in quick succession and was able to get the exact same glitch to happen! I included a live recording of what that presents as.
Now, I recognize that what I did to replicate the error is not a normal use case, but the sound dropped out at exactly the same place and in exactly the same manner as it did when it dropped in a live viewing. It does have unusual frame timing log entries seeking excessively like I did, for all that matters or doesn’t matter. For science, I booted up VLC 3.0.4 and did the same stress test over and over and over but could never get the audio to drop out like I can for Plex. However, I WAS able to use this stress test in Plex to replicate a different error I’d experienced before at a time stamp I knew off the top of my head. Why is VLC able to seek to this spot repeatedly without breaking, while mpv/Plex cannot?
I don’t know what to make of that. I can upload the mkv of the actual episode if that would help.
So, reporting back…
Billybobm1’s experience with hardware acceleration led me to try that combination. After realizing that Plex’s auto-update feature had overwritten gbooker02’s fix, I swapped the fix back in and kept watching/tallying from where I left off. I just finished my TV series and logged 41 episodes, approximately 14.25 hours of content, without issue.
I do not know if the next show I watch will have a TrueHD audio track, but I am probably willing to declare gbooker02’s fix+disabling hardware acceleration as solving the issues that I was experiencing, especially comparing and contrasting with how frequently the issues came back for the 7 or so episodes it took me to realize the update had replaced the vanilla mpv. Night and day viewing experience.
Really wanna thank gbooker02 and I hope anyone else experiencing the same issue stumbles on to this thread.
As an update, I have been running the latest fix since it was posted with no issues to report. Thanks for all the hard work!
Is it possible one of the recent Plex HTPC releases has caused more issues?
I posted in post #92 that I started experiencing more drop outs when using the same build which had worked for me for many films.
I haven’t watched much in the last week but last night I watched a 4K HDR series with Dolby Digital + sound track and that too had drop outs! This was with the same fix mentioned in post #92.
Turning Hardware Decoding off fixed this again.
(same fix as mentioned in post #105
Dolby TrueHD passthrough - modified mpv build - #105 by Billybobm1)
Are we able to get previous builds of Plex HTPC to try?
Just tried Edge of Tomorrow which has previously ran through completely without issue and within the first few mins im getting small dropouts. (with hardware decoding on).
I would really like to try a version of Plex HTPC from a few months ago to see if thats the same.
The relevant code in HTPC (really FFmpeg) hasn’t changed in over a year. However, I am in the process of merging my patch from above into our FFmpeg so it should be in a future version soon.
Is there any info to what Hardware Decoding is doing?
I have no audio dropouts with this disabled.
Would also like to know what impact Hardware decoding has on all this…
Another question to all.
Would you still want me to provide patched mpv builds with the old trueHD logic from time to time?
update:
With Hardware decoding off and the latest build provided I have not experienced any further issues.
Will this fix make it into a release?
