Corvus

I see. How do I find the Plex temp folder?

I don't think so. How do I check? If that were the case, wouldn't this be happening all the time, as I usually have multiple users streaming off my server remotely every day?

I'll do it after the parity check finishes tomorrow. In the meantime, can someone please tell me how I could find out how this happens?

Thanks for the tip. However it's currently greyed out for me so I'm not able to enter any value. Could it be because the system is currently performing a parity check (after reboot)?

Hey guys, This is the second time this has happened. The first time, I shrugged it off as an anomaly - maybe a rogue process or docker I forgot to turn off. However, this time, I have nothing out of the ordinary running. I woke up this morning to find notifications on my Unraid web UI saying: Unraid Cache disk disk utilization: 17-01-2024 07:13 Alert [NAS] - Cache disk is low on space (91%) SanDisk_SDSSDHP256G_132803400467 (sdf) Unraid Cache disk disk utilization: 17-01-2024 07:15 Alert [NAS] - Cache disk is low on space (92%) SanDisk_SDSSDHP256G_132803400467 (sdf) Unraid Cache disk disk utilization: 17-01-2024 07:17 Alert [NAS] - Cache disk is low on space (94%) SanDisk_SDSSDHP256G_132803400467 (sdf) Unraid Cache disk disk utilization: 17-01-2024 07:18 Alert [NAS] - Cache disk is low on space (95%) SanDisk_SDSSDHP256G_132803400467 (sdf) Unraid Cache disk disk utilization: 17-01-2024 07:19 Alert [NAS] - Cache disk is low on space (96%) SanDisk_SDSSDHP256G_132803400467 (sdf) Unraid Cache disk disk utilization: 17-01-2024 07:20 Alert [NAS] - Cache disk is low on space (98%) SanDisk_SDSSDHP256G_132803400467 (sdf) Unraid Cache disk disk utilization: 17-01-2024 07:21 Alert [NAS] - Cache disk is low on space (99%) SanDisk_SDSSDHP256G_132803400467 (sdf) Unraid Cache disk disk utilization: 17-01-2024 07:23 Alert [NAS] - Cache disk is low on space (100%) SanDisk_SDSSDHP256G_132803400467 (sdf) This was followed up by another notice saying: 'Notice [NAS] - Cache disk returned to normal utilization levelSanDisk_SDSSDHP256G_132803400467 (sdf)' at 08:25. I'm guessing this was Mover doing its thing. My cache is 2x 256 SSDs in RAID_0 making up 512GB total. Right now, the Cache is sitting on 223GB free. Every time I've noticed that the cache hits 100%, my dockers fail to work until I completely reboot the server. I've only just learned about the Disk Activity plugin, so I unfortunately can't rely on that (unless it happens again soon). The only Dockers I had running were Plex, transmission (with no torrents pending or downloading), Radarr, Sonarr, nzbget, bazarr and tautulli. I've attached my diagnostics (I'm yet to reboot the server, however will do so after I post this). How can I see what was responsible for temporarily eating all my cache, and what was (ostensibly) writing to my array? Please be clear and use step-by-step explanations, as I'm a noob and don't know my way around Linux. Thanks for any help. nas-diagnostics-20240117-1634.zip

How do I do that?

Hey all, So I logged into my server and noticed it had started a parity check. When I looked at the uptime, I noticed it rebooted 10 mins previously. There was no electrical outage, and it's constantly connected to a UPS. I got the MCE check system notification and it told me to install MCElog from NerdPack, although I know this has been depreciated. I tried installing NerdTools, but I couldn't find MCElog in there. Where do I find it? Here's my diagnostics. Can anyone shed some light on what's wrong? nas-diagnostics-20230829-0054.zip

Anyone??

Hey guys, So let me put the backstory into point form. - I have a BlueIris CCTV system running on another machine with no dedicated GPU. - I have outsourced the AI recognition to my Unraid box because it has a GPU. - I use CodeProject.AI, and since they don't have an official docker which supports Nvidia GPUs, I followed the advice on this thread (CodeProject AI GPU on unRaid : unRAID (reddit.com)) to use a Deepstack docker as a template and make it into a CodeProject.AI docker running with my GPU. - Everything is working flawlessly. - Few days later, started noticing the Docker utilization warning going up by 1 percentage point per day starting from 75%. - Warnings stopped at 84%. - 5 days later, got a warning that it has now jumped to 100%. - Paradoxically, all my dockers still work flawlessly (even CP.AI). - Checked Docker container sizes: Total is '18.4 GB', despite my docker image size being 30 GB. What's going on? I know it's almost certainly something to do with the CP.AI docker I made, however it doesn't point to any directories on my system and Docker itself is reporting just over half of its capacity is used. Not sure if this is relevant, but I've also got a notification saying that CodeProject.AI-Server-GPU needs updating, which is weird because I essentially created the docker. If I press update, will it revert back to the Deepstack docker? I also ran 'Fix Common Problems' plugin today, and nothing seems out of the ordinary. Here are my logs: nas-diagnostics-20230220-0008.zip Where do I go from here?

Yeah you're right. It's now showing 91MB/s @ 80% complete. I'm guessing it will take faster to finish the last 20%?

nas-diagnostics-20221219-2157.zipHere you go!

Ok so a new development. I logged onto my NAS this afternoon, and now the old parity drive has a grey square next to it. When I hover over it, it says 'new device, in standby mode (spun down)', despite the fact that it also says 'Reading' in the status, and the fact that I've already set its spin down delay to 'never'. Despite this, it's gone up a percentage point since then, so it looks like something's still happening. The new parity drive is writing *something* at a super slow speed, but Unraid is now showing the 'read' speed of the old parity drive to be stuck at 0.0 B/s. How is Unraid writing data to the new parity drive when it's not reading the old one - or any drive for that matter? P.S. When I click 'spin up all', literally nothing happens.

So if I understand correctly, what you are saying is that the parity process keeps sending the spin down command, but since the disks keep receiving read commands, the disk keeps rapidly alternating between the spin down/up states, resulting in low transfer speeds? If true, this sounds alarming to me. Wouldn't this rapid, constant switching due to conflicting information put heavy stress on the disks?

Yes I do. Does this open my options?

That's what I'm saying. The drives aren't even spun down. Every time I look at them, they're active anyway. So this will achieve nothing, *and* I'll have to start over. So there's nothing else I can do? No idea what caused this?