SABnzbd Forums

Doesn't SABnzbd 0.7.11 already handle these cases?

I'm using SABnzbd Mac version 0.7.12. Everything works great except in the case where part of a file set has been intentionally misnamed. I'm talking about a series of rar files like this:

Real-file-name.rar
Real-file-name.r00
Real-file-name.r01
Real-file-name.r02
Real-file-name.r03
DF93n5ngkDJFH3n5lG.r04
DF93n5ngkDJFH3n5lG.r05

If the .par2 file itself is misnamed, SABnzbd apparently never downloads it and doesn't do the par check. I see lines like this in the log:

2013-05-27 13:48:07,125::INFO::[postproc:548] Par2 check starting on AutoNZB-2913c
2013-05-27 13:48:07,126::INFO::[__init__:859] /Storage/Downloads/nzbtemp/AutoNZB-2913c/__ADMIN__/__verified__ missing
2013-05-27 13:48:07,126::INFO::[postproc:579] No par2 sets for AutoNZB-2913c
2013-05-27 13:48:07,128::INFO::[postproc:594] Par2 check finished on AutoNZB-2913c

If the .par2 file is named correctly but some of the other files are misnamed, I see this in the log:

2013-05-20 16:22:29,245::INFO::[postproc:548] Par2 check starting on AutoNZB-bdbe2
2013-05-20 16:22:29,245::INFO::[__init__:859] /Storage/Downloads/nzbtemp/AutoNZB-bdbe2/__ADMIN__/__verified__ missing
2013-05-20 16:22:29,245::INFO::[postproc:568] Running repair on set This.Is.The.Filename
2013-05-20 16:22:29,247::INFO::[newsunpack:1411] Cannot Quick-check missing file This.Is.The.Filename.r18!
2013-05-20 16:22:29,247::INFO::[newsunpack:821] Scanning "/Storage/Downloads/nzbtemp/AutoNZB-bdbe2/This.Is.The.Filename.par2"
2013-05-20 16:22:29,266::INFO::[downloader:664] Thread [email protected]:119: forcing disconnect
2013-05-20 16:22:31,509::INFO::[newsunpack:1031] Verified in 2 seconds, repair is required
2013-05-20 16:22:31,510::INFO::[newsunpack:1082] Need to fetch 418 more blocks, checking blocks
2013-05-20 16:22:31,510::INFO::[newsunpack:1104] 0 blocks available
2013-05-20 16:22:31,515::INFO::[newsunpack:839] Par verify failed on /Storage/Downloads/nzbtemp/AutoNZB-bdbe2/This.Is.The.Filename.par2!

When the files are all named correctly, this is the log:

2013-01-07 03:48:01,087::INFO::[postproc:547] Par2 check starting on AutoNZB-bdbe2
2013-01-07 03:48:01,087::INFO::[__init__:859] /Storage/Downloads/nzbtemp/AutoNZB-bdbe2/__ADMIN__/__verified__ missing
2013-01-07 03:48:01,087::INFO::[postproc:567] Running repair on set This.Is.The.Filename
2013-01-07 03:48:01,090::INFO::[newsunpack:795] Quick-check for This.Is.The.Filename is OK, skipping repair
2013-01-07 03:48:01,090::INFO::[newsunpack:857] Deleting /Storage/Downloads/nzbtemp/This.Is.The.Filename.par2
2013-01-07 03:48:01,091::INFO::[postproc:591] Par2 check finished on AutoNZB-bdbe2

If the unrar fails, I can find all the files in the temporary folder and manually unrar myself, although I have to go back and manually download the .par2 if SABnzbd didn't already grab it.

An "unrelated" par2 file will be treated as a separate set, so it should work.
However, if that par2 file isn't (completely) downloaded, it will not work.
Please email a representative NZB to [email protected] (and add the URL of this post).

I am emailing you an NZB that does not work for me.. It downloads all the files but fails to extract.
Email is from danmed (AT) gmail DOT com

I seem to have a similar issue as the original post, I am using the latest 0.7.14 version on my qnap nas and I have loads of issues with downloads failing as they hit the par2 verify stage. Running par2 manually on the nas shows that it cannot see all the spanned .r01 .r02 etc files to unpack.

However if I load the par2 file in windows using quickpar it shows that the files I have downloaded are all incorrectly named and it fixes them into the required spanned rar format.

The files I download are like .10 .11 .12 etc and seem to contain multiple rar files, they are all named in a long sequence of random numbers and letters.

Any help appreciated on how to correct this!

I am also striking this issue. The release name is intentional obscured and following downloading the par2 repair process doesn't rename the files as expected. If I run par2repair *.par2 * it finds the files that match it internally and rename all the files.

Bumping this up again, is there a plan to correct this? I am seeing probably half my NZB downloads hit this issue meaning a lot of manual work. Using par2 with a * always works and renames the files so unpack can take place.

This is being done intentionally to avoid DCMA takedowns ... A fix would be appreciated

Bushbrother wrote:Bumping this up again, is there a plan to correct this? I am seeing probably half my NZB downloads hit this issue meaning a lot of manual work. Using par2 with a * always works and renames the files so unpack can take place.

Are you running SABnzbd on some NAS device?

Yes, running on a Qnap ts-419 arm based. But I am running latest version of sabnzbd

There's a problem in some Unix-based embedded systems that makes par2 fail.
We're looking for a solution.

Thanks, if you need me to provide logs etc then let me know here, happy to help resolve this.

Please set logging to Debug (Status page) and try to find the
lines where par2 is started.

Hello,

I am bumping this up too.
I run Sabnzbd on a Readynas Pro x86. What I do for the moment is when I need to download a discussion where all the files are intentionally renamed, then as soon as Sabnzbd starts downloading I run Quickpar on the par2 file from my workstation in the background.
So when Sabnzbd is done downloading, all the files in the folder have already been renamed with their correct name by Quickpar in the meantime, and Sabnzbd can resume doing the Repair, Extract and Delete tasks.

So what I am asking is why isn't the Par engine attached to Sabnzbd doing this while checking the downloaded files?

Thanks

xtrips wrote: So what I am asking is why isn't the Par engine attached to Sabnzbd doing this while checking the downloaded files?

Ask its author, we have no control over the design of the par2 tool.
BTW: the cause might be a different one, we're looking into that.

The author, of Par2?
But the Par engine does what it is tasked to do.
I mean, you embed the Par engine into Sabnzbd, you probably know better which switches, if any, you used into the script/code to execute the Par check and Repair tasks.
I am just saying you know...