Client failure in VM server environment

Plex Media Server
1

I am also experiencing this issue. Hardware transcoding works on all my other devices, but I get the same error code when requesting a transcode from my Windows client. Is there any suggested fix yet?

There is another issue that seems to be the same problem, with no update or solution: Plex Transcode Fails ONLY on Windows clients

Proxmox is not supported but there is a very helpful user community.

@ChuckPa can I ask what it is about proxmox that makes it unsupported? Is there any officially supported hypervisor distribution?

2

There are no Officially Supported hypervisors because PMS isn’t a bare-metal application. It requires an OS to run.

The officially supported OS distributions are Debian , Ubuntu, Redhat, Centos, Fedora.

There is compatibility with more DPKG-based systems due to the new installation scripting. This will extend into more RPM compatible distributions when the RPM packaging is updated this fall.

In summary:

  1. Debian/Ubuntu - Native DEB package
  2. Redhat/Centos/Fedora - Native RPM package
  3. Docker packaging
  4. SNAP packaging.
3

Thanks for the context. I appreciate your insight.

For reference, I am currently running PMS in an Ubuntu Server virtual machine. Proxmox itself is actually just debian with some fancy software on top, too. Since Debian, Ubuntu, and Docker are all supported, which do you think would be the most “supported” setup for those of us wanting to run this on our multi-tenant servers:

  • as an application installed on the hypervisor (which is debian-based),
  • as an application installed in an ubuntu virtual machine,
  • or as a docker container running on top of the hypervisor’s containerization platform?
4

I find that running closer to the OS is best.

If you examine the abstraction layers.

PMS -> Docker -> Host OS ; has the “docker layer”
PMS -> Host OS ; is clean.

When running on the native host OS, my scripting can configure the hardware transcoding access if present.

If a hypervisor makes the host hardware available (/dev/dri directory), then it should also be available to the Guest OS and work properly.

5

Ok, cool. I think my next major step would be trying to run it directly from the debian host, but I’m not quite ready to give up on the VM. The hardware passthrough was a huge pain in the ass to get working, but I’m glad to see that the direct access is in the place you expect. Here’s the tree of my /dev/dri inside the VM:

/dev/dri$ tree
.
├── by-path
│   ├── pci-0000:01:00.0-card -> ../card0
│   └── pci-0000:01:00.0-render -> ../renderD128
├── card0
└── renderD128

Furthermore, I double checked with the nvidia-smi tool during a transcode and found its process there. Unfortunately, I think this just means it “should” work, but there’s no good way of debugging it because it goes a little beyond what most people might have setup.

If you feel like giving this a second shot, I’m happy to work on getting debug logs from the GPU drivers and operating system (probably in the next few days). Otherwise I know how unpleasant debugging anything hardware-related in a virtualized environment is, so I don’t blame you for citing the “not officially supported” point, lol.

6

@jeichenhofer

I moved this here to avoid bothering the OP.

I am willing to try but there are limits to what I can do .

I was never able to establish Proxmox in VMware with any success (which would have been magic if it did . haha)

1 Like
7

Awesome, works for me. Thanks for your time! I need to sign off super soon, but if you can put together a list of the logs you think might help, I can start collecting them sometime tomorrow. At the very least, I’ll capture the PMS logs, the windows client debug logs, and the nvidia driver logs (once I figure out where the relevant ones are). I can’t imagine there will be anything telling in the qemu logs about the passthrough, but we can go there if we hit a dead end in the other places.

8

what would help me is:

  1. lshw output
  2. lspci output
  3. dmesg output capturing what is found at startup.
  4. PMS DEBUG (not VERBOSE) capturing the first 30 seconds of a playback (this is where all the decisions happen).

From the 3 system tools, it should be possible to trace the hardware being found, identified, and mapped into the kernel.

PMS will then pick up what it finds.

Another point here, plex is an unprivileged user. It relies on udev to assign the video group so it can access the hardware.

The PMS installation log (/tmp/plexinstaller.log) tells everything it found and configured for. - this tells me everything it saw at that moment.

This is how it looks on my system (native)

[root@lizum]# tree /dev/dri
/dev/dri
├── by-path
│   ├── pci-0000:00:02.0-card -> ../card0
│   ├── pci-0000:00:02.0-render -> ../renderD128
│   ├── pci-0000:01:00.0-card -> ../card1
│   └── pci-0000:01:00.0-render -> ../renderD129
├── card0
├── card1
├── renderD128
└── renderD129
9

Ok, I’ve collected all the logs into this archive. Everything that didn’t come from the “download logs” button on the plex server interface is prefixed with “extra”. There was no /tmp/plexinstaller.log file on the host.

There are some almost-sensitive identifiers in there, so the link will expire when you download it. Let me know if I should re-upload. Thanks again for taking a look!

10

Would it be possible to get a single active playback session to debug this with for the AFTV ?

I see at least 2, most likely 3 overlapping playbacks. It’s really difficult to track and I keep getting lost.

What I can see looks like the AFTV just drops . It doesn’t report a commanded stop.

11

Sorry about that. I didn’t realize someone was watching something when I did my little test.

Here are a new set of logs from plex and the windows client. The most recent events should be just me opening a movie to play, switching it to a lower bitrate, getting the error message, retrying, then setting back to a direct stream/play of the original for 15 seconds.

EDIT: Here is also a single log file showing what it looks like when hardware transcode works correctly for my phone.

12

This is where I first start playing the movie:

"Plex Media Server.log":L056499: Sep 24, 2020 04:33:07.219 [0x7fcace7fc700] DEBUG - Request: [10.0.0.22:53416 (Subnet)] GET /video/:/transcode/universal/decision?hasMDE=1&path=%2Flibrary%2Fmetadata%2F840&mediaIndex=0&partIndex=0&protocol=http&fastSeek=1&directPlay=1&directStream=1&subtitleSize=100&audioBoost=100&location=lan&addDebugOverlay=0&autoAdjustQuality=0&directStreamAudio=1&advancedSubtitles=text&session=o3zp2botjz7pnstdj6etjl3z&subtitles=none&copyts=1&Accept-Language=en (10 live) TLS GZIP Signed-in Token (jeichenhofer)

This is where I first request the change in bitrate:

"Plex Media Server.log":L056553: Sep 24, 2020 04:33:12.621 [0x7fcacdffb700] DEBUG - Request: [10.0.0.22:53420 (Subnet)] GET /video/:/transcode/universal/decision?hasMDE=1&path=%2Flibrary%2Fmetadata%2F840&mediaIndex=0&partIndex=0&protocol=http&fastSeek=1&directPlay=0&directStream=1&subtitleSize=100&audioBoost=100&location=lan&maxVideoBitrate=20000&addDebugOverlay=0&autoAdjustQuality=0&directStreamAudio=1&advancedSubtitles=text&session=cyc1g9lvlbunq0677e4kvio8&offset=4&subtitles=auto&copyts=1&Accept-Language=en (7 live) TLS GZIP Signed-in Token (jeichenhofer)

These two sets of messages seem to indicate failure, but I don’t know what they mean.

"Plex Media Server.log":L056625: Sep 24, 2020 04:33:12.687 [0x7fcacffff700] DEBUG - Failed to stream media, client probably disconnected after 171048960 bytes: 104 - Connection reset by peer
"Plex Media Server.log":L056626: Sep 24, 2020 04:33:12.687 [0x7fcacffff700] DEBUG - Completed after connection close: [10.0.0.22:53426] 206 GET /library/parts/1418/1600388912/file.mkv (7 live) TLS 4827ms 171048960 bytes (range: bytes=6976-)
. . .
"Plex Media Server.log":L056683: Sep 24, 2020 04:33:14.589 [0x7fcacdffb700] DEBUG - Codecs: testing h264 (decoder) with hwdevice vaapi
"Plex Media Server.log":L056684: Sep 24, 2020 04:33:14.590 [0x7fcacdffb700] DEBUG - Codecs: hardware transcoding: testing API vaapi
"Plex Media Server.log":L056685: Sep 24, 2020 04:33:14.590 [0x7fcacdffb700] DEBUG - Codecs: hardware transcoding: opening hw device failed - probably not supported by this system, error: Input/output error
"Plex Media Server.log":L056686: Sep 24, 2020 04:33:14.590 [0x7fcacdffb700] DEBUG - Codecs: testing h264 (decoder) with hwdevice nvdec
"Plex Media Server.log":L056687: Sep 24, 2020 04:33:14.590 [0x7fcacdffb700] DEBUG - Codecs: hardware transcoding: testing API nvdec

Here’s what I think is causing the failure, but I’m not following the logs well enough to know. It happens right after what appears to be my “retry” request.

"Plex Media Server.log":L056751: Sep 24, 2020 04:33:14.708 [0x7fcace7fc700] WARN - Denying access due to session lacking permission to transcode key /library/metadata/840

I think this is where the final 15 seconds of playing it directly from the source starts.

"Plex Media Server.log":L058131: Sep 24, 2020 04:33:36.860 [0x7fcaccff9700] DEBUG - Streaming Resource: Added session 0x7fca040c3e50:xkr8ni344yssbek3a48bougz
"Plex Media Server.log":L058132: Sep 24, 2020 04:33:36.860 [0x7fcaccff9700] DEBUG - Streaming Resource: Reached Decision id=840 codes=(MDE=1000,Direct play OK.) media=(id=1418 part=(id=1418 decision=direct play protocol=http streams=(Video=(id=4632 decision= width=1920 height=1080) Audio=(id=4633 decision= channels=0 rate=0))))
"Plex Media Server.log":L058133: Sep 24, 2020 04:33:36.861 [0x7fcacf7fe700] DEBUG - Completed: [10.0.0.22:53439] 200 GET /video/:/transcode/universal/decision?hasMDE=1&path=%2Flibrary%2Fmetadata%2F840&mediaIndex=0&partIndex=0&protocol=http&fastSeek=1&directPlay=1&directStream=1&subtitleSize=100&audioBoost=100&location=lan&addDebugOverlay=0&autoAdjustQuality=0&directStreamAudio=1&advancedSubtitles=text&session=4jeebb4l5tfrft2paxrpcjcb&subtitles=none&copyts=1&Accept-Language=en (14 live) TLS GZIP 10ms 3371 bytes (pipelined: 3)
"Plex Media Server.log":L058134: Sep 24, 2020 04:33:36.947 [0x7fcacf7fe700] DEBUG - Auth: authenticated user 1 as jeichenhofer
"Plex Media Server.log":L058135: Sep 24, 2020 04:33:36.947 [0x7fcab97fa700] DEBUG - Request: [10.0.0.22:53443 (Subnet)] GET /library/parts/1418/1600388912/file.mkv (15 live) TLS Signed-in Token (jeichenhofer) (range: bytes=0-) 
"Plex Media Server.log":L058136: Sep 24, 2020 04:33:36.951 [0x7fcab97fa700] DEBUG - Content-Length of /mnt/magnesia_pool/plex_data/library/Movies/Her (2013)/Her (2013).mkv is 26261696689 (of total: 26261696689).
13

Deep diving in the logs.

  1. Is this expected?
Sep 24, 2020 02:33:15.977 [0x7fcabbfff700] WARN - Denying access due to session lacking permission to transcode key /library/metadata/403
  1. When’s the last time analysis was run? According to the transcoder and the app, the duration and timing wasn’t right. It “ran off the end” unexpectedly but otherwise played to the end (6548.115 seconds of what was thought to be 6850.000 seconds).
Sep 24, 2020 04:21:27.161 [0x7fca70ff9700] DEBUG - Request: [72.131.16.65:41086 (WAN)] GET /:/timeline?audioStreamID=4737&bufferedTime=267053&duration=6850000&guid=com.plexapp.agents.themoviedb%3A%2F%2F22796%3Flang%3Den&key=%2Flibrary%2Fmetadata%2F860&playbackTime=1570007&playQueueItemID=2486&ratingKey=860&state=playing&time=6548115&token=xxxxxxxxxxxxxxxxxxxx (9 live) TLS GZIP Signed-in Token (allie.ike)
Sep 24, 2020 04:21:27.161 [0x7fca70ff9700] DEBUG - Client [f9f709fb46499675-com-plexapp-android] reporting timeline state playing, progress of 6548115/6850000ms for guid=com.plexapp.agents.themoviedb://22796?lang=en, playbackTime=1570007ms ratingKey=860 url=, key=/library/metadata/860, containerKey=, metadataId=860, source=
Sep 24, 2020 04:21:27.161 [0x7fca70ff9700] DEBUG - [Now] User is allie.ike (ID: 40618858)
Sep 24, 2020 04:21:27.162 [0x7fca70ff9700] DEBUG - [Now] Device is Android (AFTT).
Sep 24, 2020 04:21:27.162 [0x7fca70ff9700] DEBUG - [Now] Profile is Android
Sep 24, 2020 04:21:27.162 [0x7fca70ff9700] DEBUG - [Now] Updated play state for /library/metadata/860.
Sep 24, 2020 04:21:27.162 [0x7fca70ff9700] DEBUG - Statistics: (f9f709fb46499675-com-plexapp-android) Reporting active playback in state 0 of type 1 (scrobble: 0) for account 40618858
Sep 24, 2020 04:21:27.167 [0x7fcacffff700] DEBUG - Completed: [72.131.16.65:41086] 200 GET /:/timeline?audioStreamID=4737&bufferedTime=267053&duration=6850000&guid=com.plexapp.agents.themoviedb%3A%2F%2F22796%3Flang%3Den&key=%2Flibrary%2Fmetadata%2F860&playbackTime=1570007&playQueueItemID=2486&ratingKey=860&state=playing&time=6548115&token=xxxxxxxxxxxxxxxxxxxx (9 live) TLS GZIP 6ms 801 bytes (pipelined: 159)
Sep 24, 2020 04:21:31.618 [0x7fca70ff9700] DEBUG - Request: [72.131.16.65:49299 (WAN)] GET /video/:/transcode/universal/session/f9f709fb46499675-com-plexapp-android/base/00805.ts (9 live) TLS Signed-in
Sep 24, 2020 04:21:31.618 [0x7fca70ff9700] DEBUG - Asked for segment 805 from session.
Sep 24, 2020 04:21:31.618 [0x7fca70ff9700] DEBUG - Returning segment 805 from session
Sep 24, 2020 04:21:31.619 [0x7fca70ff9700] DEBUG - Content-Length of /mnt/magnesia_pool/plex_data/transcoding/Transcode/Sessions/plex-transcode-f9f709fb46499675-com-plexapp-android-1cc803d2-be9f-4293-babc-4526dada2ae4/media-00805.ts is 809180 (of total: 809180).
Sep 24, 2020 04:21:31.623 [0x7fcacffff700] DEBUG - Completed: [72.131.16.65:49299] 200 GET /video/:/transcode/universal/session/f9f709fb46499675-com-plexapp-android/base/00805.ts (9 live) TLS 5ms 809180 bytes (pipelined: 2)
Sep 24, 2020 04:21:31.623 [0x7fcacffff700] DEBUG - Removed transcode data consumer, active count 1 => 0
Sep 24, 2020 04:21:35.890 [0x7fca70ff9700] DEBUG - Request: [72.131.16.65:49298 (WAN)] GET /video/:/transcode/universal/session/f9f709fb46499675-com-plexapp-android/base/00806.ts (9 live) TLS Signed-in
Sep 24, 2020 04:21:35.890 [0x7fca70ff9700] DEBUG - Asked for segment 806 from session.
Sep 24, 2020 04:21:35.890 [0x7fca70ff9700] DEBUG - Returning segment 806 from session
Sep 24, 2020 04:21:35.891 [0x7fca70ff9700] DEBUG - Content-Length of /mnt/magnesia_pool/plex_data/transcoding/Transcode/Sessions/plex-transcode-f9f709fb46499675-com-plexapp-android-1cc803d2-be9f-4293-babc-4526dada2ae4/media-00806.ts is 622812 (of total: 622812).
Sep 24, 2020 04:21:35.894 [0x7fcacf7fe700] DEBUG - Completed: [72.131.16.65:49298] 200 GET /video/:/transcode/universal/session/f9f709fb46499675-com-plexapp-android/base/00806.ts (9 live) TLS 3ms 622812 bytes (pipelined: 3)
Sep 24, 2020 04:21:35.894 [0x7fcacf7fe700] DEBUG - Removed transcode data consumer, active count 1 => 0
Sep 24, 2020 04:21:37.160 [0x7fcacffff700] DEBUG - Auth: authenticated user 40618858 as allie.ike
Sep 24, 2020 04:21:37.161 [0x7fca70ff9700] DEBUG - Request: [72.131.16.65:41086 (WAN)] GET /:/timeline?audioStreamID=4737&bufferedTime=276429&duration=6850000&guid=com.plexapp.agents.themoviedb%3A%2F%2F22796%3Flang%3Den&key=%2Flibrary%2Fmetadata%2F860&playbackTime=1580011&playQueueItemID=2486&ratingKey=860&state=playing&time=6558135&token=xxxxxxxxxxxxxxxxxxxx (9 live) TLS GZIP Signed-in Token (allie.ike)
Sep 24, 2020 04:21:37.162 [0x7fca70ff9700] DEBUG - Client [f9f709fb46499675-com-plexapp-android] reporting timeline state playing, progress of 6558135/6850000ms for guid=com.plexapp.agents.themoviedb://22796?lang=en, playbackTime=1580011ms ratingKey=860 url=, key=/library/metadata/860, containerKey=, metadataId=860, source=
Sep 24, 2020 04:21:37.162 [0x7fca70ff9700] DEBUG - [Now] User is allie.ike (ID: 40618858)
Sep 24, 2020 04:21:37.162 [0x7fca70ff9700] DEBUG - [Now] Device is Android (AFTT).
Sep 24, 2020 04:21:37.162 [0x7fca70ff9700] DEBUG - [Now] Profile is Android
Sep 24, 2020 04:21:37.162 [0x7fca70ff9700] DEBUG - [Now] Updated play state for /library/metadata/860.
Sep 24, 2020 04:21:37.162 [0x7fca70ff9700] DEBUG - Statistics: (f9f709fb46499675-com-plexapp-android) Reporting active playback in state 0 of type 1 (scrobble: 0) for account 40618858
Sep 24, 2020 04:21:37.165 [0x7fcacf7fe700] DEBUG - Completed: [72.131.16.65:41086] 200 GET /:/timeline?audioStreamID=4737&bufferedTime=276429&duration=6850000&guid=com.plexapp.agents.themoviedb%3A%2F%2F22796%3Flang%3Den&key=%2Flibrary%2Fmetadata%2F860&playbackTime=1580011&playQueueItemID=2486&ratingKey=860&state=playing&time=6558135&token=xxxxxxxxxxxxxxxxxxxx (9 live) TLS GZIP 3ms 801 bytes (pipelined: 160)
Sep 24, 2020 04:21:39.556 [0x7fca70ff9700] DEBUG - Request: [72.131.16.65:49299 (WAN)] GET /video/:/transcode/universal/session/f9f709fb46499675-com-plexapp-android/base/00807.ts (9 live) TLS Signed-in
Sep 24, 2020 04:21:39.556 [0x7fca70ff9700] DEBUG - Asked for segment 807 from session.
Sep 24, 2020 04:21:39.556 [0x7fca70ff9700] WARN - Transcode runner appears to have died.
Sep 24, 2020 04:21:39.656 [0x7fca70ff9700] DEBUG - Sending back blank segment for 807, we overestimated the number of segments.
Sep 24, 2020 04:21:39.656 [0x7fca70ff9700] DEBUG - Returning segment 807 from session
Sep 24, 2020 04:21:39.657 [0x7fca70ff9700] DEBUG - Content-Length of /usr/lib/plexmediaserver/Resources/empty is 0 (of total: 0).
Sep 24, 2020 04:21:39.657 [0x7fca70ff9700] DEBUG - Completed: [72.131.16.65:49299] 200 GET /video/:/transcode/universal/session/f9f709fb46499675-com-plexapp-android/base/00807.ts (9 live) TLS 100ms 0 bytes (pipelined: 3)
Sep 24, 2020 04:21:43.266 [0x7fca70ff9700] DEBUG - Request: [72.131.16.65:49298 (WAN)] GET /video/:/transcode/universal/session/f9f709fb46499675-com-plexapp-android/base/00808.ts (9 live) TLS Signed-in
Sep 24, 2020 04:21:43.266 [0x7fca70ff9700] DEBUG - Asked for segment 808 from session.
Sep 24, 2020 04:21:43.267 [0x7fca70ff9700] WARN - Transcode runner appears to have died.
Sep 24, 2020 04:21:43.367 [0x7fca70ff9700] DEBUG - Sending back blank segment for 808, we overestimated the number of segments.
Sep 24, 2020 04:21:43.367 [0x7fca70ff9700] DEBUG - Returning segment 808 from session
Sep 24, 2020 04:21:43.367 [0x7fca70ff9700] DEBUG - Content-Length of /usr/lib/plexmediaserver/Resources/empty is 0 (of total: 0).
Sep 24, 2020 04:21:43.367 [0x7fca70ff9700] DEBUG - Completed: [72.131.16.65:49298] 200 GET /video/:/transcode/universal/session/f9f709fb46499675-com-plexapp-android/base/00808.ts (9 live) TLS 100ms 0 bytes (pipelined: 4)
Sep 24, 2020 04:21:43.390 [0x7fca70ff9700] DEBUG - Request: [72.131.16.65:49299 (WAN)] GET /video/:/transcode/universal/session/f9f709fb46499675-com-plexapp-android/base/00809.ts (9 live) TLS Signed-in
Sep 24, 2020 04:21:43.391 [0x7fca70ff9700] DEBUG - Asked for segment 809 from session.```

In short,  that AFTT session played right up to the end,  and seemed to seek forward and backward correctly on command (I watched all the block numbers increase and decrease)
14
  1. Is this expected?
Sep 24, 2020 02:33:15.977 [0x7fcabbfff700] WARN - Denying access due to session lacking permission to transcode key /library/metadata/403

@ChuckPa

No, I’m pretty sure that’s related to whatever is failing, actually, but I haven’t found any good answers related to it yet.

  1. When’s the last time…

I did an analysis just a few hours before capturing all these logs. I’m pretty sure what you’re seeing there is a result of me flipping the HW transcode settings to allow playback using the SW transcoding.

Were you able to make any sense of the failures I mentioned in my post above? The ones about the Input/output error? Also, I edited the other post above to include an example of what HW transcoding looks like when it works with my phone. The weird permission warning isn’t there, which makes me think it’s related to the issue when the client is Windows.

15

That is a problem indeed. It means some of the metadata files are

May I please have a set of logs here in the thread please?

Your off-site logs have been removed.

16

pms_working_transcode.log (721.5 KB)
pms_and_client_2020-09-24_04-34-13.7z (3.1 MB)

17

thank you. I wish there was a way to monitor the Nvidia.

I am suspecting the Nvidia is the root cause here. Something about being in the VM, being passed through, perhaps passthrough limitations. Whatever it is, it’s an extreme case.

18

I wonder if there is something in the Windows Plex Client profile that causes plex to send broken arguments to the transcoder. Is there any way to make plex fall back onto transcode default settings similar to whatever the android settings are? I’m specifically looking at how the WORKING hardware transcode starts with this:

pms_working_transode.log Lines 49-51

Sep 24, 2020 05:11:35.649 [0x7fcabb7fe700] DEBUG - Request: [10.0.0.83:44294 (Subnet)] GET /video/:/transcode/universal/decision?audioBoost=100&autoAdjustQuality=0&directPlay=1&directStream=1&directStreamAudio=1&fastSeek=1&hasMDE=1&location=lan&maxVideoBitrate=200000&mediaBufferSize=74944&mediaIndex=0&partIndex=0&path=%2Flibrary%2Fmetadata%2F681&protocol=*&session=1e14243385501c82-com-plexapp-android&subtitleSize=100&videoBitrate=200000&videoQuality=100&videoResolution=3840x2160 (13 live) TLS GZIP Signed-in Token (jeichenhofer)
Sep 24, 2020 05:11:35.649 [0x7fcabb7fe700] DEBUG - Found session GUID of 1e14243385501c82-com-plexapp-android in session start.
Sep 24, 2020 05:11:35.650 [0x7fcabb7fe700] DEBUG - TranscodeUniversalRequest: using augmented profile Android

While the desktop client (which gets the error message) has this:

“pms_and_client_2020-09-24_04-34-13.7z/Plex Media Server.log” Lines 58122-58124

Sep 24, 2020 04:33:36.851 [0x7fcaccff9700] DEBUG - Request: [10.0.0.22:53439 (Subnet)] GET /video/:/transcode/universal/decision?hasMDE=1&path=%2Flibrary%2Fmetadata%2F840&mediaIndex=0&partIndex=0&protocol=http&fastSeek=1&directPlay=1&directStream=1&subtitleSize=100&audioBoost=100&location=lan&addDebugOverlay=0&autoAdjustQuality=0&directStreamAudio=1&advancedSubtitles=text&session=4jeebb4l5tfrft2paxrpcjcb&subtitles=none&copyts=1&Accept-Language=en (14 live) TLS GZIP Signed-in Token (jeichenhofer)
Sep 24, 2020 04:33:36.851 [0x7fcaccff9700] DEBUG - Found session GUID of 4jeebb4l5tfrft2paxrpcjcb in session start.
Sep 24, 2020 04:33:36.851 [0x7fcaccff9700] DEBUG - TranscodeUniversalRequest: using profile Plex Desktop
19

If there were something in the player, I would think it would have been found long ago and be widespread at this point.

Making the two players behave the same isn’t really possible because the screen sizes are different and the audio capabilities are different.

You could , theoretically, create a custom profile for testing purposes and supersede the default one but the augmentation performed by the MDE is a PMS-Player negotiation which can’t be turned off

20

I can confirm that I have exactly similar issues without having a VM layer between this.
OS Ubuntu 20.04
Nvidia gpu: p2200
2x e5-2680v2
128Gigs of ecc ram

Again this is an issue, and it is isolated how the Windows clients are handled.
Both PMP and Plex Player have this error, just casually saying failed playback on transcodes with HW encoding on the Server side, if that is disabled it works fine and dandy most of the times.
Again this looks like the Windows client is definitely at fault.
Browser client works fine as always, so it seems like the development for the Desktop apps is just not even looked at at all.
The Devs should take a huge look into this as well I am more or less ready to drop plex as a whole.