SABnzbd Forums

If par2 or unrar are stuck this will prevent SABnzbd from exiting.
However, this should only block the post-processor task, everything else should function normally.
Sending a "kill <proc#> -3" (equivalent to a ^C or ^Break with the keyboard) to SABnzbd from another terminal session should stop it.

You can set the logging level to "Debug" on the Status page.
We accept debugging info on the email address bugs at sabnzbd.org.
We also have a bugtracker on Launchpad, but that's not very useful for problems like these.
Also we don't want you to attach materials to a public tracker, which indicate what you are downloading.

Sorry, I dont mean stuck per-say. Par2 and unrar are running as expected, they open up process [something] and then close down - SAB does not reflect this in the HTML GUI.

I know the kill command in Mac and Linux, is there a Windows XP equivalent? Or is it ok just to force quit the application?

Having looked at the log, I cant see where it crashed out, when I restarted SAB yesterday, it appears to have created a new debug log and not appended to the old one.

On Windows you have few choices.
Only logging out or system shutdown do do graceful exit.
Using the Task Manager, does not.
0.6.6 is better at recovering from ungraceful exits.

All out crashes have been occasionally reported for very large NZBs (>25G),
but not your kind of problems.

Ahh, Now that is making sense, these are large NZB's (around 30-50GB).

In the History queue will be a load of smaller files, typically 800MB- 1500MB, but SAB seems to freeze and not report back the download speed etc. This is what I mean by par2 and unrar are running OK as the files end up at their correct destination eventually, even though this issue happens with the download queue and statistics.

Im going to download the new release tonight and see if this resolves the issue. If it does not I will submit a full step-by-step bug report with screen grabs etc.

Thanks
B.

If you run the latest version as a Windows Service,
It should recover all by itself, should a crash occur.
If you have multiple big items in the queue, the currently post-processed one
may be doubly post-processed. So, it's not ideal.
Since only these very large NZBs are affected, it's not exactly easy to debug.
Especially since there's very little pattern to detect.
So it's like: make a few changes to the code, downloád a night,
examine result, try again, etc. etc.

BTW: you may want to enable the option Config->Switches->"Pause downloading during post-processing".
This lowers the chance of a crash during post processing.

shypike wrote:Can you see in the log file where it hangs?
This might give me some ideas where to look?

Hey man sorry didn't see this. Hmm where can I find the log file?

Also this is a bit weird.. everytime i download, two download directories appear and start flashing and stuff with directories im downloading.

aoaaron wrote: Hmm where can I find the log file?

Also this is a bit weird.. everytime i download, two download directories appear and start flashing and stuff with directories im downloading.

The log file is normally in ~/.sabnzbd/logs or else in a sub-folder of the folder sabnzbd.ini resides in.
I don't understand your last remark.

Was any resolution found for this? I'm running into the same thing

as soon as a download starts my mac gets completely locked up, and only a restart will resolve

mickbel wrote:Was any resolution found for this? I'm running into the same thing

Cross-posting to very old threads makes little sense.

Thanks but I can't find a new thread on this topic. There are a few in this forum, but none seem to document a fix.

I am seeing this issue on an intel 10.6 mac and ppc 10.5, running 0.7.3 of sabnzbd, this happens without any other apps running, downloading to a local temp dir.

Almost immediately after a download starts it crashes sab and then locks up the whole machine ... all networking functionality drops and the machines need to be physically restarted.

I apologize if I am missing something, but all I can find on this topic is a bunch of users reporting this issue with no fix or tracked bug documented.

What I meant to say is that you're already filed your complaint in another thread.
Please stick to that thread and don't start opening up old threads with the same complaint.
In fact you should have started your own thread.