SABnzbd Forums

Posted: **February 5th, 2013, 6:17 pm**

Hi all,

I have updated my Sabnzbd version from 0.7.3 to 0.7.10 on my Linux CentOS 5 box and now it seems like that verifying via Par2 is broken.
I have not changed any configuration settings. Does somebody have a clue what might be wrong?
Replaying the par2 command indeed fails with the same error message on the prompt.
Removing the latest parameter '/aaa/bbb/*' solves the issue on the prompt...

Debug Log:

Code: Select all

2013-02-05 23:56:24,610::DEBUG::[newsunpack:1380] build_filelists(): ts: []
2013-02-05 23:56:24,611::DEBUG::[newsunpack:933] Par2-classic = True
2013-02-05 23:56:24,630::DEBUG::[newsunpack:958] Starting par2: ['/usr/bin/par2', 'r', '/aaa/bbb/file.par2', '/aaa/bbb/*']
2013-02-05 23:56:24,660::DEBUG::[newsunpack:1250] PAR2 output was
The source file does not exist: /aaa/bbb/__ADMIN__
par2cmdline version 0.4, Copyright (C) 2003 Peter Brian Clements.
par2cmdline comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it and/or modify
it under the terms of the GNU General Public License as published by the
Free Software Foundation; either version 2 of the License, or (at your
option) any later version. See COPYING for details.
Usage:
par2 c(reate) [options] <par2 file> [files] : Create PAR2 files
par2 v(erify) [options] <par2 file> [files] : Verify files using PAR2 file
par2 r(epair) [options] <par2 file> [files] : Repair files using PAR2 files
You may also leave out the "c", "v", and "r" commands by using "parcreate",
"par2verify", or "par2repair" instead.
Options:
-b<n>  : Set the Block-Count
-s<n>  : Set the Block-Size (Don't use both -b and -s)
-r<n>  : Level of Redundancy (%%)
-c<n>  : Recovery block count (Don't use both -r and -c)
-f<n>  : First Recovery-Block-Number
-u     : Uniform recovery file sizes
-l     : Limit size of recovery files (Don't use both -u and -l)
-n<n>  : Number of recovery files (Don't use both -n and -l)
-m<n>  : Memory (in MB) to use
-v [-v]: Be more verbose
-q [-q]: Be more quiet (-q -q gives silence)
--     : Treat all remaining CommandLine as filenames
If you wish to create par2 files for a single source file, you may leave
out the name of the par2 file from the command line.
2013-02-05 23:56:24,661::INFO::[newsunpack:839] Par verify failed on /aaa/bbb/file.par2!
2013-02-05 23:56:24,663::DEBUG::[__init__:829] Saving data for __verified__ in /aaa/bbb/__ADMIN__
2013-02-05 23:56:24,664::INFO::[postproc:591] Par2 check finished on file
2013-02-05 23:56:24,711::INFO::[postproc:518] Cleaning up file (keep_basic=True)

Any help will be apreciated.

Kind regards,
Groentebroer

Posted: **February 6th, 2013, 12:46 am**

Werkt SAB 0.7.9 wel goed?

Zo ja, dan heeft het mogelijk te maken met de 0.7.10 feature "Try to repair rar/par sets with obfuscated (scrambled) names".
En het kan hetzelfde zijn als hier: http://forums.sabnzbd.org/viewtopic.php?f=3&t=13110

Posted: **February 6th, 2013, 3:20 pm**

Seems i have the same issue on windows.

Posted: **February 7th, 2013, 12:45 pm**

The problem has been located.
Due to a programming error, for NZBs containing mutliple rar/par sets
each set will process ALL available files instead of the just the ones belonging to the current set.
This takes a long time on slow systems.
Solution is near.

Posted: **February 10th, 2013, 7:58 am**

If I remember correctly, this was with only one rar/par set, but I'm not 100% sure.

It seems an error with processing the __admin__ folder, which is not part of any RAR/PAR set.
I hope the fix suggested above indeed fixes this.

Thanks all for your prompt replies.

Kind regards,
Groentebroer

Posted: **February 12th, 2013, 5:41 am**

Hi All,

I have updated to 0.7.11 and unfortunately this did not solve the issue.
It really seems that par2 on CentOS 5 cannot cope with with the last parameter as stated in my previous post. ('/download/folder/DOWNLOAD/*' in this post.)
Because of this par2 failure all downloads fail and stay in the downloads folder. Manually running the par2 command without the last parameter in the specific download folder works well.

If needed I can supply a .nzb file, please let me know where to...

Hope that someone can help me out.

Kind regards,
Groentebroer

Log:

Code: Select all

2013-02-11 12:30:15,946::DEBUG::[newsunpack:1380] build_filelists(): ts: []
2013-02-11 12:30:15,947::DEBUG::[newsunpack:933] Par2-classic = True
2013-02-11 12:30:15,953::DEBUG::[newsunpack:958] Starting par2: ['/usr/bin/par2', 'r', '/download/folder/DOWNLOAD/DOWNLOAD.sample-sample.par2', '/download/folder/DOWNLOAD/*']
2013-02-11 12:30:16,079::DEBUG::[newsunpack:1250] PAR2 output was
The source file does not exist: /download/folder/DOWNLOAD/__ADMIN__
par2cmdline version 0.4, Copyright (C) 2003 Peter Brian Clements.
par2cmdline comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it and/or modify
it under the terms of the GNU General Public License as published by the
Free Software Foundation; either version 2 of the License, or (at your
option) any later version. See COPYING for details.
Usage:
par2 c(reate) [options] <par2 file> [files] : Create PAR2 files
par2 v(erify) [options] <par2 file> [files] : Verify files using PAR2 file
par2 r(epair) [options] <par2 file> [files] : Repair files using PAR2 files
You may also leave out the "c", "v", and "r" commands by using "parcreate",
"par2verify", or "par2repair" instead.
Options:
-b<n>  : Set the Block-Count
-s<n>  : Set the Block-Size (Don't use both -b and -s)
-r<n>  : Level of Redundancy (%%)
-c<n>  : Recovery block count (Don't use both -r and -c)
-f<n>  : First Recovery-Block-Number
-u     : Uniform recovery file sizes
-l     : Limit size of recovery files (Don't use both -u and -l)
-n<n>  : Number of recovery files (Don't use both -n and -l)
-m<n>  : Memory (in MB) to use
-v [-v]: Be more verbose
-q [-q]: Be more quiet (-q -q gives silence)
--     : Treat all remaining CommandLine as filenames
If you wish to create par2 files for a single source file, you may leave
out the name of the par2 file from the command line.
2013-02-11 12:30:16,081::INFO::[newsunpack:839] Par verify failed on /download/folder/DOWNLOAD/DOWNLOAD.sample-sample.par2!
2013-02-11 12:30:16,082::INFO::[postproc:568] Running repair on set DOWNLOAD
2013-02-11 12:30:16,090::INFO::[newsunpack:1407] Quick-check of file DOWNLOAD.r18 failed!
2013-02-11 12:30:16,091::INFO::[newsunpack:821] Scanning "/download/folder/DOWNLOAD/DOWNLOAD.par2"

Posted: **February 12th, 2013, 7:34 am**

Groentebroer, does it happen to all or some downloads?

Let's check: Can you download this Lubuntu (open source, freely distributable): http://binsearch.info/index.php?q=lubun ... &postdate=

I'll do so on my Ubuntu, so that we can share experiences.

Posted: **February 13th, 2013, 4:33 am**

Hi Sander,

Thanks! I have tried your NZB and this works.
Now it seems that my queue items from 0.7.10 fail on 0.7.11. New queue items seem to work correctly.
I will be trying some more coming week and let you know how it works out.

Kind regards,
Groentebroer

Posted: **February 13th, 2013, 4:55 am**

Interesting.

My experience: no problem, but no logging at all of 'Starting par2". I don't understand. I would think a par2-check is always done? But maybe SAB works different, and it can skip the par2 check?

Posted: **February 14th, 2013, 3:07 pm**

Hi,

I think I found a part of the problem.

What does work on 0.7.11:

2013-02-14 20:46:22,934::DEBUG::[newsunpack:958] Starting par2: ['/usr/bin/par2', 'r', '/download/folder/file.rar.par2', '/download/folder/file.rar*']

What does not work on 0.7.11:

2013-02-14 20:58:51,849::DEBUG::[newsunpack:958] Starting par2: ['/usr/bin/par2', 'r', '/download/folder/file.par2', '/download/folder/FILE/*']

So the difference is in file.rar* and /file/*

Could this be a bug? Any other suggestions?
NZB's available, please let me know where to sent.

Kind regards,
Groentebroer

Posted: **February 16th, 2013, 8:01 am**

Hi,

Does anyone has another suggestion what to try?
Or maybe someone else who does not have this problem on Centos 5?

Kind regards,
Groentebroer

Posted: **February 16th, 2013, 10:34 am**

Yes, upgrade to 0.7.11
There's a serious problem in 0.7.10

Posted: **February 16th, 2013, 12:55 pm**

Hi,

I already updated to 0.7.11 but the problem still exists.

What does work on 0.7.11:

2013-02-14 20:46:22,934::DEBUG::[newsunpack:958] Starting par2: ['/usr/bin/par2', 'r', '/download/folder/file.rar.par2', '/download/folder/file.rar*']

What does not work on 0.7.11:

2013-02-14 20:58:51,849::DEBUG::[newsunpack:958] Starting par2: ['/usr/bin/par2', 'r', '/download/folder/file.par2', '/download/folder/FILE/*']

So the difference is in file.rar* and /file/*

Could this be a bug? Any other suggestions?
NZB's available, please let me know where to sent.

Thanks!

Groentebroer

Posted: **February 16th, 2013, 2:39 pm**

I'm not sure what your issue is.
Can you email an example of an NZB that goes wrong to [email protected]
including a description of what goes wrong and the URL of this post?

Posted: **February 16th, 2013, 3:06 pm**

Hi Shypike,

I have emailed the problem including the error and NZB file.

Groentebroer

SABnzbd Forums

par2 fails after upgrading from 0.7.3 to 0.7.10 on CentOS5

par2 fails after upgrading from 0.7.3 to 0.7.10 on CentOS5

Re: par2 fails after upgrading from 0.7.3 to 0.7.10 on CentO

Re: par2 fails after upgrading from 0.7.3 to 0.7.10 on CentO

Re: par2 fails after upgrading from 0.7.3 to 0.7.10 on CentO

Re: par2 fails after upgrading from 0.7.3 to 0.7.10 on CentO

Re: par2 fails after upgrading from 0.7.3 to 0.7.10 on CentO

Re: par2 fails after upgrading from 0.7.3 to 0.7.10 on CentO

Re: par2 fails after upgrading from 0.7.3 to 0.7.10 on CentO

Re: par2 fails after upgrading from 0.7.3 to 0.7.10 on CentO

Re: par2 fails after upgrading from 0.7.3 to 0.7.10 on CentO

Re: par2 fails after upgrading from 0.7.3 to 0.7.10 on CentO

Re: par2 fails after upgrading from 0.7.3 to 0.7.10 on CentO

Re: par2 fails after upgrading from 0.7.3 to 0.7.10 on CentO

Re: par2 fails after upgrading from 0.7.3 to 0.7.10 on CentO

Re: par2 fails after upgrading from 0.7.3 to 0.7.10 on CentO