Jacon

Updated previous post with Nvidia forum link. As of this morning, I've successfully played 7 different transcoded HEVC --> 1080p files with no problems on 470.101.03. I'm almost a tad weary of upgrading to 515.86.01 for fear of losing functionality. Eventually, I'll do it and post the NVIDIA-BUG-LOG

Loaded the 470.x driver and it stumbled on the first HEVC Main 10 transcode within 5 mins, but after closing and restarting, all subsequent HEVCs and the VC1 transcode without error. I ran the internal NVIDIA-BUG-REPORT.sh and uploaded that to the Nvidia forums. I'm going to load the 515.86.01 drivers, repeat the attempted transcodes and upload the bug-report.log to Nvidia. https://forums.developer.nvidia.com/t/515-86-01-giving-trouble-on-gtx-1070-for-transcoding/235534

I'd like to revert to the earlier 510.85.02 or 515.xx.xx version to rule out a specific driver error but I'm not sure how to do that. Is that possible? It might be anecdotal, but my experience with fresh updated drivers is that they're never perfect and with as many variants of GTX 10 series cards out in the market, it plausible that an updated driver misses compatibility with older cards. It's also possible that someone may not have updated to the 515.86.01 with my specific GTX 1070 card, and I'm just the first to have problems. It's very possible that the .01 version of the 515 driver could be buggy.

I don’t have one.

Is it possible to run a CUDA-memtest within Unraid? In short, my GTX 1070ti stopped HW transcoding and outside of replacing it, I'm wondering if it's possible to run this package from terminal. I don't have any other method to validate a hardware failure before chucking this thing out of my window. I'm not a programmer, and have little linux knowledge to know if this is even possible. Nvidia CUDA Memtest Toolkit

I'm investigating how to run a CUDA memtest on the card to see if the onboard memory has failed. Happens on H264 files too.

So with a little more testing, it transcodes the first 5 mins of a VC1 file, then hangs, and converts to software transcoding. I was able to repeat this several times. All HEVC files initiate HW transcoding very briefly (seconds), then moves to software. NVIDIA-SMI still shows the transcoding process occurring in the background, but no output obviously. All H264 plays direct, of course. How could I revert drivers if I wanted to before going nuclear and picking up a different GPU? I'd even consider going back to 6.11.1

I don’t know if it changes anything. All I know is that somewhere between all of the recent upgrades, I lost the ability to HW transcode in recent weeks. It could all be related or simply coincidental and I’ve lost my GPU.

MSI GTX 1070 8g

Happens with every file...HEVC 4K, VC1 1080p, etc. Plex mods recommend I downgrade to 510.85.02 but that's obviously not an option with the plugin.

Did anyone here ultimately solve this problem? I have the exact same issues on my GTX 1070 and I'm now on 6.11.5. Plex reverts to software instead of HW transcoding.

Installed jellyfin, getting the same symptoms. Decoder side of the GPU is blasting away, but nothing from the encoder.

I'm positive. It attempts to access the GPU and when the process fails, it reverts to the CPU. No subtitles being forced. I uninstalled the docker, cleared the docker, restarted and reinstalled. Still getting the same errors with the same description in syslog.

Im also noticing that Plex is reverting to software transcoding yet the GPU Statistics plugin is registering the process and that Plex has an active stream. Im officially puzzled.

Happens on all movies and I'm on the latest Official Plex Container. I will try downgrading to an earlier 1.29.2.x version and report back.

Here you go! I ran several Plex sessions on different clients to get the problem to occur more than once. sassnas-diagnostics-20221123-0912.zip

My GTX 1070 freezes within the first 10-15 mins of transcoding a video. NVIDIA Corporation GP104 [GeForce GTX 1070] (rev a1) Running the official Plex Docker and transcoding to ram using /dev/shm This started after moving from 6.11.2 to 6.11.4 and I haven't had any trouble before what appears to be the last upgrade. Syslog is dropping this error: Ive tried the Latest and Production branches but nothing changes. Not sure if this is a driver or RAM problem. sassnas-syslog-20221123-0118.zip

Got brave yesterday and upgraded the BIOS to 3.4. Runs very well and no conflicts so far. iGPU still functions perfectly. BIOS menu remains mostly unchanged from what I noticed.

After you boot to a DOS prompt (C:/), you’ll type ‘ami.bat x10slh5.c17’ (no apostrophes) and it’ll do the rest. Open the read me and it should say the same thing. i used Balena Etcher (from a Mac) to flash the basic freedos image to a usb drive, then I copied the BIOS files to the same USB. Put the usb into a slot and boot. Press F11 to open the boot selection menu during the BIOS boot. Select your usb flash drive containing DOS and the new bios. If you do choose FreeDOS, it will prompt you too install the FreeDOS OS, BUT you don’t need to. Simply back out and it’ll take you right to a DOS prompt. From there you can install the new x10 BIOS.

Forgot to mention, you can transition containers fairly easily without disrupting your library. All you need to do is move the Plex Media Library appdata folder from your current container folder to the new one. Spaceinvader One has a good video on how to migrate libraries without rebuilding configs, etc.

The rep sent me 3.0a, which isn’t listed on their site. Sent you a message. Id be slightly worried about a 3.4 update in the event it conflicts with unraid or a driver in some way. To the old adage, “if it ain’t broke…” I know 3.0a works based on my experience, I can’t speak to 3.4.

@velcroBP More good news, after some... tribulations. I floated between Binhex, Isio and the Official docker, and I landed on the official docker because now with successful HW transcoding, I have no reason to move back to Binhex or Isio. I'm not saying those won't work, but I'm satisfied with the official docker such that I don't need to move back to a different docker. Therefore, after many settings adjustments, and getting mixed results compared to my last post, I finally reached out to Supermicro and we finally concluded that I need to upgrade my BIOS to 3.0a. I was previously on 3.0 but apparently the A-version includes an update to the Intel Graphics. The customer rep couldn't give me any more detail than that as to why because 1) he was a low-level tech 2) the board is no longer supported. However, his recommendation seems to do the trick. I updated the BIOS to 3.0a and all is gravy. Same settings as above, Internet Streaming and Home Streaming both set to max, YMMV, [Play Smaller Videos at Original Quality] is checked. /dev/dri is added as a Device path and [--device=/dev/dri:/dev/dri] is added under Extra Parameters. Interestingly, the Official Docker and Isio docker are VERY similar. 1080p transcodes well, but 4K struggles (but at least the iGPU tries unlike before), as to be expected with the Haswell capabilities. I no longer get s1003 errors, only slow or buffered transcoding if the file is too complex If you need help updating your BIOS, message me and I'll walk you through it. I don't think the 3.0a BIOS is available on Supermicro's website but you could go right to 3.4, which is on their website. 🙂

@VelcroBP I have promising results! The good news is that I'm now transcoding two simultaneous 1080p H264 files and one 4K H265, so at a minimum, the following conditions apply. I'm going to change each of these of these rows over the coming days to determine exactly which change produced the (HW) transcoding results. 1) I moved to the Binhex-Plex container. I was previously on the LSIO container because of the advertised HDR --> SDR tone mapping, but I wasn't able to transcode. This may change. I added the [--device=/dev/dri:/dev/dri] command to the Extra Parameters line and I also added a Device with the docker options to /dev/dri. I will remove each of these one at a time to determine if I need one or the other, or both 2) my VGA jumper on the mobo is set to disabled. I will probably re-enable this jumper first because it disables my ability to view anything, included the BIOS post and therefore my ability to log into the BIOS menu. JPG1 jumper set to disabled, for now. 3) MOBO BIOS is 3.0 and I haven't upgraded any of the BIOS or BMC firmware 4) Plex settings [General] --> [Automatically Adjust Quality] Off Internet Streaming [Play Smaller Videos At Original Quality] On Home Streaming [Use recommended settings] On [Debug] [Direct Play] On [Direct Stream] On [Use alternative streaming protocol for video playback] Off [Transcoder] --> [Default Throttle Buffer] 30 secs [Enable HDR Tone Mapping] On [Disable Video Stream Transcoding] Off [Use Hardware Acceleration] On [Use Hardware-accelerated Video Encoding] On 4) My GPU Statistics plugin (Intel GPU-TOP also installed) now shows activity on the dashboard but my CPU also shows 25-50% activity. Therefore, I cannot tell whether how much load sharing is occurring between the CPU and GPU. Frankly, I don't care because I'm able to transcode three 4K streams...something I couldn't even dream of before. When I run cd /dev/dri/ from terminal, I get back a Card0 and RenderD128, so my driver is active. I did NOT modprobe i915 the drivers or anything related to blacklisting or forcing the drivers. This is on UnRaid 6.10.3 and Plex 4.84.1 (also assumes you have Plex Pass). @ me if you have follow-ups. I'm subscribed.

I’m going to try a couple of things and if I figure it out, I’ll report back with my settings. This is frustrating.

@VelcroBP Any luck getting this sorted out? I'm running a E3-1275l on a X10SLH-F and cannot get HW transcoding to work. All is enabled, and I get the card0 card1 renderD128 but Plex will not shift over to transcoding. I get the same s1003 error as you. Running linuxserver.io version of Plex.