HBO conversions unplayable on Plex

I’ve got an issue with converting recordings from HBO, where most of my Plex clients refuse to play the content. I dug through logs and I’m not coming up with much, but maybe I’m just not seeing anything. I would normally just do a MP4 Unprocessed, but thought maybe converting would help so I changed to MP4 High Quality in the hopes that the transcode would sort something out.

One thing I’m noticing on the Unprocessed is that the resulting file has (according to MediaInfo) some pretty wacky properties: avg framerate of 28.893fps (ok) but a min/max of 9.99/90,000? Avg bitrate of 8.324kbps, but a max bitrate of 80.0mbps? I can see why Plex might spazz out, but while the MP4 High Quality has very normal properties (constant 29.97fps, avg 9,652kbps and max 16,000mbps bitrate) it’s also not happy with the playback either.
MP4-High_Last Week Tonight With John Oliver_HBOHD_2024_05_12_22_55_00.wtv-No-Commercial Convert-2024-05-13T16-45-31.zip (449.4 KB)
MP4-Unprocessed_Last Week Tonight With John Oliver_HBOHD_2024_05_12_22_55_00.wtv-No-Commercial Convert-2024-05-13T01-16-33.zip (54.5 KB)

I’m seeing loads of errors in the source video, this could by why even after converting Plex may be having issues with the file. If I were to guess you’ll see stuttering and skipping while playing back.

2024-05-13T16:46:26 MCEBuddy.AppWrapper.FFmpegMediaInfo → [mpeg2video @ 0000026c384d02c0] end mismatch left=25 35 at 0 68
2024-05-13T16:46:26 MCEBuddy.AppWrapper.FFmpegMediaInfo → [mpeg2video @ 0000026c384d02c0] Warning MVs not available
2024-05-13T16:46:26 MCEBuddy.AppWrapper.FFmpegMediaInfo → [mpeg2video @ 0000026c384d02c0] concealing 120 DC, 120 AC, 120 MV errors in B frame
2024-05-13T16:46:26 MCEBuddy.AppWrapper.FFmpegMediaInfo → [vist#0:2/mpeg2video @ 0000026c3801ca00] corrupt decoded frame
2024-05-13T16:46:26 MCEBuddy.AppWrapper.FFmpegMediaInfo → [mpeg2video @ 0000026c384d02c0] end mismatch left=23 7C at 0 68

2024-05-13T16:46:27 MCEBuddy.AppWrapper.FFmpegMediaInfo → [mpeg2video @ 0000026c384d02c0] concealing 120 DC, 120 AC, 120 MV errors in P frame
2024-05-13T16:46:27 MCEBuddy.AppWrapper.FFmpegMediaInfo → [mpeg2video @ 0000026c384d02c0] end mismatch left=28 4 at 0 68
2024-05-13T16:46:27 MCEBuddy.AppWrapper.FFmpegMediaInfo → [mpeg2video @ 0000026c384d02c0] Warning MVs not available
2024-05-13T16:46:27 MCEBuddy.AppWrapper.FFmpegMediaInfo → [mpeg2video @ 0000026c384d02c0] concealing 120 DC, 120 AC, 120 MV errors in I frame
2024-05-13T16:46:27 MCEBuddy.AppWrapper.FFmpegMediaInfo → [vist#0:2/mpeg2video @ 0000026c3801ca00] corrupt decoded frame
2024-05-13T16:46:27 MCEBuddy.AppWrapper.FFmpegMediaInfo → Last message repeated 1 times

This is usually caused by a bad OTA signal or an issue with the recording card drivers.

I noticed you’re using WTV, if the source WTV is playing okay in WMC then you could try this option, add this to the profile (in your profiles.conf file) you’re using and see if it helps. This will use the native WTV DirectShow filters to decode the file which could help recover any errors if possible:

ForceWTVStreamsRemuxing=true

If that doesn’t help then you could try an alternative option in the profile to decode the WTV files by using:

UseWTVRemuxsupp=true

Playback in Plex was… not great. At best it would stutter really, really bad (ie play for ~0.5s, pause for 2s, then repeat). Oddly enough playback on my iPhone worked fine… but that could be something client-specific that it’s doing because Apple. I verified playback is fine on the HTPC it was recorded on, so that’s a plus.

I don’t think signal is an issue, I’ve got no errors on the tuner or other stations (HDHR Prime), but it wouldn’t be the first time that my cableco has had a goofed up HBO stream… I don’t remember what it was, but years ago when playing back on a Media Center Extender it would flip out because of a framerate issue. I suspect it was less a matter of maleficence, and more a matter of them just being bad at what they do. It’s also not likely to be anything else on my end… the everything is being recorded on a Win8.1 HTPC which obviously isn’t getting updates.

At any rate, I added the ForceWTVStreamsRemuxing=true option on the no-convert profile, and while it seemed to play back without issue at first, it fell to pieces pretty fast. Same goes with UseWTVRemuxsupp=true.

I tried ForceWTVStreamsRemuxing=true on the MP4 High and it seems like it’s alright! I’ll need to check my Smart-TV to see what it’s doing, but that seemed to have squared it away.

While waiting for the encodes to finish, I did some Googling around, and remembered this blast from the past:
https://answers.microsoft.com/en-us/windows/forum/windows_7-pictures/extreme-stutter-and-sometimes-flicker-with-hbomax/652f8120-f8bb-474b-ad77-ab81535233fb?msgId=c37ec098-ad01-464b-879f-98f16b033db9&page=1

Since I had the HTPC fired up already (confirming the original video works) I fired up the debug and sure enough the framerate is spazzing out between the two framerates (it’s too fast for me to read). So it’s definitely a funky signal from the mothership. Watching things directly on the HTPC is fine (though it’s obviously not preferred) or streaming is also good… I’m curious what made this pop up all of a sudden after years of working fine.

Attached are logs, if they’re of any interest… definitely seems like a garbage-in/garbage-out sort of thing. I suspect I’m in the minority of users who might be affected by this nonsense, but who knows.
Force-Passthrough_Last Week Tonight With John Oliver_HBOHD_2024_05_12_22_55_00.wtv-HBO-No Convert-2024-05-14T23-05-58.zip (46.9 KB)
Force-MP4-High_Last Week Tonight With John Oliver_HBOHD_2024_05_12_22_55_00.wtv-HBO-No Convert-2024-05-14T23-28-15.zip (439.7 KB)
Use-Passthrough_Last Week Tonight With John Oliver_HBOHD_2024_05_12_22_55_00.wtv-HBO-No Convert-2024-05-14T23-20-47.zip (45.4 KB)

Looking at your logs, it looks like you’re using Nvidia hardware encoding. I suspect that the card is unable to handle the frame rate / timestamp issues. Try turning off the hardware acceleration and see if that helps smooth things out.

Ok so I rewatched one of the “successfully” converted shows and found that while the video wasn’t going bananas the audio sync was off when using ForceWTVStreamsRemuxing=true… like, 5s off.

I tried UseWTVRemuxsupp=true with GPU encode, and while it seemed to work, it also became unstable fairly quickly. Switching to CPU-only has a file that’s working fine though, so that seems to be the “fix” to the issue.

USE-GPU_Last Week Tonight With John Oliver_HBOHD_2024_05_12_22_55_00.wtv-HBO-No Convert-2024-05-17T13-12-11.zip (441.1 KB)
USE-CPU_Last Week Tonight With John Oliver_HBOHD_2024_05_12_22_55_00.wtv-HBO-No Convert-2024-05-17T11-47-20.zip (374.3 KB)

GPU encoders are generally very sensitive to errors in the videos and aren’t good at compensating for it. They’re basically designed to do one thing and do it fast. Software encoders (CPU) are far more flexible and forgiving, but at the expense of speed.