PMS Version 1.30.1.6562 - this update stopped my transcodes from working

Plex Media Server
85

Yeah It’s pretty crazy how inefficiently it works.

PMS does not even remember that VAAPI didn’t work during the very same transcoding session and keeps checking.

Running tail -f "Plex Media Server.log" | egrep 'API (nvenc|vaapi)' while starting transcodes is pretty interesting.

Jan 30, 2023 13:54:48.216 [0x7fffdb226b38] DEBUG - [Req#3c52e/Transcode] Codecs: hardware transcoding: testing API nvenc
Jan 30, 2023 13:54:48.511 [0x7fffdb226b38] DEBUG - [Req#3c52e/Transcode] Codecs: hardware transcoding: testing API vaapi
Jan 30, 2023 13:54:48.710 [0x7fffdb226b38] DEBUG - [Req#3c52e/Transcode] Codecs: hardware transcoding: testing API nvenc
Jan 30, 2023 13:54:48.995 [0x7fffdb226b38] DEBUG - [Req#3c52e/Transcode] Codecs: hardware transcoding: testing API vaapi
Jan 30, 2023 13:54:49.205 [0x7fffdb226b38] DEBUG - [Req#3c52e/Transcode] Codecs: hardware transcoding: testing API nvenc
Jan 30, 2023 13:54:49.502 [0x7fffdb226b38] DEBUG - [Req#3c52e/Transcode] Codecs: hardware transcoding: testing API vaapi
Jan 30, 2023 13:54:49.813 [0x7fffdb226b38] DEBUG - [Req#3c52e/Transcode] Codecs: hardware transcoding: testing API nvenc
Jan 30, 2023 13:54:50.388 [0x7fffdb226b38] DEBUG - [Req#3c52e/Transcode] Codecs: hardware transcoding: testing API vaapi
Jan 30, 2023 13:54:50.731 [0x7fffdb226b38] DEBUG - [Req#3c52e/Transcode] Codecs: hardware transcoding: testing API nvenc
Jan 30, 2023 13:54:51.192 [0x7fffdb226b38] DEBUG - [Req#3c52e/Transcode] Codecs: hardware transcoding: testing API vaapi
Jan 30, 2023 13:54:51.561 [0x7fffdb226b38] DEBUG - [Req#3c52e/Transcode] Codecs: hardware transcoding: testing API nvenc
Jan 30, 2023 13:54:51.992 [0x7fffdb226b38] DEBUG - [Req#3c52e/Transcode] Codecs: hardware transcoding: testing API vaapi

For most files I try transcoding, it checks 6 times for both VAAPI & NVENC before starting the transcoding process. It looks like Chrome handles this extra delay badly, and usually just fails playback, while some other devices handle this a bit better but with noticable delays when starting playback.

1 Like
86

It’s crazy!.. What I noticed with the logs is that PMS/Transcode will do this:

  1. Mess around testing VAAPI and NVENC to eventually pick where to go (my case NVENC)
  2. Transcode part of the file
  3. Test if the desired file would fit the required mbps
  4. If not, it’ll start again, and re-check VAAPI+NVENC
  5. Loops until it gets a good mbps
  6. Then look to start the stream/transcode for real

So knowing that it always wants to probe for VAAPI+NVENC (which we can agree is silly), seeing it re-testing (or retrying) this is plausible especially if its ‘test transcode’ (2) fails (4), as the estimated mbps are not close to what is needed. This is what my log said:

Jan 30, 2023 00:09:03.451 [0x7f3ecc96cb38] DEBUG - [Req#a688/Transcode] Streaming Resource: Calculated bandwidth of 4469kbps exceeds bandwidth limit. Changing decision parameters provided by client to fit bandwidth limit of 4000kbps

But I’m pretty sure I identified, in my log breakdown, that it’s doing even more cr@p/checks even when it has decided to transcode for real (6). That just seem beyond odd to me.

2 Likes
87

Hahaha yeah it looks like you are right, it’s even more crazy than I thought. Last time I knew ffmpeg supports specifying the bitrate for pretty much all codecs in existence, I wonder how they managed to mess this up so badly. It would be hard to find a more inefficient way to do this.

88

A quick look over the nvidia docs indicates that there should not be any issues specifying the video bitrate.

https://docs.nvidia.com/video-technologies/video-codec-sdk/ffmpeg-with-nvidia-gpu/

Almost all the example commands have -b:v *bitrate* argument for setting the video bitrate. So it should pretty much just be a case of calculating the audio+video bitrate and making it fit within the selected range.

I wonder what the hell exactly is going on in PMS land.

1 Like
89

I actually like the idea of PMS/Transcoder trying to work out what’s what as far as bandwidth goes. I don’t know enough about the subject, but it’s making sections of video (Transcode files) and just testing them to be sure they’re going to play at the right rate. If it decides it’s too much (or presumably too little?) it’ll make another adjustment.

I’m guessing it’s a form of VBR compression, so this variability means checking is a good idea? It doesn’t really answer the question as to why we’re getting these problems and why PMS/Transcode is checking VAAPI when it’s clearly identified and happy to play with NVENC?

I do wonder if there is some fault in the logic behind the whole transcode process. Could it be that if it restarts the transcode, because it’s decided that VBR/compression settings don’t meet requirements, that the 2nd attempt is causing PMS to not understand and it ends up wiping itself out? Just a thought :man_shrugging:

90

@Adarnof Just to clarify, when you asked me here to disable “hardware-accelerated video encoding”, I just turned off ALL h/w transcoding stuff and just test it. Again, it was fine, but not reading your own forum post (your thread), I test just unchecking “hardware-accelerated video encoding” and left the rest on.

It works… No real clue why, but it works without error, when using Chrome/browser. How strange is that!?

It’s certainly kicking my CPU a bit harder, but it’ll probably cope for a couple of transcodes. So I kinda want/need to encoding turned on. Sure enough, I turned it on again, and the browser/Chrome is back to messing up every other mbps change (works, doesn’t work, works, doesn’t work :joy:)

I’m just noting this, nothing more, it’s interesting that their is only one PID showing in nvidia-smi, so the decode and encode are run from the same PID? Again, just a mention for my own metal health :joy:

91

I would assume that both encoding and decoding use the same PID as they’re both being handled by Plex’s not-quite-ffmpeg. If you watch closely, you should see a second PID appear for a second or two before they both disappear when you request a quality change. At least that’s what I’m seeing.

No idea why disabling hardware-accelerated video encoding makes a difference - they were chasing a bug with video decoding earlier. It’s happening to me with different kernels, different drives, different PMS versions, different source files, different hardware… Either this bug has always existed and no-one had noticed it until now, or there’s something I’m missing. I haven’t changed my browser that I’m testing with, but I had someone else using Chrome on Windows replicate it for me, so I don’t think it’s a browser problem…

92

@Adarnof I have been getting playback issues when switching between transcoding and direct play on NVIDIA + Chrome for years. I have also tried everything, including completely different hardware. My friends running PMS also have the same issues with NVIDIA + Chrome since the beginning, on completely different hardware.

93

You’re right! A quick search has brought up two other threads from 2020 describing the exact behavior. So a known issue, but has never been addressed. Not a good omen.

EDIT: another thread, and another thread. This one suggests turning off ad blockers resolved it, but I checked and mine are already disabled both on local addresses and app.plex.tv…

3 Likes
94

I think by chasing the recent, but different, problem this has now come up and being noted.

I’ve had issues with my Android TV not wanting to play files, and I’m betting that it’s this issue I’ve noted in the PMS logs. Though I have not investigated yet (via Android TV).

Overall, we’re all chasing problems, some are obviously different (not linked), but it’s hard to get any proper traction. And finding this stuff in the logs and identifying them isn’t easy. Especially when you didn’t code, or the system, in the first place. I’ve spent hours pouring over this, but why aren’t these escalated?

I’m hoping and trusting that time can be put to this as I’ve clearly identified issues that need answers and fixes :man_shrugging:

2 Likes
95

Definitely not great that people have had the same (or similar) symptoms/problems. I posted an issue with the DVR once, took 12month to be looked at :cry:

It’s hard not to look at the logs and see clear problems, inconsistencies and inefficiency. E.g. constant re-checking vaapi when it’s already been identified as not being available; or having all this logging but seemingly no one though to log why a transcode was clearly happily stopped/killed.

What I find the most difficult is how the moderators struggle with the quantity of problems with easy way to prove, monitor, escalate and problems. And I am not, I repeat I’m not, blaming these staff/people. Its a company issue in how to control the flow of problems and seek meaningful conclusions… Reading, in other threads, about this same vaapi issue (inefficiency) being know by moderators is heartbreaking and you do read the odd nodd from them to say, this should be different.

3 Likes
96

@Minxster Yeah it really sucks, even issues which have clear signs in the logs and are easily reproduced, are not getting fixed for years. :tired_face:

3 Likes
97

So it seems I now have a fully upgraded PMS, to latest beta (1.31.3.6819-2ef591a4c_amd64.deb). Transcoding seems to be happy once more, though for reference I’m using Nvidia drivers 525.85.12 also.

I’ve not checked if anything has changed with VAAPI and how the transcoding wastes time trying this before NVENC - so I don’t know if this has been looked at. (To me, the process should be checked and changed to better accommodate Nvidia transcoding, e.g. why keep checking for VAAPI for every start of a transcode when clearly it’s not powered off and I’ve magically installed an Intel CPU with VAAPI :man_shrugging::wink:)

I’ve run a similar process (to the below) a good few times of the past months (different PMS versions), but PMS was clearly still not having any of it… Until today :rofl:

Anywho… Today I took another stab at this and wanted to see if the latest PMS beta was now working correctly. Here’s the process I followed :wink:

  • Powered off my VM (ESXi VM) for PMS (Ubuntu 20.04)
  • Made a snapshot
  • Powered on
  • Remove old Nvidia stuff
    -sudo apt-get remove --purge nvidia-* -y
    -sudo apt autoremove
  • Rebooted
  • Updating initramfs (take from @ChuckPa, from a different post)
    -update-initramfs -u
  • Rebooted
  • Installed the very latest Nvidia drivers
    -sudo apt install nvidia-driver-525-server nvidia-settings
  • Rebooted
  • Downloaded and installed the latest version of PMS (beta)
    -wget https://downloads.plex.tv/plex-media-server-new/1.31.3.6819-2ef591a4c/debian/plexmediaserver_1.31.3.6819-2ef591a4c_amd64.deb
    -dpkg -i plexmediaserver_1.31.3.6819-2ef591a4c_amd64.deb
    (N.B. I didn’t want to just do apt update/upgrade as there are lots of other updates needed, I just wanted to focus on PMS)
  • Let PMS sit for a good 15+ minutes
    (Even though the DB update took about 5mins, PMS was still really busy afterwards for around another 10mins)

And that’s about it. Once PMS had time to catch-up with itself, it seems ok. My transcodes to an external Roku box are working without issues, whereas before they would instantly fail.

I’ve not been keeping tabs on everything that has been going on since PMS 1.30.xxx came out. I tried to be a part of the “lets find the problem”, but as soon as I mention ESXi/VMs, you’re on a bit of a loosing streak. But, it seems that this dreaded transcode issue has been identified and fixed at some point, prior (or at) this latest PMS beta.

I’ll still need to be careful with future releases of PMS as we won’t know when all of the changes made to the beta will be in the public release. You’d expect it to be the “next version”, but this is not always the case… So unless I find a big problem with this beta, I’ll have to stick to this for a few public release… And then re-test all over again :man_shrugging::rofl:

I’m only posting all of this for completeness, and to show there is a least one working version of PMS just now :rofl::joy::rofl:… Also, to give a nod to the hard working forum admins/staff who’s work has paid off, and the Plex developers have made good progress. Lets hope the constant checking for VAAPI get looked at :wink::joy:

1 Like
98

Just as a follow-on from my previous post, I’ve made a few changes to my system and all is still good with my PMS :man_shrugging:

  • Re-enable virtual graphics card (I’m using ESXi and had this turned off during these problematic times)
  • apt update && apt upgrade -y (I did a full update yesterday and everything is still working well)

During the Ubuntu upgrade, PMS updated to the latest public version: 1.31.3.6868-28fc46b27, March 27, 2023

I just want to post back here (to anyone/everyone) and say that I believe 1.31.3.6868-28fc46b27, March 27, 2023 is transcoding well and I’ve not noticed any issues :wink::+1:

99

@Vicerak and I spent a good long time on the phone last night.

His stuff works now. It was all configuration problems.

The only issue remaining, for which I have the logs now, are LiveTV/DVR.

2 Likes
100

@ChuckPa I just wanted to post back to this thread in-case others were following along and wanted any update.

Things have certainly calmed down with the transcoding stuff, which is really good to see (mainly for you running around like a mad-man :rofl::joy::wink::+1:)

Just on TV/DVR stuff, I did see another post where people were seeing vertical lines? I skimmed over the thread and posted a like to my DVR post. Just-in-case it helped anyone there, or they wanted to follow along with what’s happening.

Again, for me, the DVR stuff is a bit of a back-seat thing, unless you’re all caught up on things. :+1::wink:

101

Yes. I really appreciate your help, Chuck. Without your help, things would not move.

I am still facing LiveTV issues. I haven’t tried anything with DVR.

102

Me? Mad? Shirley you jest! :rofl:

There are two things I do “OK” with Windows; 1) Wash and 2) Break. That’s it.

How one gets “vertical lines” in a horizontal scan video stream is beyond my understanding but – it’s “Windows” :man_shrugging:

I’ve seen no screenshots to confirm the phenominominom… :wink:

2 Likes
103

LOL :blush: I jest :wink::joy:

Sadly my youth started with a Sinclair QL, then a 286 with MS-DOS 3.2, so it was inevitable I’d be that “Windows” guy. But playing around with *nx based systems (tbh mainly Ubuntu) has been fun - fully headless since I started, though lots of Word docs storing all my precious keystrokes and screenshots :man_shrugging::man_facepalming::rofl:

… I did think the other thread was a little strange with the vertical lines, hence why I posted a link to mine (for any deinterlace problems people may have) and ran away :joy: I did see a screenshot from the person who started the thread… I honestly looked at it, squinted, and thought, that’s not an interlace thing :man_shrugging::astonished: But then again, I’m no expert :blush:

104

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.