Page 2 of 2

Re: Large queue nzb's or large nzb's makes download speed 'very' slow

Posted: April 16th, 2010, 2:29 am
by shypike
Instead of --clean you can also remove all files in the "cache" folder.
So, stop SABnzbd, remove files, start SABnzbd.

Re: Large queue nzb's or large nzb's makes download speed 'very' slow

Posted: April 16th, 2010, 3:57 am
by pikkedonker
That trick worked! Although everything in queue or history (about this large download), was gone. I checked the sabnzbd/download and luckely the files were still there!
Had to change rights via WinSCP and now verifying and rar-ing them manualy.

Thx Shypike!

Re: Large queue nzb's or large nzb's makes download speed 'very' slow

Posted: July 4th, 2010, 1:02 am
by steve1977
Exactly the same issue as I am facing (also running 0.5.0 from server with the GUI not showing up anymore). Did some stupid mistake and now my queue is "packed". Getting same error as you are getting above and I cannot access the GUI. Any thoughts what I can do? I would prefer not to delete my queue as you did. Upgrade to 0.5.2? Any other idea?

Re: Large queue nzb's or large nzb's makes download speed 'very' slow

Posted: August 5th, 2010, 10:52 pm
by miketew
I also have this issue. I can have hundreds of items queued up sometimes - but even with maybe 100 it seems like the framework starts to crumble. I can pause the queue (so there's no overhead for downloading) but still even just listing the queue using API calls is slow and blocks.

Does sabnzbd use sqlite or anything for it's internal queue database? (I see it uses it for the history DB... what about the active queue?!) I would think with only 500 items and a minimal amount of information per item for the summary table (and then if it breaks it down into more detailed, that in a different normalized table) it should be quite speedy to do queue management activities...

However it seems like the whole engine starts getting stuck in locked/block mode. Besides the downloader - that still works pretty well.

Is there any thoughts on re-architecting things? Perhaps using twisted? Supposedly it's non-blocking, and then throw mysql or sqlite behind it (sqlite would be more portable of course?)

Right now the queue status blocking really messes things up, especially when firing off ajax style requests in the UI, or loading it on myNZB. Sadly I'm only a PHP hacker, not Python, or I'd investigate how to help...