[Solved]Par2cmdline-turbo - Repair failed, not enough repair blocks

[boredazfcuk]

Hey, everyone,

I've noticed that I'm getting a "Repair failed, not enough repair blocks" error quite often, but it's not accurate.

A download failed just now saying that it was 202 files short, but when I drop to the command line and run par2repair it was fine:

Code: Select all

Repair is required.
30 file(s) exist but are damaged.
61 file(s) are ok.
You have 1227 out of 1265 data blocks available.
You have 54 recovery blocks available.
Repair is possible.
You have an excess of 16 recovery blocks.
38 recovery blocks will be used to repair.
...
...
Repair complete.

I have Par2cmdline-turbo installed and nice check mark next to it. I've checked the sabnzbd.log file but the latest entry was 5 days ago.

Is it just me that's having problems?

[sander]

Useful if you post the full command from the CLI which does work.

Plus the relevant from sabnzbd.log

[boredazfcuk]

The command that successfully repairs the archives is just:

Code: Select all

par2repair <rarfile.par2>

There's still nothing interesting in the log file, even though a second download failed this morning. I've spotted that the log_level set to 0 in my config file though, have set to 2 now and will report back once my next download fails. Looks like that will be in a few hours time as I've another one which is missing articles.

[boredazfcuk]

Hi,

So I ran par2verify <par2 file> so that it didn't actually perform the repair this time and got this:

Par2Verify Output:
https://pastebin.com/BGNEDDdM

While this is the Sab log:
https://pastebin.com/7YFTs8du

It's not finding anywhere near as many data blocks within the corrupted files. It helpfully suggests adding the -N option with par2, but this option is already specified in Extra PAR2 Parameters, in fact, it's the only parameter specified there.

EDIT:

In the sab log, I can see that parameter is already being passed:

Code: Select all

2023-12-11 08:22:18,068::INFO::[misc:1152] [sabnzbd.newsunpack.par2cmdline_verify] Running external command: ['/usr/local/bin/par2', 'r', '-B', '/downloads/sabnzbd/incoming/Debian.Linux.12.4.iso', '-N', '/downloads/sabnzbd/incoming/Debian.Linux.12.4.iso/Debian.Linux.12.4.iso.par2 <Plus many, many more par files>']

Par2 information, just in case:

Code: Select all

/sabnzbd # /usr/local/bin/par2 --version
par2cmdline-turbo version 1.1.0

[boredazfcuk]

Also, manually running this simple command gives odd results:

Code: Select all

/downloads/sabnzbd/incoming/Debian.Linux.12.4.iso # par2 v -N Debian.Linux.12.4.iso.par2
Loading "Debian.Linux.12.4.iso.par2".
...
...
Target: "Debian.Linux.12.4.iso.part027.rar" - damaged. Found 9 of 33 data blocks.
143932992 bytes of data were skipped whilst scanning.
If there are not enough blocks found to repair: try again with the -N option.
...
...

Scanning extra files:


Repair is required.
13 file(s) exist but are damaged.
81 file(s) are ok.
You have 2790 out of 3086 data blocks available.
You have 150 recovery blocks available.
Repair is not possible.
You need 146 more recovery blocks to be able to repair.

It's like the '-N' command is ignored.

[boredazfcuk]

Running par2verify finds the additional blocks though:

Code: Select all

/downloads/sabnzbd/incoming/Debian.Linux.12.4.iso # par2verify Debian.Linux.12.4.iso.par2
Loading "Debian.Linux.12.4.iso.par2".
...
...
Target: "Debian.Linux.12.4.iso.part027.rar" - damaged. Found 32 of 33 data blocks.
Opening: "Debian.Linux.12.4.iso.part030.rar"
...
...

Scanning extra files:


Repair is required.
13 file(s) exist but are damaged.
81 file(s) are ok.
You have 3071 out of 3086 data blocks available.
You have 150 recovery blocks available.
Repair is possible.
You have an excess of 135 recovery blocks.
15 recovery blocks will be used to repair.

Edit: par2verify is it's own binary, rather than just being an executable script which calls par2.

[safihre]

Strange.. And the par2repair command also turbo version?

So it scans the right files but finds less blocks when we specify exactly which files to scan?

[boredazfcuk]

Yeah:

Code: Select all

/downloads/sabnzbd/incoming # par2verify --version
par2cmdline-turbo version 1.1.0

[boredazfcuk]

So it scans the right files but finds less blocks when we specify exactly which files to scan?

I've just copy/pasted the command from the log file which specifies 94 rar files and 9 par2 files and it doesn't find enough blocks:

https://pastebin.com/rWLrEh1V

This works:

Code: Select all

par2 v Debian.Linux.12.4.iso.par2
...
...
Repair is required.
13 file(s) exist but are damaged.
81 file(s) are ok.
You have 3071 out of 3086 data blocks available.
You have 150 recovery blocks available.
Repair is possible.
You have an excess of 135 recovery blocks.
15 recovery blocks will be used to repair.

This doesn't work:

Code: Select all

par2 v -N Debian.Linux.12.4.iso.par2
...
...
Repair is required.
13 file(s) exist but are damaged.
81 file(s) are ok.
You have 2790 out of 3086 data blocks available.
You have 150 recovery blocks available.
Repair is not possible.
You need 146 more recovery blocks to be able to repair.

But this does work:

Code: Select all

par2 v Debian.Linux.12.4.iso.par2 -N
...
...
Repair is required.
13 file(s) exist but are damaged.
81 file(s) are ok.
You have 3071 out of 3086 data blocks available.
You have 150 recovery blocks available.
Repair is possible.
You have an excess of 135 recovery blocks.
15 recovery blocks will be used to repair.

So...
Specifying '-N' before the main par2 file does not work
Specifying '-N' after the main par2 file works, providing no other files are specified
Specifying '-N' after the main par2 file and specifying additional rar/par2 files does not work
Specifying '-N' after the main par2 file and the additional rar/par2 files does work
Omitting '-N' works whether files are specified or not

It seems that for '-N' to work, it either has to be omitted, or last on the command line.

[boredazfcuk]

I've removed '-N' from the Extra PAR2 Parameters field, gone into history and hit Retry. This time around it has successfully repaired, unpacked and deleted.

[safihre]

Aaah.. Good to know.
Why did you add N in the first place?

[boredazfcuk]

I added because of the same problem... perfectly repairable downloads were being identified as non-repairable

Adding the '-N' tells par2 that you want "No data skipping" (https://manpages.ubuntu.com/manpages/xe ... ar2.1.html). It makes sure the the whole file is scanned and can recover mispositioned blocks.

In this case, omitting the '-N' should mean that it's unable to find the mispositioned blocks and considers the data unrepairable.

Some other people have witnessed that they get a better chance of a successful repair by using the '-N' switch:
viewtopic.php?f=2&t=19998
viewtopic.php?f=2&t=19005

I'm guessing that as I can omit the '-N' parameter and the repair manages to find all the mispositioned blocks, that maybe it's the default behaviour now, but just not documented.

[sander]

TIL: If manual par2repair gives better results than SABnzbd's par2repair, first step is to have the default par2 settings in SABnzbd ... meaning "Extra PAR2 Parameters" ... empty.

[boredazfcuk]

TIL: If manual par2repair gives better results than SABnzbd's par2repair, first step is to have the default par2 settings in SABnzbd ... meaning "Extra PAR2 Parameters" ... empty.

That won't always be the case... adding '-N' to Extra PAR2 Parameters used to give better results, however, I'm not sure at which point it stopped.

Maybe it was the recent change from par2cmdline to turbo. It's not very often that I get stuff which has missing articles so no way of knowing if that was the change which broke it. Other people may still be using the standard version of par2cmdline and that may still perform better with '-N'.

[boredazfcuk]

Just realised I have par2cmdline 0.8.1 on my Debian host server, I should have tested it with that too, but I've deleted the rar's now. Will test again if I encounter another failure.