Not a feature, more like improvement: zero fill missing parts

[looseruser]

Quite often, SABnzbd tells me that there are too many parts missing and it can't repair the files.

What I do in these cases is that I test the files using Quickpar manually, queue up the files in NOMP (NZB-o-Matic Plus), download them and fix the bad files using quickpar.
This works in 80% of the cases - but I hate the manual labour associated with test, download and repair of the invalid/missing files.

I think that the reason why it works in the majority of the cases is that SABnzbd does not grab the rest of the broken files (or, does not handle these properly).
I led me to think that I am more successful using NOMP is because NOMP decodes all parts, filling in the missing parts with zeroes.

For example, there's a file with 8 parts (the numbers are representing the parts):
12345678
Say, after download part 4 is missing.
This is the output that SABnzbd produces:
123
This is the output that NOMP produces (replacing part 4 with zeroes):
12305678

So, I would like to suggest that SABnzbd fills the missing data with zeroes instead of cutting the files short.
It will enhance the chance of repairing the files.

Thank you.

PS. I might be wrong about NOMP being more successful due to the fact that it fills the missing parts with zeroes. Maybe NOMP is just better (for some other reason - maybe better retry?) in grabbing files with missing parts.

[shypike]

I fail to see why it's useful to fill the files.
Par2 or Quickpar will repair the files anyway, they don't need zero-filled files.
Even missing files are reconstructed.
All this depends on having enough par2 files and if your short,
no zero-filling will help you.

[looseruser]

Maybe you're right.
But for some reason I achieve better repair ratio with NOMP+Quickpar combo than SABnzbd.
Thus, there's something fishy with SABnzbd.
If it's not the zero padding, then it's something else.
I leave it to you to decide what your next steps are.
Thanks.

[shypike]

SABnzbd only uses properly named par2 files, while your solution
gobbles up any par2 file.
The reason we do this is to be able to distinguish multiple sets in a single NZB
and being able to safely delete the par files afterwards.
Unless you're processing NZB files of dubious quality,
you'll seldom come across situations where SABnzbd fails.

[looseruser]

Unless you're processing NZB files of dubious quality,
you'll seldom come across situations where SABnzbd fails.

I seems that it's not (only) about the quality of the NZB file.
Did you check the one I sent your related to another thread? I mean this one:
https://forums.sabnzbd.org/index.php?topic=4114.0
Check the screenshots there. SABnzbd 0.5 grabbed 14 files incorrectly.
Just out of curiosity I grabbed the same thing with NOMP again. Guess what: I got zero errors; all files checked out perfectly.
This happens quite frequently. Maybe you don't have this problem under Linux, but the Win32 release seems to have it.