how to prevent needless par2 doublecheck?

[username]

hello

when a Download is corrupt and needs repairing the usual routine is this
SAB:
-downloads the rars+smallest par2 for checking
-after checking all rars it notices it needs x more blocks
-the needed blocks are downloaded in form of additional par2 files
-now sab rechecks all rars again before repairing, even though it just did check them

when you have very big downloads (10GB+) this is getting REALLY annoying and time consuming and it is needless imo?
is there a way to stop sab from rechecking all the rars and go straight to repairing?
afaik quickpar saves the status in a small file to eliminate the rechecking, maybe something like this can be implemented in sab too?
it would be a tremendous help for me and for pretty much everyone downloading huge nzbs

if i overlooked an option that already does this, please accept my apology and tia for the hint

[switch]

We use an external app for the par2 checking, par2cmdline. There is no ability for it to remember the verification between separate verifications, so it has to scan a second time; until there is such a feature (which is fairly unlikely) then there is little we can do address this.

One thing we could maybe do is detect that files in a par2 set have missing articles while a download is in progress and add more par2 files to be downloaded. However this will always be inaccurate, either fetching too many or not enough par2 files as we cannot know how many blocks need to be fetched until a par2 verify tells us so.

In short, I don't see a solution to this. 0.5 can skip the verification stage if the file is deemed 100% correct, however an incomplete download will still require the double check.

[username]

pitty but thx anyway for your time

[username]

on 2nd thought it would be nice if you could implement an option to download pars that are smaller than x MBs (to be determined by the user) cause i´d rather needlessly download 50 or 100 MB than to wait 1h for double checking, so yeah that feature would be highly appreciated

[shypike]

Idea filed as ticket #256, long term item.

[username]

thx very much in advance