SABnzbd Forums

sanbnzbd does a reasonable job handling nzb files with multiple parsets. However, it differs processing of the entire sets of pars until the entire nzb has been downloaded. Wouldn't it be better to try and process and the par2 right away?

yes. I know one can (should? though i'm not sure I agree with should) create a separate nzb file for each parity set, however that can be annoying if one is creating an nzb to download multiple items from a search engine (for instance).

A way to perhaps attack this problem would be to preprocess an nzb file. If it's contents can be fully assigned to individual parity sets, create a individual nzb files corresponding to those sets and process normally as that. Otherwise, continue as normal. (and by fully assign I mean get a set of parity "header" files, get the set of "data" files and "parity" file blocks, see if they can all be assigned to those "header" files, if they can, I'd think that you are pretty safe in automatically dividing up the large nzb file into multiple smaller nzb files)

How is this a bug report?
It's a feature request which is already in the queue for future releases.
(Although quite a while because it's a rather complex issue).

you're right (I didn't see the feature request forum at the bottom). With that said, I think I proposed a solution that wouldn't require the queue being fundamentally changed, just require the nzb be preprocessed and would handle a large amount of nzbs).

The splitting up is complicated.
Not for the average case where you just lump together a bunch of episodes that use a regular naming convention.
However, often even single posts already consist of multiple rar/par sets which also might have deviating naming conventions.
What do you do with spurious extra files?
So, while in principle splitting up an NZB is easy, the many fringe cases make it difficult.
We'll get there someday, but it won't be perfect.

I agree, my point was, in the case where you can split it up easily, do it. In the case where you can't, don't and just continue with standard behavior.

if one can handle the average and very common case better by preprocessing, why not do that? especially as (I'm guessing, can always be wrong), isn't really a fundamental change to any part of sabnzbd.

just my 2 cents. think it could help a lot, but whatever you guys decide is fine.