No hardware decode after RDP connection

Plex Media Server
1

Server Version#: 1.20.1.3252
Player Version#: 7.6

I’m running Plex Media Server on a Windows 10 machine. I have hardware acceleration and hardware-accelerated video encoding enabled. It all works fine with PMS using hardware acceleration for video decoding and encoding until I connect to the machine using Windows Remote Desktop. From that point on, even after I have disconnected the RDP session, Plex does not use hardware acceleration for video decoding. PMS will only use hardware acceleration for encoding. When I reboot the machine it will then use hardware acceleration for decode and encode until after the next RDP session again.

I have seen many posts regarding hardware acceleration causing crashes or not working at all after RDP sessions. However I couldn’t find one with this particular type of issue. Does anyone know how to fix this or work around it successfully?

Thank you!

2

Try using TeamViewer, LogMeIn, VNC or other similar tools. From what limited understanding I have, switching from a console session to a terminal services session is what breaks this. The above tools leave you in console while still letting you remotely interact with your system.

2 Likes
3

Thanks @Uh_Oh. TeamViewer avoids the issue but for some reason TeamViewer thinks I’m using it for commercial use and is limiting my connection time and number of connections within a certain time. I’ll take a look at LogMeIn but it looks like they only offer a paid version. For VNC do you mean RealVNC? I think they have a free version.

Really disappointing that RDP doesn’t work. It’s free, included in Windows, has an app for iPad, and doesn’t require creating a central account with some third party company. :frowning:

4

TeamViewer is a damn picky tool. If it detects anything to make it think you’re using this on a commercial use, it will flag you. A surefire way to get flagged, is to install it on an Active Directory joined system. Installing it on a Windows Server OS is another. You can contest their flagging of your connection as commercial to see if they can explain why it was flagged, and maybe get it fixed.

Yep, wasn’t sure what options you had at your disposal, so I tossed a few out that I’ve used over the years. LogMeIn is a paid product, but if you’ve got an account, it’s useful.

I’ve not used VNC since XP / Server 2003, so I really don’t recollect which one I used. It may have been TightVNC. The biggest thing to do is to look into how to secure VNC over the internet. I used it within a LAN, not from WAN into LAN, so I didn’t have the same security concerns back then. Then again, the same goes for RDP over the internet. It’s a great LAN tool, but exposed to the internet, it’s a highly sought after target.

Can you setup another computer that would not get flagged by TeamViewer as commercial use on the same LAN? TeamViewer into that system, and using Admin Shares, move files around via \plexhostname\f$\movies etc.

Could you setup a VPN on your router? Open RDP through your VPN connection to a different system on your LAN, and then again through Admin Shares, manage the files on your Plex system?

There may be other means of remote connection. I do recollect that Splashtop also makes a remote access tool, but again, it has a cost to it.

1 Like
5

Cheaper yet, outside of security… when you’ve finished with your RDP session, create a script to log you out, thus closing your RDP terminal services session, and then have it automatically log you back in on the console. This will kill the Plex server software when you log out, and restart it when you log back in. You would kill any active streams and DVR sessions, so timing / scheduling is important.

You’d still want to look into ways to secure your RDP connection though.

1 Like
6

I agree that using other remote console tools avoids this issue.

RDP tries to use physical adapters. Has anybody tried disabling this?

Both of these:

RDP also tries to use hardware acceleration. Has anybody ever tried disabling that?

Or forcing RDP to use XDDM? (Disabling WDDM)

Or disabling RemoteFX? (Both of these)

I’m curious if any (or all) of those would prevent RDP from taking over the physical adapter.

7

Yeah I’m only using RDP on the local network to access the machine via my laptop and my iPad. I use the machine for more than just Plex so it is handy to be able to connect to it remotely to do stuff and leave apps running after I disconnect. I thought maybe if I created a second windows user account just for RDP access but Windows 10 Pro only allows one user to be logged in at a time. I’m not interested in running Windows Server. When I have a chance I’ll poke around with some VNC options and see about that. Thanks!

8

You can submit this form to Teamviewer to declare that you are only using it for personal use.

I had a laptop flagged for suspected commercial use for TeamViewer once - apparently I exhibit the same usage behavior at home for personal use that I do in the office for IT work. Gee, imagine that! It took them a few weeks after I submitted the form, but they did lift the limitation and I haven’t had problems since. Ok, so I did switch to VNC for a lot of things because it annoyed me so much while I was waiting…

1 Like
9

I’m noticing this behavior, and it’s worth noting that it’s a change from previous behavior. I’ve used RDP on Win 10 with RemoteFX on servers for years, and as long as it was logged in locally and had a monitor attached, the RDP session didn’t affect Plex at all.

So far, I haven’t reproduced this with Nvidia. It works fine during/after RDP sessions. It’s just Intel. In my case, it either falls back to software encode/decode, or in some cases, it now hard-crashes without a log entry.

Hard to say if this is due to a change in Plex, Windows, or the newer Intel drivers. It’s certainly frustrating, though.

1 Like
10

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