djtodd

Love this plugin. I finally have good control over the fans. Came in just to say thanks for this very useful tool. Concerned that the developer @CkChong hasn't posted since last October.

I just wanted to jump in again and thank @ich777 for nor only the Nvidia driver, but the iGPU one as well. Having much better luck on my new Intel setup!

Nah, all of this stuff was working fine before. It's OK. I'm using this as a learning experience and I'm going to delve into Intel hardware. Lots to play with there with power savings and other things to fiddle with. It's not a crisis, its an opportunity to learn!

So you rebuilt the Yeah, not a space. Looks like one! Had my hopes up for a minute that I pulled a classic IT fat finger.

At any rate, I appreciate the help @ich777 . I'm not sure what I'm doing wrong, but we tried. Like the responsible adult that I am I thought "This is incentive to build a new system on Intel hardware and get frustrated by QuickSync instead!" 😆

I swear I'm not on drugs. Doesn't help. Switch anything to transcode and the CPU goes nuts. I've tried an Android device, a Windows Plex app (not the web app), and various media sources. Most stuff direct plays of course, but when I force it to 720p (for example)

Yes, it's started with the --runtime=nvidia I guess 7.3b2 somehow broke hardware transcoding. FWIW, I opened a bug report. @anthony0030 you in particular might want to check/comment as you can roll back to b1, and I can't as I moved from 7.2.4 https://product.unraid.net/p/7-3b2-breaks-hardware-transcoding-in-plex?b=unraid-os-bugs

OK, I removed the plugin, re-installed it, and made sure it was on v580. Rebooted. Doesn't appear to have changed anything. HW transcoding still isn't happy. I've included screen shots and diagnostics as well as my docker template, because hey, the problem could be me. tower-diagnostics-20260403-0816.zip

I'm having the same issue. Went through the upgrade to 7.3b2 and migrated to a spare nvme drive for booting. Everything appears to be functioning well. Found Plex wouldn't start. "docker: Error response from daemon: unknown or invalid runtime name: nvidia" Thats odd. The nvidia driver is installed. Set to v580 for my 1050. I can see the GPU in the Dashboard via the GPU Statistics plugin. Removed the nvidia variables and it starts AOK. So no immediate panic. I updated the plugin, and re-selected v580. Plex starts now with the NVIDIA_VISIBLE_DEVICES and NVIDIA_DRIVER_CAPABILITIES both set to all. However hardware transcoding isn't happening. Attached are my diagnostics. tower-diagnostics-20260402-1836.zip

This is an issue for a lot of us. The Continue button doesn't work.

I noticed there was an update to the plugin. Thank you for bringing it "back".

I have no idea how the file got reverted to default or something, but lo and behold I was having the same issue, checked the conf file and was like "that ain't right."

Yeah, the verification run passed with flying colours. Thanks!

OK, so the correction run found 6 errors, down from 12-15. I'm going to start the "verification" run without corrections. If any more errors are found I'll re-post diagnostics.

Ah I swear I turned off ram overclocking. Well, I'll turn that off and start the cycle again.

OK, ran with correction and 12 errors were found. Attached are diagnostics post correction run. Starting a no correction run to see if anything was actually fixed. tower-diagnostics-20231015-1751.zip

I've run a couple of parity checks over the last few weeks and the errors keep creeping in. Parity-Check 2023-10-13, 19:33:36 (Friday) 14 TB 1 day, 1 hr, 30 min, 29 sec152.5 MB/s OK 14 Parity-Check 2023-10-04, 10:07:22 (Wednesday) 14 TB 1 day, 1 hr, 22 min, 28 sec153.3 MB/s OK 12 Parity-Check 2023-10-02, 08:49:11 (Monday) 14 TB 1 day, 1 hr, 11 min154.4 MB/s OK 6 I'm using the Dynamix File Integrity plugin and just checked, and all files are not corrupted. I'm going to run another correcting check, and then to follow best practices after this is done I'll do another check without correction. Lets assume that the 2nd "verification" check still turns up parity errors. At which point in this operation would I collect diagnostics that would best help shed light on this situation?

Here's the fix:

I have tried it, we'll see in 3-4 days. That seems to be how long it takes for the network to wig out.

I posted a thread about this over a week ago. Crickets chirped. Exact same issue. Networking is fine, Plex is available, but Docker and Plugin checks are "unavailable" Here's the original post with DIagnostics. Updating to 6.12.2 didn't help. tower-diagnostics-20230707-0911.zip

Now here's an interesting one. Since updating to 6.12 periodically my unRAID server stops being able to access the internet. Usually takes 2-3 days. Dockers work fine, connectivity is AOK. But update plugins or check for docker upgrades? Checking connectivity ... No response, aborting! Anyone else experiencing this? tower-diagnostics-20230625-0835.zip

Well, just using counters seems to work. I spun down the drives, waited a few minutes, started a backup which spun up the Parity and Data disk(s). 15 minutes after it finished the system went to sleep. I'll monitor over the next few days and make sure my backups run and the system is asleep in the morning.

None of the above. However, I think it may be the s3 sleep plugin. I used the file activity plug in and saw nothing, as expected. Status monitors the hardware status of the device Counters monitors the read/write counters of the device I've changed the device activity monitoring from "Status" to "Counters" as this is my backup server. It basically gets woken at 2am, backups run with it as the destination, then when the drives go inactive for 15 minutes, it put the system to sleep. I've hit the big spin down button, and now I'm waiting.

Yeah, and I think I know whats going on, but I have no idea how to stop it: Mar 23 15:10:35 Backup SAS Assist v2022.08.02: Spinning down device /dev/sdd Mar 23 15:10:54 Backup emhttpd: spinning down /dev/sdf Mar 23 15:10:54 Backup SAS Assist v2022.08.02: Spinning down device /dev/sdf Mar 23 15:11:21 Backup emhttpd: read SMART /dev/sdd Mar 23 15:11:21 Backup emhttpd: read SMART /dev/sdf So as soon as they're spun down for some reason SMART is read and spins them back up again.

Hah, no its definitely the drives. I can click spin down forever, and they never do, not even for a second and then spin up. This is on a very bare bones server that I use for backups. It sits in S3 sleep until woken by my main Unraid server. Then 5 minutes later backups run. Then after 30 minutes of activity the drives should spin down, then 15 minutes later go back to sleep. The Toshiba SATA drives spin down nicely, and the SAS drives in my main server spin down, its just these particular odd drives.