SABnzbd Forums

I have set up post-processing python scripts to detect and handle failed downloads.
'Post-Process Only Verified Jobs' is unticked, and 'empty_postproc' is ticked.

When the job appears in the history section, I assume that failed jobs (for any reason) should show as failed with the red skull icon.

In the following cases, they do:
» Aborted, cannot be completed
» Repair failed, not enough repair blocks
» Aborted, encryption detected

However in the next case, they don't, and shows the 'successful' star icon instead:
» Unpacking failed, CRC error

In all four cases, SABnzbd correctly passes a non-zero value to the script for parameter number 7. So I'm able to take appropriate action for failed jobs, but they don't always show as failed in the history, regardless of the exit code I choose to return from the script.

[Version 0.7.11 on Linux]

The exit code of the script is not used to determine the result of the download.
Is there any pattern detectable in the relation between CRC error and the job end status?

I wasn't able to find any patterns so I decided to retry the downloads on a different machine with the same config (running Windows).
In the cases where I previously got 'Unpacking failed, CRC error' in Linux, I now get 'Repair failed, not enough repair blocks', and the job shows as failed in the history.

I noticed that the Linux machine had the classic version of par2 0.4, so I switched to the multicore TBB version by chuchusoft. It now behaves exactly like the Windows machine.

I tried both par2-classic and par2 multicore in Windows, and they both produce the same results (correct fail status in history).
I have not since encountered a CRC error, so I cannot yet confirm whether the final job status is marked as failed or not for these types of errors.

I'm happy with how things stand at the moment, with all failed downloads (so far) showing as failed in the history using the par2 multicore on Linux.

Unfortunately we have no control over par2 (and unrar) on Linux systems.