nzbget fills up disk, and then stops working.

Get help, report and discuss bugs.
Post Reply
ssl-3
Posts: 2
Joined: 28 Aug 2019, 03:11

nzbget fills up disk, and then stops working.

Post by ssl-3 » 12 Jun 2022, 03:45

I'm having an issue with NZBGet that seems to happen with both sonarr and radarr.

I do my Usenet stuff in a virtual machine running Manjaro under QEMU.

I have a dedicated scratch disk that is an old (but healthy) 160GB Intel SSD, mounted using virtiofs, and that's where all of NZBGet's temp folders hang out. (I do it this way for speed, to avoid wearing out an SSD that I actually care about, and to avoid contention with other filesystems when doing repair and such.)

Once they're finished downloading, repairing, and renaming, the files are supposed to land in their final resting place, which is a different folder on a different (much larger) physical disk that is also mounted using virtiofs.

And that always works perfectly, except when it doesn't.

When it doesn't work perfectly: The scratch disk gets filled up by NZBGet, which then pauses all activity.

I get old MKVs hanging out in NZBGet's temp folder for months sometimes -- for downloads that completed successfully and that did get copied to their final destination. I usually find the really old stuff hanging out in dst and inter.

And that's not the end of the world, if my activity is low enough. Since most files aren't left behind, I just go and shovel those folders out periodically and things are fine, but the problem always comes back.

Which is one problem.

And it may or may not be related to that problem, but: If I shovel the scratch space out and do a bunch of downloads (hundreds of gigs of many much, much smaller NZBs, say -- individually, the downloads are relatively small), then the whole disk fills up and then NZBGet pauses because it correctly recognizes that it is out of space.

Which is the problem right now: Of the ~160GB I have for scratch space, inter is the culprit with 157GB used.

And when it pauses, it pauses everything -- including processing things that are already downloaded, even though working through the processing queue is the only way to free up scratch space without throwing away data or adding more hardware.

And when either problem occurs, I don't see any failures in the download history. (I think I have things configured to throw away data from failed downloads, too.)

(I had these same problems when I was using a traditional local filesystem for temp space, and when I was using SMB as temp space, and when using NFS as temp space, on two completely-different iterations of the VM. Thus, I don't think it's filesystem-related, but I wanted to include that information.)

Any thoughts?

Post Reply

Who is online

Users browsing this forum: No registered users and 8 guests