Gnomuz

That's pity signatures are off in the Bugs section, it's probably the section where they would be the most useful, as generally people describe their configuration in details in their sig ... At least it's the same for everybody, thanks for the replies

Back after a good night sleep, and I decided to give up redundancy on the cache and switch to XFS as a file system, following @jonathanm 's advice. So, as I'm a noob, I have a new question : what are the steps to convert my current BTRFS raid1 cache pool to a single-device XFS one ? Thanks in advance.

According to your syslog, I would say no ! 😂 For reference, here is my syslog in 6.9.0-beta35 with exactly the same setup as @nblom (local syslog server disabled, no remote syslog server declared, Mirror syslog to flash : Yes) Dec 15 17:31:45 NAS ool www[19853]: /usr/local/emhttp/plugins/dynamix/scripts/rsyslog_config Dec 15 17:31:47 NAS rsyslogd: invalid or yet-unknown config file command 'UDPServerAddress' - have you forgotten to load a module? [v8.2002.0 try https://www.rsyslog.com/e/3003 ] Dec 15 17:31:47 NAS rsyslogd: invalid or yet-unknown config file command 'UDPServerRun' - have you forgotten to load a module? [v8.2002.0 try https://www.rsyslog.com/e/3003 ] Dec 15 17:31:47 NAS rsyslogd: Could not find template 1 'flash' - action disabled [v8.2002.0 try https://www.rsyslog.com/e/3003 ] Dec 15 17:31:47 NAS rsyslogd: error during parsing file /etc/rsyslog.conf, on or before line 66: errors occured in file '/etc/rsyslog.conf' around line 66 [v8.2002.0 try https://www.rsyslog.com/e/2207 ] Dec 15 17:31:47 NAS rsyslogd: [origin software="rsyslogd" swVersion="8.2002.0" x-pid="20087" x-info="https://www.rsyslog.com"] start Quickly comparing, I would say there's undoubtedly a change between beta35 and rc1 : the number of errors in syslog jumped from 1 to 3 with the same setup. So it seems something has been tried, but I would leave the bug open at that stage if I were to decide. Thanks for changing the title @nblom , and let's hope it's the last time you have to do so, otherwise you'll have to automate this somehow ...

Thanks for reminding the difference between redundancy and backups @jonathanm . CA Backup was one of my first installed plugins, VMs are backed up daily to the array (Macrium Software for Windows, Timeshift for Ubuntu), the array has 2 parity drives, and a weekly backup of the array to external drives is scheduled. So I think belt and braces are in place, but any advice is welcome. My understanding of the cache usefulness is (when built with SSD(s) over a 2.5G network to workstations) : - performance for frequently accessed data (Vdisks, containers' data, ...), - fast-write temporary storage before the mover does its job overnight And that's why cache redundancy appears so important to me. I hardly imagine telling one of my users "Well, you know what ? You stored an important document at 5pm on my super secure NAS, but as a piece of hardware crashed at 10pm, your 8 hours of work have disappeared". I've been working for 2 decades in the capital-market industry IT departments, where a 5 minutes outage during market hours was simply not to be envisaged, whatever the cost. But maybe I have to lower my expectations now that my environment is more regular and budget-constrained, who knows 😉

Thanks for directing me to this relevant frightening thread. Well, I really don't like what I read ! I also understand from this thread that the issue is specific to BTRFS, which may explain why my test of trim over the HBA on an XFS-formatted SanDisk SSD was successful (?). To sum up, all options with my hardware components look like dead-ends or gambles : - downgrading my 9207-8i firmware from P20 to P16 (risky operation btw) would enable trim, but may also lead to "chaos" and data loss according to one of the posters. No thanks ! - switching the cache file system from BTRFS to XFS may enable trim, but then redundancy is not an option. I just can't imagine a single-device cache for the VMs' virtual disks and the containers' data ! - connecting back the SSDs to the AMD onboard controller would re-enable trim, but would also very likely trigger the "quite common" Ryzen issue I've already experienced 3 times, which itself may or may not be fixed by a future BIOS update and/or newer kernel. Another option would be to swap the SAS2 9207-8i out for a 9300-8i which seems to be the equivalent SAS3 model. That's another 100€ for a used one from somewhere in Asia (with all the risks incurred), or almost 250€ for a brand new one from Germany. If this can be avoided, my bank account will thank me ... To try and reach a conclusion, even a sad one, what would be according to you the overall impact of not trimming the cache pool until a miracle happens, i.e. Unraid proposes an alternative file system to BTRFS for redundant cache pools ? Thanks again 😉

You're totally right, the error appears, pointing to sdf (the device which went offline as you know), only when I run fstrim. But also, checking file system on sdf1 (btrfs check) yesterday evening reported a huge number of file system errors. Guess what, when I issue the same command this morning I get this result : root@NAS:~# btrfs check /dev/sdf1 Opening filesystem to check... Checking filesystem on /dev/sdf1 UUID: c74954f2-6961-434c-b5ba-d0155fd6602d [1/7] checking root items [2/7] checking extents [3/7] checking free space tree cache and super generation don't match, space cache will be invalidated [4/7] checking fs roots [5/7] checking only csums items (without verifying data) [6/7] checking root refs [7/7] checking quota groups skipped (not enabled on this FS) found 217076813824 bytes used, no error found total csum bytes: 18733168 total tree bytes: 410370048 total fs tree bytes: 298795008 total extent tree bytes: 87080960 btree space waste bytes: 96197597 file data blocks allocated: 2801561227264 referenced 167881072640 I don't know what "cache and super generation don't match, space cache will be invalidated" means and whether it's worrying or not, but this is completely different from what I got yesterday ... And the fstrim /mnt/cache still produces the same error, I just tried. Thus a previous question. The fstrim command does not report any error on sdc (the other member of the pool, the 840 Pro SSD) when trimming the pool, just on sdf (860 Evo). Does it mean according to you that trim works on sdc, and fails on sdf ? If yes, that would clearly point to the 860 Evo not supporting trim over the LSI HBA for whatever reason (firmware ?). I could then replace it with a 512GB 860 Pro (present 840 Pro equivalent) to have trim supported on both members of the pool. Remember I succeeded trimming a spare consumer grade Sandisk SSD Plus 2TB over the HBA, so trim support over the HBA is no longer questionable. But the major difference is this test SSD was XFS formatted not BTRFS, my mistake. So maybe BTRFS Raid1 is also the problem for trim support, not the SSD... I must admit I'm a bit lost with too many possible causes and hypothesis ... What would be the possible next steps ? Thanks in advance.

Hi all, To make a long story short, I'm in a situation where the cache BTRFS Raid1 pool is in an instable state, because one of the pool members went offline due to a known issue with the AMD SATA onboard controller. For those who'd need more context, please see my initial post and @JorgeB 's answers in this thread : I've already run scrub on the pool, no errors found, and also performed a full balance. Could anyone help me rebuild this cache pool composed of a 840 Pro 512GB (sdc) and 860 Evo 500GB (sdf), knowing that sdc is presumably clean, whereas sdf still generates a ton of errors when I run 'btrfs check /dev/sd1'. I'm not at all a BTRFS expert, I just want to force BTRFS to rebuild the raid1, just mirroring sdc to sdf. I hope my request is clear, diags attached if it can help. Thanks in advance. nas-diagnostics-20201215-0957.zip

Thanks, I just thought that following up on the initial issue would help the community understand the context and provide relevant answers. My mistake. So I'm going to open a thread in General Support to ask the very same question, perhaps with a reference to this (non-bug) thread, if it doesn't infringe any forum rule.

Changed Status to Closed

Changed Status to Open

I don't know who had the brilliant idea of marking this thread as "closed" after I reopened it, but I can confirm there's still an issue there. But again, as on another issue, perhaps "Closed" means "Open" or "Under review" for some around there, who knows ... Anyway, the extended smart test completed without error. Even with my very little understanding of BTRFS, I found a thread elsewhere and issued the command "btrfs check /dev/sd1", which reported many errors (output too long for here), among which "errors found in fs roots" I think the file system has been corrupted on this SSD due to the device going offline when still connected to the onboard controller. And I'm almost sure I will lose data if the clean SDD were to have any problem.... So now, how could I rebuild the raid1 pool with both SSDs assuming sdc is clean and sdf needs to be somehow reformatted ? Thanks in advance for your guidance and please do not bury this thread again.

As the IO error happened again with the cache SSDs connected to the onboard SATA controller, I decided to plug them in the spare trays and thus use LSI 9207-8i instead. As @JorgeB had told me, the SSDs were recognized by Unraid on reboot, and the cache was mounted properly. 'sdc' is the 840 Pro SSD which didn't report any error so far. 'sdf' is the 860 Evo SSD on which the IO errors occurred. I launched a fstrim to check the functionality. Here's the worrying result : root@NAS:~# fstrim -v /mnt/cache fstrim: /mnt/cache: FITRIM ioctl failed: Remote I/O error and syslog is less terse : Dec 14 19:48:57 NAS kernel: sd 9:0:4:0: [sdf] tag#9146 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=0s Dec 14 19:48:57 NAS kernel: sd 9:0:4:0: [sdf] tag#9146 Sense Key : 0x5 [current] Dec 14 19:48:57 NAS kernel: sd 9:0:4:0: [sdf] tag#9146 ASC=0x21 ASCQ=0x0 Dec 14 19:48:57 NAS kernel: sd 9:0:4:0: [sdf] tag#9146 CDB: opcode=0x42 42 00 00 00 00 00 00 00 18 00 Dec 14 19:48:57 NAS kernel: blk_update_request: critical target error, dev sdf, sector 973080532 op 0x3:(DISCARD) flags 0x800 phys_seg 1 prio class 0 Dec 14 19:48:57 NAS kernel: BTRFS warning (device sdf1): failed to trim 1 device(s), last error -121 That's where I need help. I understand, but maybe I'm wrong, that the trim operation succeeded on sdc (840 Pro), which would indicate the problem lies specifically with sdf (860 Evo). As the physical connection are completely different now (SATA cables from onboard controller to SSDs -> SSDs in hot-plug trays), the SATA cables are not the problem. I start wondering whether the 860 Evo SSD itself doesn't have an issue. Or maybe I should try to reinitialize it and rebuild the Raid-1, but I must admit BTRFS is really cryptic for me ... I launched a short SMART self-test which completed without error. I now launch an extended self-test (polling time 85 min), we'll see ... Any help and idea will be appreciated.

As I had read contradictory information on this matter, I hot-plugged a spare cold storage SanDisk SSD Plus 2TB in a spare tray. This SSD seems to have the required features, even if DRZAT is called "Deterministic read data after TRIM" : root@NAS:~# hdparm -I /dev/sdj /dev/sdj: ATA device, with non-removable media Model Number: SanDisk SSD PLUS 2000GB Serial Number: 2025BG457713 Firmware Revision: UP4504RL Media Serial Num: Media Manufacturer: Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0 Standards: Used: unknown (minor revision code 0x0110) Supported: 10 9 8 7 6 5 Likely used: 10 Configuration: Logical max current cylinders 16383 0 heads 16 0 sectors/track 63 0 -- LBA user addressable sectors: 268435455 LBA48 user addressable sectors: 3907029168 Logical Sector size: 512 bytes Physical Sector size: 512 bytes Logical Sector-0 offset: 0 bytes device size with M = 1024*1024: 1907729 MBytes device size with M = 1000*1000: 2000398 MBytes (2000 GB) cache/buffer size = unknown Form Factor: 2.5 inch Nominal Media Rotation Rate: Solid State Device Capabilities: LBA, IORDY(can be disabled) Queue depth: 32 Standby timer values: spec'd by Standard, no device specific minimum R/W multiple sector transfer: Max = 1 Current = 1 Advanced power management level: disabled DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=120ns IORDY flow control=120ns Commands/features: Enabled Supported: * SMART feature set Security Mode feature set * Power Management feature set * Write cache * Look-ahead * Host Protected Area feature set * WRITE_BUFFER command * READ_BUFFER command * DOWNLOAD_MICROCODE Advanced Power Management feature set SET_MAX security extension * 48-bit Address feature set * Device Configuration Overlay feature set * Mandatory FLUSH_CACHE * FLUSH_CACHE_EXT * SMART error logging * SMART self-test * General Purpose Logging feature set * 64-bit World wide name * WRITE_UNCORRECTABLE_EXT command * {READ,WRITE}_DMA_EXT_GPL commands * Segmented DOWNLOAD_MICROCODE unknown 119[8] * Gen1 signaling speed (1.5Gb/s) * Gen2 signaling speed (3.0Gb/s) * Gen3 signaling speed (6.0Gb/s) * Native Command Queueing (NCQ) * Phy event counters * READ_LOG_DMA_EXT equivalent to READ_LOG_EXT Device-initiated interface power management * Software settings preservation Device Sleep (DEVSLP) * SANITIZE feature set * BLOCK_ERASE_EXT command * SET MAX SETPASSWORD/UNLOCK DMA commands * WRITE BUFFER DMA command * READ BUFFER DMA command * DEVICE CONFIGURATION SET/IDENTIFY DMA commands * Data Set Management TRIM supported (limit 8 blocks) <------ * Deterministic read data after TRIM <------ Security: Master password revision code = 65534 supported not enabled not locked not frozen not expired: security count not supported: enhanced erase 2min for SECURITY ERASE UNIT. Logical Unit WWN Device Identifier: 5001b444a7732960 NAA : 5 IEEE OUI : 001b44 Unique ID : 4a7732960 Device Sleep: DEVSLP Exit Timeout (DETO): 50 ms (drive) Minimum DEVSLP Assertion Time (MDAT): 31 ms (drive) Checksum: correct I mounted the drive with UD, and fstrim seems to work fine with my SAS2308 HBA (IT mode firmware 20.00.07.00) : root@NAS:~# fstrim -v /mnt/disks/WKSTN/ /mnt/disks/WKSTN/: 1.8 TiB (2000201273344 bytes) trimmed So maybe something has changed with the latest versions of the drivers ? That's beyond my technical skills, but I just wanted to report for others who would wonder about TRIM support behind this HBA/firmware couple. Thanks again for your help @JorgeB !

Hum, I haven't upgraded to RC1 because I use telegraf / smartctl to monitor the system and hate the idea of having all my disks spun up 24/7, so I couldn't re-test this feature. But it does look like the very same error messages we've been reporting since August, so I understand we should have read "fixed in next release" as "fixed in a future release coming soon™". Just a matter of terminology. Let's be fair however, the release notes state : rsyslog: fix broken "Mirror syslog to flash" What @nblom tried to setup is much smarter than writing syslogs to the flash drive : enable local syslog server, setup to write on a local share, and self-point the server to this "remote" syslog server. Advantages are obvious, there are no potential massive writes to the flash drive, and the Unraid server is available for other machines and network devices as a remote syslog server. But the "Mirror syslog to flash" is another option. Maybe this one works in RC1. Anyone tried ? Even if that works, let's be explicit, the bug should not be closed, as other options are still faulty... In the meantime, the only way to have persistent logs across reboots or crashes is to have another 24/7 machine as a remote syslog server. Guys, I'm a geek, but my wife still prevents me from turning the lounge into a datacenter. And I don't own my electricity company, I pay my bills... But I swear I will never again argue against this long lasting bug being classified as "minor". Communication is easy once you have agreed on the generally-agreed meaning of words, but I'm afraid we'll never reach that level of mutual understanding... PS : btw @nblom, I would suggest to amend the title of the thread to "[6.9.0-BETA25] THROUGH [6.9.0-RC1]". Who knows, it may draw minimal attention soon™

I enabled View signatures under Account Settings > Signature. I also filled in my own signature describing my configuration as accurately as possible, within the limit of 5 lines of text (no image). Obviously that can help when I raise any support request. Sometime I can see other's signatures as well as mine at the end of the posts, but most of the time I see no signature at all, including mine. I use Chrome Version 87.0.4280.88 (64 bits). Do I miss something obvious, or is it a known issue of the forum ? Thanks in advance for your replies. PS : as usual, when reporting a random issue, it disappears. After submitting my post and editing it, I can now see my sig ! 👿 PPS : I can see signatures (including mine) on this section of the forum, but no signature at all in the "Prereleases" section I'm active on. Maybe a per section setting ?

Thanks, but why will I lose trim support ? You mean trim will not work if I connect SSDs to the LSI HBA (IT mode) instead of the buit-in SATA controller ? I was aware you can't trim SSDs when they belong to the array. But my understanding was LSI HBA 9207-8i (SAS2308, FW 20.00.07.00) like mine do support trim when in IT mode, provided the attached SSD(s) have both 'Data Set Management TRIM supported (limit 8 blocks)' & 'Deterministic read ZEROs after TRIM' enabled. I just checked with hdparm -I on my SSDs, both Samsung 840 Pro and 860 Evo have these two features enabled, lucky me for once 😉. So I think it should work fine in my case. I insist because for me, possibly losing the trim feature is not really a small price to pay, even against greater stability, especially on a cache drive which is often written to when transferring data from workstations to the NAS and this data is then moved to the array by the mover overnight. From my understanding, it's typically a use case where trimming an SSD does make a lot of sense.

Thanks for the reply. I'm on the latest version of BIOS, which unluckily is not brand new on this MB (Agesa 1.0.0.6). BIOS releases by AsrockRack are rare ... As for IOMMU, it is enabled. I understand it is necessary, because I have a GPU with the new Nvidia driver plugin to use it in containers, and I also pass it through to a VM sometime (containers then disabled, of course). For a newer kernel, I'll have to wait for RC2, as I have telegraf running and using smartctl, and I really don't like the idea of having my 6 HDDs spun up 24/7. If I understand well, the problem arises because the SDDs are connected through the built-in SATA AMD onboard controller. I may have an option then, as I have an LSI HBA for the 6 HDDs, and two spare trays in the HDD cages. So I could plug the two SSDs in the spare trays and thus have them connected through the HBA. Is it a possible approach and if yes how should I proceed without any loss of data on the cache ? Thanks in advance.

Thanks for your reply, as usual. I'll try to boot Unraid in GUI mode tomorrow, it's late in here. What I want to do with nvidia-settings is overclock the GPU, while undervolting it (with 'nvidia-smi -pl XXX' which works) to diminish the power draw and maintain the folding throughput. nvidia-settings works in command mode, and you can do the same as in GUI mode, esp. apply an offset to your clocks, i.e. overclock, provided you have the famous "Coolbits" set to 28 in xorg.conf. The main issue is nvidia-settings needs to run in an X server. Just to be sure, I have an integrated GPU on the IPMI motherboard (which is used by Unraid and is the primary graphics in BIOS), and the 3060 Ti with no screen attached just computing/transcoding. If I get it well, I should attach a monitor to the 3060Ti, change the primary graphics card in BIOS, and boot Unraid in GUI mode. We'll see ... I don't know what graphical environment Unraid uses when in GUI mode, and thus don't know how to tweak xorg.conf, if it exists. I had thought of another approach, using a container like your "debian-buster-nvidia", which on paper has everything I would need : the driver is installed, the graphical environment exists, so nvidia-settings should work from inside the container, either in cli or graphical mode. And the tweaks applied from there would maybe have an effect on the card itself, and thus on processes launched by another container. But it's mostly speculation at that stage, and very likely wishful thinking 😉 I've found many over-complicated and unsure approaches around when it comes to overclocking an Nvidia GPU on a headless server not running an X server. The best I've found so far is https://gist.github.com/johnstcn/add029045db93e0628ad15434203d13c#overclocking (in the context of coin mining, but folding has the same requirements if not objectives...). But as we can't install much nor persist settings across reboots in Unraid, I quickly reach a dead-end on my side 🙁

Hello, As already reported, I've successfully setup a RTX 3060Ti FE with this plugin and above all the help of @ich777, and it's properly used in 3 containers (telegraf for GPU monitoring, Plex for hw transcoding and Folding@Home for folding 24/7). Now I'd like to go a bit further and optimize the power consumption vs folding ratio. I've read in numerous forums about folding that the way to go was to undervolt and overclock the GPU to get the same computing power with less power drawn. Helping medical research (against Covid-19 among others) when the server is idle is ofc great, but if I can limit my electricity bill with the same output, that's also fine 😉. Undervolting is not an issue, with the 'nvidia-smi --power-limit=XXX' I can set the power limit anywhere between 100W and 220W with this card, default being 200W. But of course, when I lower the power limit, the built-in algorithm lowers the GPU and memory clock frequencies accordingly, which produces less science (as they say in F@H forum). The only way I've found to overclock an Nvidia GPU under Linux command-line is through the nvidia-settings utility, which is built-in with the drivers, the commands to overclock being : nvidia-settings -a '[gpu:0]/GPUGraphicsMemoryOffset[3]=50' #offset of +50Mhz on GPU Clock nvidia-settings -a '[gpu:0]/GPUMemoryTransferRateOffset[3]=50' #offset of +50Mhz on Memory Clock The purpose is to compensate for the clock frequencies lowered by the power limit algorithm with a positive offset to get the same computing power with less power drawn. As always, the challenge is to find the sweet spot between power consumption, computing power and stability. But I've already reasonably overclocked CPUs and GPUs, and I'm patient, so this is not a problem. Unluckily I didn't reach so far, because issuing the nvidia-settings ... command produces the following error : root@NAS:~# nvidia-settings nvidia-settings: error while loading shared libraries: libX11.so.6: cannot open shared object file: No such file or directory After checking, this nvidia-settings utility requires a X11 server on the machine. Moreover, the xorg.conf file must contain these clauses Option "AllowEmptyInitialConfiguration" "True" Option "Coolbits" "28" to have an access to the clock offsets through nvidia-settings. Of course I understand Unraid OS does not come with, and does not need btw, any graphical environment, and that's why the utility throws an error. And it's really a poor design choice by Nvidia to require a graphical environment to fine tune the GPU on a headless server under CLI. I think nvidia-settings is basically a graphical utility to tune the nvidia drivers which accepts CLI commands (see https://forums.developer.nvidia.com/t/overclock-gpu-at-lower-voltages/139326/2 for instance). Anyway that's the way it seems to be, unless I missed something... All that could work fine if I ran F@H in a Linux VM with the GPU passed-through, but I'd prefer not to lose GPU computing performance due to the virtualization overhead and above all I would lose the ability to use the GPU in containers, and thus the whole interest of this great plugin... So I raise the question to the community, as my technical skills enable me to understand the root cause of the dead-end, but sadly not to find a solution by myself 🙁 Thanks in advance for your ideas and feedback.

Hi all, I'm back on this issue. I had the opportunity to reboot and thus test the usbreset program @SimonF kindly compiled for me. Bad news, although highly anticipated for me. The software reset by usbreset does not work : - after the reboot without unplugging the UPS, apcupsd had the usual crazy information - I stopped apcupsd - I launched usbreset which did its job ("reset full-speed USB device number 2 using xhci_hid") - I relaunched apcupsd, still faulty - The usual unplug/restart daemon/replug did the job, as expected. As already stated, the major difference with a physical unplug/replug action is that the device number changes. I have the feeling the daemon then sees the UPS as a brand new one, and restarts dialog from the very beginning. I now have to admit my technical skills as well as my patience have reached their limit on this issue. As a reminder, the "latest" release of apcupsd is dated May 2016, and my UPS is brand new (product launched late 2019). I didn't check, but it's possible, if not likely, the ModBus protocol has evolved in the past 4 years and a half (!), and my issue may be some kind of incompatibility between a non-maintained critical package as apcupsd and an up-to-date firmware in the UPS. In May 2016, the latest kernel version was 4.6. I didn't take time to go through the release notes, but it's reasonable to think the USB management has "slightly" evolved in the kernel since then, due for instance to USB 3.2 appearance in 2017. And I think many other possible causes could be found for explaining the malfunctioning of an obsolete low-level software with up-to-date hardware and firmware. So, thanks for all the help from community members, but I think I definitely need @limetech on this one, as UPS management is a built-in feature of Unraid, supported as such by Limetech, even if the maintenance of the underlying open-source software seems to have stopped mid-2016. Of course, I'll be more than happy to participate in the debugging of this OS functionality, for the benefit of all existing and future Unraid users owning a similar common UPS model. Thanks in advance for your attention and help.

I suspected H.265 was the problem, and you understand it correctly. Your other mp4 containers very likely contain streams with Maxwell compatible codecs, i.e. not H.265. As a piece of information, second-hand Quadro P2000s are rather easy to find, don't cost arm and leg, and are powered only by the PCI-E slot (75W), no extra power cable. I don't know where you live, but here in France I recently bought one, brand new from an Dell workstation where it was immediately replaced by a more powerful GPU, for 200€.

Just to let everybody know and follow up on my previous posts, I managed with the precious help of @ich777 to get my brand new Nvidia RTX 3060 Ti to be recognized and fully operational under Unraid 6.9.0-beta35 with the Nvidia driver plugin. I was lucky enough to get one of very few Founders Edition cards available here in France. Now the GPU is bravely folding proteins to help research against covid-19, running circa 6 times faster than the P2000 I had so far, with a power draw of 190W vs 75W ! I wanted to share this success with the whole community, and let's push Unraid forward alltogether !

Hi @Whatupdays, mp4 and mkv files (among other formats) are nothing but containers for video and/or audio streams. What is key to know why such or such stream is hardware transcoded or not by your GPU is the codec of the video stream inside the container. Under Windows you can use a tool like MKVToolNix to know exactly what the codec of the video stream is in your mkv, mp4, avi, ogg, ... container file. Then we'll certainly be able to understand why the video stream is not hardware transcoded by Plex. Having a look at https://www.elpamsoft.com/?p=Plex-Hardware-Transcoding , I noticed that the GeForce GTX980 (Maxwell 2nd Gen architecture) does not support H.265, which may explain your issue. It's also software limited to 3 simultaneous sessions. As for Quadro P2000 (Pascal architecture, the next one), it does support H.265, and has no sessions limit. So yes, transcoding capabilities of a P2000 are way superior to GTX980 for a Plex server.

Thks for the quick reply ! I hadn't understood @limetechwas the driver provider, so my question was more for them, I think. And yes, I would really like to test the card, just to check whether it's DOA ot not, so I'm ready to try the "hack" you seem to propose.