plunderisley

Just to post an update: I did a full BIOS update, re-did the settings in the BIOS for the Ryzen CPU (cstate and other recommend changes) and also lowered the max TDP of the CPU. Waited 14+ days and did a parity check (last one was months ago). Finished with 0 errors. Seems it's stable now. Maybe the BIOS version had issues.

I'll update the BIOS to the latest version and go through the c-state fix info again and configure it. I did a memtest86 a few months ago and for about 24hrs of running there were no issues. All the other attached devices seem to be fine. The stuck docker container on a boot loop was before the update.

Attached are the syslog for this month. I don't see anything there of any mention of the last night (well would have been around 4am 4th Aug) server lockup. I'm quite sure I did all those c-state changes before but I will double check. Sunday morning the docker containers update. I did the 7.3.2 update sun afternoon or evening time. It is a 5800x Ryzen 7 and a ASRock X470 mobo.

I updated to 7.3.1 a month or so ago and the server was running fine. A few days ago I patched it to the 7.3.2, rebooted fine and all worked. Last night, the server seemed to lock up and I was unable to SSH in to reboot it, and had to reset it (unclean shutdown). No idea why. the diag are attached.

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).