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.

Okay. My thought here is if this is a hardware issue (say motherboard is dying or something else), and the parity check goes crazy again, I can then replace the motherboard or psu as I'd assume that would be the cause (unless Im missing out on something)

Okay. I got the array up. I'll stop all the docker containers to make sure nothing is running in the background. Should I do a write correction parity-check (assuming that is what you meant) or to be safe first do a check parity before doing a write corrections one?

I'm a bit of a noob with unraid still. Assuming both disks are OK and unraid parity check just went crazy (who knows if it was a controller mobo issue, or some docker container also trying to do something the same time and messed something up as I am running it on AMD), what would be the exact steps to do the new config and get this back up online?

zoidberg-diagnostics-20260128-1058.zipzoidberg-diagnostics-20260128-1050.zip Also, all this happened during a parity scan. I'm leaning more towards a failure of the controller or some motherboard issue.

Rebooting gives me this No idea what to do now or how to proceed. I don't believe 2 drives failed at the same time. Added the diagnostics zoidberg-diagnostics-20260128-0205.zip

A parity check (the quarterly one) started running and about 20% in I got a notification os multiple drives errors and failing. I have no idea how this happened or what could have caused it. Everything has been running fine now and I dont see how every drive could fail like this. I stopped the array and it looks like this: This would be absolutely catastrophic if all the drives failed. What can I do to try and fix this or diagnose the problem?

Same problem for me too.

I think I follow now - any variables I add (such as the file size, date) all must be met to move the files. So if I turn off all of those other variables and just leave the % of cache used, then it should trigger, I'm guessing.

Ahhh, so the mover wont run if the other criteria are met if the schedule is set differently? I have it set hourly - every 8hrs. Last time it hit the 8hr mark, it ran but moved 0 items. 23-05-2025 08:00 Unraid Status Mover Tuning Notification A total of 0 files representing 0B were successfully moved/synced by Mover Tuning plugin. normal

See a few posts above - its set 70% full to move and then move all at 75% full. So me getting an alert that the cache is over 80% means that neither triggered. I did that and when I had the mover set to follow the tuning rules, it moved nothing.