StevenD

No, sorry. I just don't have time right now.

Ive messed around with it and cant get it to properly compile. Unfortunately, I have no time to mess with it right now.

The SM 836TQ is a great chassis, and the only chassis that I use. You will want to get some SQ power supplies, if you care about noise. However, the X8DTH is ancient and inefficient. You would be better off finding a barebones chassis, and adding your own motherboard, or finding something more modern. As soon as prices and availability are better, Im dumping the rest of my X9s.

Yes, the mover does run overnight. Unfortunately, I cant disable it for a week. At the end of the day, it doesn't really bother me that the parity check basically takes a week. It was problem for a while, as I was having some crashing. I had to reboot everything to fix the crash, which of course, cancels the parity check. My RTX 4000 was overheating and disappearing from the bus. I have improved cooling and solved that issue.

I use the tuner plugin. I also only run it every other month. It runs from 10PM on the first Sunday of the month to 6AM the next morning, and runs for either 6 or 7 nights. Sometimes after 6 nights it has a couple of hours, or a couple of minutes. However, for some reason, with the tuner plugin, it seems to take longer than if I were to just let it run straight through. My parity checks also slowed down when I went from two HBAs for the array to one. But, I really wanted to install a GPU, so I needed to free up a slot. Now that I have switched to 40GbE networking, I can probably remove one of the 10GbE cards, install another HBA and split the array again. HBA prices (like just about everything else) has gone through the roof. I only paid like $240 for the 9400-16i.

My 16TB parity array finishes in about 48 hours.

Not for very long, since they are Seagate.

I wouldn't pass through a NIC. I get almost full 10GbE speeds using the virtual NIC. I can write to cache at over 800MB/s and 130-150MB/s to the array directly.

Did you pass through your controllers, or did you assign virtual disks? Those are ridiculous speeds.

Whenever I upgrade my cache, I ALWAYS use the CA Backup/Restore plugin. Its is way, way faster for backing up and restoring all the appdata. My appdata folder is about 300GB, most of which is Plex metadata. It does it in about 25 minutes.

From what I have read, its not transcoding media files, but Live TV fails to close the stream after you stop Live TV or even close the client. The devs have been working on it for quite some time.

@CS01-HS Thanks! Funny enough, I couldnt figure out why my cache drive was almost full this morning. I found a 445GB .ts file in the Emby appdata/transocde dir.

For me, its too slow and doesn't have enough resiliency. You are basically storing your VMs on a single disk. That being said, I haven't tried out any of the ZFS stuff in unRAID.

Thats a separate plugin

This.

I'm running unRAID virtualized under ESXI 7 with an RTX 4000, using @ich777 plugin. I don't recall doing anything special to get it to work. I do have these settings: pciHole.dynStart 3072 hypervisor.cpuid.v0 FALSE but I don't recall specifically setting them.

Looks like it didn't upload to Github at all. It should be there now. Sorry about that.

Also, have you reset BIOS to make sure nothing like memory speed was set directly?

That motherboard should support a single CPU in CPU1 and and a single DIMM in P1-DIMMA1. Is it possible the CPU is newer than the BIOS supports? I typically only buy RAM that is on the SM approved and tested list. Hynix HMA81GR7AFR8N-VK Samsung M393A1G40EB2-CTD Hynix HMA82GR7CJR8N-VK Hynix HMA82GR7AFR8N-VK Micron MTA18ASF2G72PZ-2G6D1 Samsung M393A2K40BB2-CTD Micron MTA18ASF2G72PDZ-2G6H1R

are both sockets populated? If using only a single socket, are you using the right one? Also, if you are using both, you must have RAM spread across both.

Updated for 6.9.0-beta25. Also updated the plugin to use libffi-3.3-x86_64-1.txz. I discovered that the package will not successfully build with libffi-3.3-x86_64-1.txz installed. I'm afraid this plugin may not survive much longer.

Sorry...somehow I never saw this. I will test it out this week and replace it in the plugin if it works ok.

@SCSI I have put quite a bit of time in this, and I just can't seem to make the message disappear using open-vm-tools 11.x.x. I reverted to 10.3.10, and the ioctl message only shows up four times upon intial startup or plugin install. I am going to see if the open-vm-tools maintainers will help with this, but I doubt they will. Someone else posted this error and they closed it saying you need vsock installed. We dont need it, so there is no point in trying to install it. I am pretty sure it would need a custom kernel, which is way above my head and not something I really want to maintain. This is apparently caused by a change in the 5.x kernel. The current version of the plugin (2020.07.11) will install open_vm_tools-10.3.10-5.7.7-Unraid-x86_64-202007111402.tgz on unRAID 6.9-beta24. I did not compile a new one for -beta22.