I saw in a previous post you bumped up the memory cap for qbit. Are we able to do that for Lidarr as well? I keep getting a system.outofmemoryexception when trying to manually import. Unable to retrieve queue and history items from qBittorrent 2026-06-24T17:39:43.074643357Z 2026-06-24T17:39:43.074651298Z [v3.1.0.4875] System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown. 2026-06-24T17:39:43.074656897Z at System.Text.UTF8Encoding.GetString(Byte[] bytes, Int32 index, Int32 count) 2026-06-24T17:39:43.074661904Z at NzbDrone.Common.Http.HttpClient.ExecuteRequestAsync(HttpRequest request, CookieContainer cookieContainer) 2026-06-24T17:39:43.074667173Z at NzbDrone.Common.Http.HttpClient.ExecuteAsync(HttpRequest request) in ./NzbDrone.Common/Http/HttpClient.cs:line 70 2026-06-24T17:39:43.074672336Z at NzbDrone.Core.Download.Clients.QBittorrent.QBittorrentProxyV2.ProcessRequest(HttpRequestBuilder requestBuilder, QBittorrentSettings settings) in ./NzbDrone.Core/Download/Clients/QBittorrent/QBittorrentProxyV2.cs:line 369 2026-06-24T17:39:43.074678877Z at NzbDrone.Core.Download.Clients.QBittorrent.QBittorrent.GetItems() in ./NzbDrone.Core/Download/Clients/QBittorrent/QBittorrent.cs:line 220 2026-06-24T17:39:43.074684060Z at NzbDrone.Core.Download.TrackedDownloads.DownloadMonitoringService.ProcessClientDownloads(IDownloadClient downloadClient) in ./NzbDrone.Core/Download/TrackedDownloads/DownloadMonitoringService.cs:line 93 2026-06-24T17:39:43.074707916Z 2026-06-24T17:39:43.074714812Z
11 replies
tomspark wrote:
Yep — same deal as qBit, and you can do it right now in a way that survives updates. Lidarr's currently capped at 256MB, and that out-of-memory crash is it hitting the ceiling while pulling a big queue/history from qBittorrent. Over SSH, create a file at /opt/sparkbox/state/overrides/media.yml containing exactly this (indentation matters): services: lidarr: deploy: resources: limits: memory: 1G Then run: sudo sparkbox up That raises Lidarr to 1GB. Because the file lives under state/, updates won't wipe it. You can confirm it stuck with: docker inspect sb-lidarr | grep -i memory A built-in memory setting for the arr apps (like qBit got) is on the list too. Give that a try and let me know if the manual import behaves now.
jackhammer57 wrote:
So would this be the correct way to do that? I have 40GB RAM so I figured I’d give it a little more headroom and bump it up to 2GB. sudo nano /opt/sparkbox/state/overrides/media.yml services: lidarr: deploy: resources: limits: memory: 2G
tomspark wrote:
2GB is a great choice — with 40GB to play with you've got loads of headroom. One important thing though: the indentation has to be nested, and the version in your post looks flat. Each line needs to step in 2 more spaces than the line above it, like this: services: lidarr: deploy: resources: limits: memory: 2G So: services: at the left edge, lidarr: in 2 spaces, deploy: in 4, resources: in 6, limits: in 8, memory: 2G in 10. If it's all flat like your paste, it'll error out. Save in nano with Ctrl+O, Enter, then Ctrl+X. Then run: sudo sparkbox up Confirm it took with: docker inspect sb-lidarr | grep -i memory — you're looking for 2147483648 (that's 2GB). Then give that import another go.
jackhammer57 wrote:
Your comment is showing up left justified as well. But I understand it should be like the image above.
tomspark wrote:
Exactly — that image is spot on. That's precisely the right nesting (services at the left edge, then each line stepped in 2 more spaces, with memory: 2G the deepest). You're right that the forum just flattens the spacing when it displays our comments — but as long as your actual file looks like that image, you're golden. Save it, run sudo sparkbox up, and Lidarr will come back with its 2GB. That manual import should behave now — let me know how it goes!
jackhammer57 wrote:
That helped a lot. It was certainly bottlenecked by the RAM. I just checked in docker, because it doesn’t seem to be working right on the sparkbox dashboard, and Lidarr is now currently using 1.3 GB
tomspark wrote:
That's the one — 256MB was strangling it, and at 1.3GB it's got room to breathe now. Nice work getting the override in. On the dashboard not looking right — what exactly are you seeing? If you mean the memory/usage figure for Lidarr looks off or stale, the dashboard only samples stats every several seconds so it can lag the real number for a moment; a refresh usually lines it up. But if it's something else (Lidarr tile showing unhealthy, a stat missing, a button not responding), tell me what's on screen or drop a screenshot and I'll get it sorted.
jackhammer57 wrote:
On the containers tab. I do see now that it doesn’t seem populated very briefly when you refresh but then it quickly disappears
jackhammer57 wrote:
That was a typo it does populate the data briefly
tomspark wrote:
Thanks, that screenshot nails it — that's the V2 (beta) Containers tab, and the CPU/Memory columns are flashing the numbers in on refresh then blanking back to dashes. Good news: it's purely a display glitch in that new view — your containers are all running fine and Lidarr genuinely has its memory, the table just isn't holding onto the live stats. Nothing's actually broken on your box. I've flagged it to get fixed in the V2 dashboard. Meanwhile the Overview page (or docker stats over SSH) shows the real numbers reliably. Appreciate you pinning it down with the screenshot!
Chris wrote:
Chris here, picking up a promise that was made to you and then quietly kept. Tom shipped that fix on 22 July, in v1.6.427. Your read was right: the stats endpoint worked the whole time — the Containers table just waited for every container to answer before painting anything, so one slow reply left the lot showing dashes. Each row now fills in as its own reading arrives. Over SSH: sudo sparkbox upgrade — note upgrade, not update. update only refreshes app images and won't pull in a release. Sorry nobody came back to tell you sooner. — Chris