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.
Every day or two, I find sabnzbd has become none-responsive. The process is still there and has to be killed. I have only been running sabnzbd on FreeBSD (9.2) a couple months now, and never had similar problems when I ran it on Gentoo before. Checking the error log, I see this:
Exception in thread Thread-582:
Traceback (most recent call last):
File "/usr/local/lib/python2.7/threading.py", line 810, in __bootstrap_inner
self.run()
File "/usr/local/lib/python2.7/threading.py", line 763, in run
self.__target(*self.__args, **self.__kwargs)
File "/usr/local/lib/python2.7/site-packages/sabnzbd/newswrapper.py", line 127, in con
select.select([sock], [], [], 1.0)
ValueError: filedescriptor out of range in select()
It definitely seems plausible that FD>1024, so this may be a legitimate bug. I am still running SABnzbd Version: 0.7.16 but I still see the same line of code in the git master branch so I doubt an update would resolve (but I'm working on getting the update in the meantime anyway).
Several Unix variants have a low threshold for the amount of open sockets and/or files.
The description in the link is accurate, however it's not a problem on the majority of OSses.
From my understanding, its not that the OS has a low threshold on file sockets. Its almost the complete opposite. FreeBSD is apparently not limiting FD at 1024 and the select() method in python does not support indexes this high. I could limit the sockets allowed, but then I would probably en up with a different problem. Since this can apparently be solved in sabnzbd code, this doesn't seem like something that should be blamed on the OS.
You cannot use select() with such file descriptors. Try poll() instead, or Twisted.
Using twisted to solve this problem seems a little overkill. Although come to think of it, cherrypy has been a thorn in your side for some time and twisted may offer some relief there as well. No small amount of work though, and probably not worth it.
I guess you're right about it not being the root cause.
The socket/filehandle leak may be instead, not necessarily caused by SABnzbd.
The article you refer to says it's a Windows issue.
Which is a bit odd, because we've never seen this complaint for the Windows builds.
CherryPy is indeed a PITA, but rewriting the UI from scratch is just too much work.
As is moving the download code to Twisted.
I remember a competitor from the past that used Python and Twisted,
but it had lots of other problems. Having a worse performance that SABnzbd was one.
