Instead of --clean you can also remove all files in the "cache" folder.
So, stop SABnzbd, remove files, start SABnzbd.
Large queue nzb's or large nzb's makes download speed 'very' slow
Forum rules
Help us help you:
Help us help you:
- Are you using the latest stable version of SABnzbd? Downloads page.
- Tell us what system you run SABnzbd on.
- Adhere to the forum rules.
- Do you experience problems during downloading?
Check your connection in Status and Interface settings window.
Use Test Server in Config > Servers.
We will probably ask you to do a test using only basic settings. - Do you experience problems during repair or unpacking?
Enable +Debug logging in the Status and Interface settings window and share the relevant parts of the log here using [ code ] sections.
-
pikkedonker
- Newbie
- Posts: 14
- Joined: April 13th, 2010, 12:37 am
Re: Large queue nzb's or large nzb's makes download speed 'very' slow
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!
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
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
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...
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...