External tools: par2 & unrar x64

[ncjok]

Using 0.5.0Beta6 on Win7-64; I would like to just ask for clarification on how SABnzbd+ knows my preference for it to call the x64 versions of par2 and unrar in the post processing stage.

In Config -> Switches I have set "Extra PAR2 Parameters" = -t+ per the Wiki. Does this alone tell SABnzbd+ to call par2 from the x64 subdirectory (\win\par2\x64) or do I have to move the x64 files into the par2 root directory (\win\par2\) myself?

If the former is true, how do we configure SABnzbd+ to call the x64 version of unrar (\win\unrar\x64)? I do not see any corresponding setting in the Config section to specify this preference.

Thanks.

[inpheaux]

The -t+ flag just forces par2 to use multiple threads, this has nothing to do with 64/32 bit Windows. In fact, the -t+ flag isn't even necessary if you have a multi-core processor, the par2 binary should be intelligent enough to determine if you're capable of running multi-threaded and automatically run that way if it can.

As for picking between the 64/32 bit binaries, SABnzbd should also do this automatically. If we can tell you're running a 64 bit OS we'll automatically use the 64 bit binaries for par2/unrar.

[ncjok]

So I'm a few days "into Usenet" and have now had my first experience with a broken download. I came home to find par2 hung on repair, munching up 100% CPU and going nowhere.

Not knowing much about the other two versions in (\win\par2\) I picked the classic exe and performed a manual repair and subsequent extraction.

I'm guessing that the 64-bit version still needs to mature, so how do I ensure that SABnzbd continues to use par2-classic.exe (which is par2cmdline 0.4) in the future?
- Should I just delete the x64 directory?
- Should I copy par2-classic.exe into the x64 directory and rename to par2.exe?
- Do I need to keep the DLL files in (\win\par2\) and (\win\par2\x64) ?
- Should I also remove my "-t+" setting from Config -> Switches -> Extra PAR2 Parameters?

Please be specific.
Thanks!

[inpheaux]

You're the first person to complain about the 64 bit par binary being weird. Sometimes par just hangs, regardless of what version you use. If you're concerned about it, though, you can switch from the 64bit multi-threaded par2 to either the 32 bit multi-threaded par2 or to par2-classic.exe by deleting the x64 par2.exe and moving whatever binary you want to the x64 directory, and rename it par2.exe.

[shypike]

- Should I also remove my "-t+" setting from Config -> Switches -> Extra PAR2 Parameters?

Yes! Change it to -t0  (that's minus tee zero)
-t+ is counterproductive and will lead to heavy disk trashing.

[ncjok]

If I were to move either the 32-bit multithreaded, or classic par2 to the x64 directory, do I need to move any of the DLLs along with it?

tbb.dll in \x64\ is differently sized to the one in par2 root directory, where there are an additional two libraries: msvcp72.dll and msvcr71.dll.

Why is it disadvantageous to use multi-core via "-t+" for verify and repair when it's "okay" to use it for repair alone? From my experience with par2cmdline (par2 classic) when a repair is called the program first repeats the verify stage anyway? In effect, manually performing a "par2 verify " and "par2 repair " lead to 2x verify and 1x repair.

edit: I've just noticed I am already using "-t0"

[shypike]

The DLLs are for par2.exe. The par2-classic.exe doesn't require anything.
The 32bit and 64bit par2 programs come with different DLLs (named the same).

With -t+ you will have two or more cores fighting for disk access
and also asking for different parts of the same file during verification.
This increases the pressure on the disk channel, while there is no gain
simply because verification is disk-bound and not CPU-bound.
Using -t0 will do single-core for verification and multi-core for repair.
Repair is very CPU bound.

[ncjok]

Thank you both.