dyno

That's great news! Thanks!

The OOM errors are due to a qbittorrent bug that occurs when having multiple Qbittorrent webUI sessions open simultaneously on the same IP address. I've already created a bug report on qbittorrent's github repo. I went ahead and remove Cache Dirs entirely. That has fixed the issue of WebUI lockups. However, I still have a strange issue where a remote SMB share becomes unresponsive after being idle for a period of time (an hour or so). It still requires me to restart the remote SMB server to fix the issue. This is a fairly long-standing issue for me, fwiw. It's occurred since at least Unraid 6.10.

I'd suggest making a bug report on Github as well. The more reports they get, the more likely they will be to address the issue.

I'm having an issue with Remote Shares causing the WebUI to hang and be completely unresponsive. This occurs after several hours if I forget to unmount a remote SMB share. Previously, it would just cause Krusader to lock up, but now it also locks up the WebUI. The only way to resolve the issue is to turn off File Sharing at the remote server. That fixes the issue in Unraid immediately. But it's really pesky and has only gotten worse recently. I think a recent update to this plugin has only exacerbated the issue. Diagnostics attached. galactica-diagnostics-20240529-1821.zip ud_diagnostics-20240529-181432.zip

After some additional testing, it appears that the issue is indeed related to having multiple WebUI sessions open simultaneously. Check out my issue on Github. Qbit Memory Leaks - GitHub

So I figured out the cause of my issue. The .torrents in my qbit instance had all been migrated from a Debian qbit instance, along with their .fastresume files. This was done to avoid a recheck. For some unclear reason, this was the cause of my memory leak issues. So I created a new container, added all the .torrent files to it and then re-checked all of them. Since then, I’ve had no issues with memory leaks. I also made an issue in the qbit GitHub repo. Regardless, this doesn’t seem to be an Unraid issue. It’s definitely a qbit issue.

This plugin works great for me, but I have noticed one strange issue regarding Fan Control. Specifically, I cannot control one of my fan headers from Fan Control. Fan Controls lists: FAN12345 and FANA. However, FANB is missing. I can see sensor data for FANB just fine, but it cannot be controlled via Fan Control in the plugin. How can I fix this? The motherboard is a Supermicro H12SSL-NT. galactica-diagnostics-20240402-1951.zip

Will do. Unfortunately, this appears to be a bug in qBittorrent’s code. For now, I’d recommend setting a memory limit for your qBit container(s) to prevent it from crashing the server. Aside from that, you may want to try Transmission. For myself, I can live with this for the moment since I have a lot of RAM. That said, migrating to Transmission is painful and not really feasible for me.

No, it has no impact on memory usage.

I have WebUI tabs open for all the qbit containers, but that has no impact on server memory usage. I have some manual scripts that poll the qBit API, but I only run them occasionally to locate unregistered .torrent files and clean them up. So that would not cause this either.

Not yet, unfortunately. I posted a thread in the lscr.io Discord server, but they instructed me to make a bug report to qBittorrent. Since this issue is occurring across containers from three different maintainers. I'll probably make a bug report in GitHub today.

I've been having some pretty severe memory leak issues with all three qbittorrent docker containers recently (binhex, hotio and lscr.io). I transferred ~10,000 torrents (47TB total) and fast resume data from another linux-based (not Unraid) server to my Unraid server. The previous server that these torrents were running on was rock solid stable for a year and that server used 8GB RAM total (including the OS). No memory leaks with that Qbit instance (4.3.9 libtorrent v1). The qbit instance is just seeding (no downloading). And no matter what I try, the qbit container eats up more and more RAM until it almost locks up the server. Even when I have zero active torrents, memory usage grows until the docker oom killer reaps it (and resets the qbit app within the container). For now, I've set a container memory limit of 64GB and that prevents the server itself from running out of RAM, otherwise Qbit will easily eat up all 192GB of RAM before I have to kill it. Troubleshooting Steps I've Tried -- no success with any of them: Different containers (lscr.io, Binhex and Hotio) Different Qbit versions (4.3.9, 4.4.5, 4.6.0, 4.6.2, 4.6.3 and 4.6.4) Different Libtorrent versions (v1 and v2) New Server Hardware (new CPU, Ram, Mobo, HBA) Server Specs: Supermicro H12SSL-NT EPYC 7B13 - 64 core at 2.20 Ghz 256GB DDR4-3200 ECC RDIMM Memory Allocation: 64GB to ZFS 64GB to troublesome Qbit container The remainder is unallocated Strangely enough, I have two other active lscr qbit containers (details below) and those containers only uses around 1-4GB of RAM each (depending on activity). This is all on the same unraid server. I've also tried endless changes to qbit advanced config options, but nothing helps. I'm not sure what the problem is, but I've never run across such memory leaks across so many different versions of qbit. The only constant factor for the memory leaks is this set of torrents and Unraid. Any suggestions would be greatly appreciated. Enclosed are my anonymized diagnostics. Since these issues persist across every new container I create, I'm unsure if perhaps there's a rogue torrent causing the issue? I'm completely stumped at this point. Qbit Instance 1: 1,000 torrents -- seed size 26TB -- no memory issues Qbit Instance 2: 10,000 torrents -- seed size 63TB -- no memory issues Qbit Instance 3: 10,000 torrents -- seed size 47TB -- terrible memory leaks (problem child) Other Config Info (may not be relevant): Local File Storage for Qbit 16 HDD RAIDZ2 Pool Two VDEVs with 8 HDD each galactica-diagnostics-20240402-1951.zip

I've tried that previously and it did not fix the issue.

I'm not sure if anyone else has come across this issue, but I've been having some pretty severe memory leak issues with the linuxserver qbittorrent docker container recently. I transferred ~10,000 torrents (50TB total) and fast resume data from another server and split it across two separate lscr qbit instances (roughly 5k torrents each). The files themselves are stored on an 8-wide raidz2 pool dedicated for torrents. Both instances are just seeding (no downloading). And no matter what I try, the qbit container eats up more and more RAM until it almost locks up the server. I have 128GB RAM (64GB for ZFS + 64GB for everything else) and qbit will easily eat up 40GB of RAM before I have to kill it. This happens with every version of qbit I've tried: 4.3.9, 4.4.5, 4.6.0, 4.6.2. I've tried both libtorrent v1 and v2 with all of these builds as well. Nothing works. I can limit RAM to 8G or 16G via docker compose, but that makes the container endlessly reset itself when it runs out of RAM. This causes the appearance of phantom torrents with the tracker and wildly fluctuating ul/dl speeds. Strangely enough, I have another active lscr qbit container (latest repo -- 4.6.2) with around 6,500 active seeding torrents in it and that container only uses around 3GB of RAM. This is all on the same unraid server. I tried the binhex container and same issue. As a last resort, I spun up a new hotio qbit container running 4.6.2 (libtorrent v1) and put the original 5k torrents into it. It's been pretty stable so far, only using 4GB RAM at present. I'm not sure what the problem is, but I've never run across such memory leaks across so many different versions of qbit. Any suggestions would be greatly appreciated.

I noticed that this plugin displays space in a manner inconsistent with the rest of the unraid Main page. Specifically, it appears to show data in GiB/TiB, but the plugin uses the GB/TB nomenclature. It's a bit confusing. If you're going to continue using base 2 units, would you consider changing the nomenclature to be accurate? Or perhaps change the units to base 10 instead?