Hoopster

mount -t tmpfs -o size=16g tmpfs /tmp/PlexRamScratch Mounts a RAM disk with a size of 16GB. You can use less. Some use as little as 4GB. I am not dedicating much RAM to VMs so I have 16GB to spare for transcoding.

This could be a problem. I used to have mine set up this way but without limiting transcoding RAM in some way, tmp will eventually fill up all available RAM completely especially if there are multiple transcoding sessions going on simultaneously. I also have 64GB RAM on my server but have limited transcoding to using 16GB RAM. I have this in my go file to limit transcoding to 16GB and to recreate the folder in RAM on reboot: mkdir /tmp/PlexRamScratch chmod -R 777 /tmp/PlexRamScratch mount -t tmpfs -o size=16g tmpfs /tmp/PlexRamScratch With this, the mapping in the Plex docker container is /transcode to /tmp/PlexRamScratch This forces Plex to reclaim space by deleting older transcoded bits that have already played rather than just waiting to delete them all when the entire transcode finishes.

There is a Contact Us link at unraid.net that will get you in direct contact with Limetech.

As long as you have single parity, array disk order is not important. unRAID tracks disk by serial number. If a particular drive used to be in slot 2 for example and is in slot 4 in a new config, that does not cause any problems for unRAID as long as the serial numbers are reported correctly. Serial numbers are usually messed up if the were previously or are currently connected to some type of RAID controller. The only real damage that can be done by doing a new config is to assign what was an array data drive as parity. That will wipe out the data on it.

The Config folder has your license, all settings configured in unRAID, plugin and docker container configuration if installed via Apps, user scripts, etc. Is this folder present on your flash drive? Not having it in a backup is a concern but it is more important that it is found on your unRAID flash drive. The Parity drive will not have a filesystem. If you are unsure which is the parity drive, you can use the New Config tool and assign all drives as array drives. When you start the array, one will show up as unformatted. DO NOT format it, that is the parity drive. Stop array and do new config again assigned the "unformatted" drive as the parity drive and the others as array drives.

In the config folder of the flash drive do you have a file called DISK_ASSIGNMENTS.txt? Alternatively, do you a recent notifications email (only if you set it up in notifications) with unRAID array health report? This will also show disk assignments by serial number.

In the BIOS boot order is your flash drive called UEFI:{brand of flash drive} or something similar? Some recent ASRock (and other brands as well) boards will only boot UEFI and not legacy. On your flash drive, if there is a folder named EFI- that means it wants to boot in legacy mode. To tell it to boot UEFI, rename the folder to EFI (remove the trailing - character).

That's the Plex container I am using and have no issues with remote access.

I am not saying this will resolve your issue, but, I did the following to keep my remote access stable: 1. Manually specified port 32400 (even though it is the default) in the Plex remote access setup 2. Turned off UPnP in my router (I manually forward all ports I need as UPnP is not always reliable and has some security issues - not saying it is flaky in your router but turning it off in mine has been the right call) 3. Set a port forwarding rule in my router for port 32400 to the local LAN IP address of my Plex server Remote access in Plex has been stable for months for me.

For many generation of Intel Core processors, the i3 supported ECC just like the Xeons. The 9th generation i3 linked by the OP does support ECC RAM. Beginning with the 10th generation i3, support for ECC RAM was dropped.

Yes, but you will need to use the New Config tool to assign other drives to the array. Other than that, your license, configuration, plugins and docker container settings will transfer over to a new system. Share settings may need to be tweaked if they were setup for certain disks in the old system. If you have VMs they may need be reconfigured based on the new hardware and anything you may have had passed through. For reference, I have swapped hardware (motherboard, CPU, RAM, SSDs etc.) four times using the same unRAID USB flash drive and HDDs.

What are the permissions on your Plex folder? I can access the Plex GUI no problem (192.168.3.110:32400) and it is on a VLAN separate from the subnet for unRAID. Here are the permissions I have on the Plex folder in appdata:

Those are your options with your motherboard. You can try CPU transcoding to see how it keeps up and go with a dedicated GPU if the CPU can't handle it. With CPU (software) transcoding, passmark scores for the CPU are important. Your i3 9100 has a passmark score of 6629. In general, 2000 passmarks are needed for each 1080p stream (forget 4K) you need to transcode plus 1500-2000 for unRAID overhead. With a passmark score of 6629, you can simultaneously transcode two streams and still have enough for unRAID to do its thing. If you put a supported Xeon in your motherboard, the E3-1245 V6 has a passmark score of 8684. That will give you three simultaneous 1080p transcoded streams + unRAID overhead. UPDATE: I incorrectly linked to the passmark score for the i3-9100 CPU when the CPU in question on the Supermicro X11SSL-F motherboard is the i3-6100. The passmark score for the i3-6100 is 4154 meaning only one transcoding stream is possible.

@Froberg As mentioned by @Taddeusz, motherboards based on the C232 chipset do not support QSV and iGPUs. Same with C242, C252, etc. You need the c2X6 chipsets for QSV/iGPU support. I have two motherboards in unRAID servers right now that are based on the C246 chipset and both have IPMI. QSV and the iGPU are supported in addition to the ASpeed chip for IPMI video either via a special BIOS to enable both or by settings in the public BIOS. There are some threads in these forums about the settings needed to enable both iGPU/QSV and IPMI on some Supermicro motherboards but that requires a board with the appropriate chipset which your X11SSL-F does not have.

Yep, that is the case. Monitor output is via VGA connector which is controlled by the ASpeed chip.

Mentioned on page 3 of this discussion:

iGPU bound to VFIO = no EDID has corrupt header/EDID block 0 is all zeroes errors in syslog. ASpeed bound to VFIO = EDID has corrupt header/EDID block 0 is all zeroes errors in syslog. The iGPU in the case of my servers appears to be the culprit.

Yep, looks harmless. Hopefully it can be suppressed if not eliminated in a future unRAID release. For now, I have rolled back to 6.10.3 on the always-on server. For testing purposes, I have left the backup server on 6.11.0 as it is powered on/off by script for various backups and doesn't spend much time powered on. No danger of the log filling up there.

Go to Settings --> SMB in the GUI and set Enable NetBIOS to Yes

Some packages may be fine as is; others may not. The issue is keeping the packages updated to work with the current version of Slackware (now 15 in unRAID) whatever that happens to be in a particular unRAID version. In the future, something that works now may not work with a new Linux kernel in Slackware. You do not have to modify the kernel or do anything fancy so it is hard to mess up. Just place the desire .txz packages in /boot/extra on the flash drive and they load when unRAID is booted.

Will likely need to roll back both servesr to 6.10.3 due to the EDID has corrupt header /EDID block 0 is all zeroes errors filling the syslog. Plugged in monitor does not help. Cannot blacklist iGPU and AST (IPMI) drivers as they are actively used. Others have reported this makes no difference anyway. medianas-diagnostics-20220926-1028.zip

I have a VGA monitor connected to my server. It does not stop the errors which hit the log every 2 seconds Sep 26 09:59:28 MediaNAS kernel: EDID has corrupt header Sep 26 09:59:28 MediaNAS kernel: EDID block 0 is all zeroes I have an AST (IPMI) on the server and iGPU in the E-2288G processor. I can't blacklist either as I use iGPU for transcoding and AST for KVM access to server via IPMI. Hopefully this gets fixed soon. The problem was not present in 6.10.3 which was running previously on the server. Same issue on my backup server which also has an iGPU and ASpeed chip for IPMI. No monitor is plugged into that server as it is in a closet in the basement. I guess I could try a dummy plug there but an attached monitor on main server does not prevent the errors.

Look in plugins/Nerdpack and open the NerdPack.cfg file in a text editor. Anything with a "yes" is a package you were loading via the Nerd Pack. For example: ipmitool-1_8_18="yes"

This one for Slackware 14.2 still works. ipmitool-1.8.18-x86_64-1.txz

This usually means that since the time you purchased a license and registered your flash device GUID that someone else has attempted to register the same GUID resulting in it being blacklisted in future releases. It is possible your unRAID flash device has a non-unique GUID. In this case, you were fine on the previous version but an upgrade triggered the blacklist on your flash device GUID. This may or may not be the issue in your case, but it does happen.