I have a Kaby-Lake-based Plex server (Public channel) using Intel Graphics on Windows 10. I’ve run into a weird showstopper issue: Whenever the Plex server is idle for a while, the hardware trancoder doesn’t work on first try. It’ll still transcode the video, but it will instead use full CPU. I’m seeing this behavior on the recent release (1.13.0.5023), but have also seen it on prior versions.
Here’s the kicker: If you stop the playback, then simply restart it, suddenly you’ll get “(hw)” shown properly in the status. It just happens the very first time after the server has been idle for a while.
Is anyone else seeing this problem? Platform seems to be irrelevant; I’ve seen this in the web app (today), Roku, Android, and LG.
I saw this in action this morning in a test. I had debug logs enabled. I’d be happy to provide them, but I’d like to just post the portion that is needed for troubleshooting, since they’re fairly extensive. What sections are needed?
@trumpy81 said:
What you describe is not a Plex issue, it’s a Windows 10 issue.
Start by updating your graphics card drivers. Then make sure you have all of the latest Microsoft updates installed, especially if your machine has updated to Windows 10 version 1803.
Drivers are current, and I have all updates in place except 1803 (I’ve deferred it for now), but I haven’t done an SFC check. Good reminder. I’ll give it a round right now.
@trumpy81 said:
Run the DISM commands also, that seemed to do the trick for me, but it’s hard to tell because I also had to update the video drivers again, just after running those commands.
At least my issues were resolved after that.
The QFC and DISM scans came back clean. But while I was there, I decided to update to 1803, and MS also offered me a new approved graphics driver for Intel 610. I’ll give it a day or two and see what happens.
Weirdly enough, I’m now seeing a different problem: 480i MPEG2 gets hardware decode/encode, but 720p MPEG2 is getting software decode/encode. Strangest thing. But I’ll eye it and run some testing today.
Ok, I’m officially still seeing this problem. The hardware acceleration on the server is randomly (AFAIK) failing, but will then sometimes work when I stop and immediately restart the playback. The test file being played is 1080p HEVC, on the web app for Chrome. The first two times it attempts to transcode, acceleration failed. The third time I tried, acceleration succeeded for both decode and encode. Probably the key line from the log from the first playback attempt:
May 16, 2018 15:49:35.236 [6096] ERROR - [Transcoder] [h264_qsv @ 03d4e5c0] Error during encoding: device failed (-17)
This is on Windows 10 1803 (but it was happening with prior versions, too). It’s running on a Kaby Lake Celeron G3930, which supports Quick Sync. A monitor is attached, and Plex is not running as a service.
I have a log file available, but every time I try to upload it, the forum gives me this error: “The file failed to upload”. The text file is 517kb with debug enabled, I’m guessing this is too big? It’s just a log of the three playback attempts, so I’m not 100% sure what I should cut out.
It appears that Plex is actively falling back to software transcoding. I’m not sure why, but that should not be a problem. Did you see any issue with the playback at all?
Playback looks fine, other than a noticeably-longer delay when hardware transcoding fails. Thanks for looking at the log files, btw.
This does actually present a significant problem: With hardware transcoding, it can handle 5+ simultaneous transcodes if necessary (the main reason I’m using a modern Intel CPU for this). When it falls back to software encoding, I can barely get one successful transcode, especially if the source is an MPEG2 recording. I could look into alternatives, like trying to optimize a huge collection, but that feels unnecessary (and kind of unreasonable) when hardware transcoding should theoretically work.
Not blaming the Plex software when I say that… just thinking out loud, and would love to find the cause of this problem.
@trumpy81 said:
Correction. I just found this in the log:
May 16, 2018 15:49:35.236 [6096] ERROR - [Transcoder] [h264_qsv @ 03d4e5c0] Error during encoding: device failed (-17)
May 16, 2018 15:49:35.236 [3148] ERROR - [Transcoder] Video encoding failed
May 16, 2018 15:49:35.298 [5860] DEBUG - Jobs: 'C:\Program Files (x86)\Plex\Plex Media Server\PlexTranscoder.exe' exit code for process 9552 is 1 (failure)
May 16, 2018 15:49:35.298 [9720] DEBUG - Streaming Resource: Changing client to use software decoding
The Hardware transcoding failed, probably due to an error in the file. I will see if I can get one of the employees to take a look at your logs. They may have some insight into why it failed.
Thanks! These files are encoded via Handbrake using mostly defaults (x265 8-bit auto-cropped with audio passthru). If you need any file info, just let me know.
@trumpy81 said:
Aside from the space saving, is there any other reason you encode using HEVC?
Personally I don’t recommend it and prefer to stick with the tried and tested H.264.
If I may ask, why the cropping?
In general, I leave Blu-Rays at full quality H.264 unless they have forced subtitles. In that scenario, I re-encode them in Handbrake to “burn in” just the forced subtitles. For the codec HEVC is just a personal preference since all my devices support it natively. I’m not married to it; it has simply been highly effective since I started using it.
Also worth noting: I’ve seen this same problem when Plex needed to transcode from H264 to H264. Typical scenario: Full Blu-Ray file being streamed to a mobile network, or a device that doesn’t have strong enough wifi. So with this particular problem, it doesn’t seem to be HEVC-specific. I’d be happy to run more tests, just to make sure that’s still the case though. I haven’t tried in a bit, perhaps that’s an evening task for me.
For cropping: Interesting question! I’ve been cropping video to clear pillbox/letterboxing since the early days of DVD’s. It means it’ll display at the fullest possible size on any device. For one example, if I didn’t crop, it wouldn’t properly fill a 21x9 ratio monitor. Is there a known disadvantage to cropping?
I can only suggest that you experiment a little with the settings in HandBrake, relaxing the amount of compression would help for sure, but may reduce the quality a little.
Or, revert to using H.264.
I know we’re at a standstill on this one (frustrating but understood), but I was also able to reproduce this problem with a H.264 file directly ripped from a Blu-Ray. If, for any reason, you’re interested in the logs, just give the word.
Please test them and let us know if you are still having issues, thanks.
Nice catch. Worth a shot! I’m holding out hope it might also fix the 720p MPEG2 issue I’m seeing, since it has the same error in the logs on two different machines. Thanks for letting me know. I really should add that driver page to my RSS feeds.
No luck! I updated drivers on both servers with Quick Sync (Kaby Lake and Haswell), but same problems. I’ll get you some logs later tonight, and I might also edit a small set of MPEG2 clips in case you’re interested in seeing if you can reproduce that behavior as well.
Plex Media Server beta release 1.17.0.1709 which has an updated Plex Transcoder ffmpeg should resolve the following error [h264_qsv @ xxxxxx] Error during encoding: device failed (-17)
