plunderisley

Thanks for checking. I'll keep an eye out on the docker container and see if any more out of memory messages pop up.

Attached.

I tried the reboot and it did reboot (unclean apparently) but its working fine now. I stopped the bambu docker (its the 3d printer one) from booting up. Only odd message I received when rebooting (well other than the unclean shutdown and to do a parity check) is: Cache pool BTRFS missing device(s) CT1000P1SSD8_20512C63F770 (nvme0n1) But after I entered the password and the array started, it shows fine in the web ui (normal operation, 0 errors, SMART 0 errors) so IDK if it's an error because the array wasnt unlocked yet or something else....

I updated to 7.3.1 some weeks ago and all seemed well. The other day I added a share and tried to set the SMB users and it wouldn't save. I tried to do a reboot, but I can't stop the array. Attached are the diagnostics. I don't want to force a shutdown if it'll cause issues cause I can still access the server now. /usr/local/sbin/mdcmd stop /usr/local/sbin/mdcmd: line 35: echo: write error: Device or resource busy /usr/local/sbin/mdcmd stop /usr/local/sbin/mdcmd: line 35: echo: write error: Device or resource busy

hmm not sure. How can I check if its the audio? It shouldnt be skipped as I marked it to transcode even if same format.

I had a few movies transcode to H265. I noticed that when the transcoding runs, the CPU cores are maxed out but nothing is happening on the GPU side (even though I can see unmanic loaded into the GPU). I did set the --runtime=nvidia and the correct UUID. In the plugin for transcoding, it does see the GPU. But it doesn't seem to use the GPU. How can I fix this? Also I noticed the transcoded quality isn't great. GPU is a GTX1080 8GB Under global plugin settings: Standard config mode max input stream buffer 2040 video codec - HEVC/H265 force transcoding checked NVENC-hevc_nvenc The nvidia device selected HW decoding - NVDEC/CUDA - use GPU hardware Quality - P5 Tune - HQ Profile - Auto Encoder ratecontrol - Auto keep same container checked

Maybe its some bug in the 7.2.3 version? I could run a parity scan again in a few days and see if it catches anything, but I'm not sure if that's worth it to stress out the drives again (given each parity check is 20TB)

Yup. syslog.log I read the first post on that unclean shutdown and changed the disk settings from 90 to 420sec and VM to 300sec. It does make sense, given I have a ton of docker containers running (though when I did run the scan, I only had 2 containers up and rest were stopped as not to interfere with the parity check)

Attached are: diagnostics that I grabbed when I started the write correction (after the parity scan without write correction and no reboot).zoidberg-diagnostics-20260130-0006.zip the diagnostics after the write correction finished.zoidberg-diagnostics-20260131-1312.zip I shutdown the server, opened it up to check and re-seat the SATA cables, and booted it up. I got a unclean shutdown detected (no idea why, as I pressed the shutdown button on the main web ui and it did say it shutdown). I attached those diagnostics too. zoidberg-diagnostics-20260131-1404.zip I'm not sure if I need to do another whole parity scan, as I already did 2 and the previous 1375 errors were fixed.

Shoot, already started the write correction. I did save a diagnostic just now (7 sync errors corrected, 845GB/4.2% completed) and I'll do one once it'll be done sometime tomorrow night/next morning.

The parity check completed. Parity Check Tuning Manual Non-Correcting Parity-Check finished (1375 errors) Elapsed Time 1 day, 8 hr, 56 min, 9 sec, Runtime 1 day, 8 hr, 56 min, 9 sec, Increments 1, Average Speed 168.7 MB/s I'll run a correcting parity check now and fix those errors. It seems the issue was probably caused by either a controller issue or some issue with AMD Ryzen and unRAID (there was some issues iirc with those).

Okay. If it happens again, I'll do a diagnostics before I reboot. (it was a panic shutdown as I've never seen that before) Right now its 1.5hrs into a parity-check (5.7%) and 7 sync errors found (in the beginning of the scan). The SATA controller is on the motherboard.

memtest I've done 2 months or so ago when I added 2 additional sticks and it passed fine (did multiple passes over it to make sure it was good). I'm using the XMP profile that showed in the BIOS for the RAM sticks. DIMM 0: Unknown CMK16GX4M2A2666C16, 8 GiB DDR4 @ 3200 MT/s DIMM 1: A-DATA Technology AX4U320016G16A-BB10, 16 GiB DDR4 @ 3200 MT/s DIMM 0: Unknown CMK16GX4M2A2666C16, 8 GiB DDR4 @ 3200 MT/s DIMM 1: A-DATA Technology AX4U320016G16A-BB10, 16 GiB DDR4 @ 3200 MT/s I remember I did change the c-state in the BIOS back in May or June (?) when I was first setting up the server as I had problems with it. Since then it has been running fine. Unless somewhere it lost the setting or it was never configured correctly.

Oh I do have that now once the array is up. syslog.txt

Multiple cables.