SABnzbd Forums

Hi,

Version: 0.6.9
InstalledBy: Ubuntu PPA
OperatingSystem: Ubuntu
NewsProvider: newsdemon

So I recently added a NZB*, downloaded... Came back to see sabnzbd stating:-

"""
Repair is required.
1 file(s) are missing.
4 file(s) exist but are damaged.
182 file(s) are ok.
You have 2972 out of 2977 data blocks available.
You have 4 recovery blocks available.
Repair is not possible.
You need 1 more recovery blocks to be able to repair.
"""
(EDIT: Actually that's probably output from my manual run of par2verify, but sabnzbd's state was similar, if not as detailed!)

The missing file is the .nfo file which is in my clean-up list so either wasn't being downloaded or was being deleted before the par2verify/repair. (Random thought: cleanup after par2 verification? - Just a guess, not investigated too much on exactly when it performs the clean-up.)

Anyway, even in this state... if I click retry and let it sit in the paused queue there was over 100MB of additional par2 files available for download. Unpause the queue, and it goes straight back to verifying/failing.

I removed the .nfo file from the clean-up list and hit Retry then it was able to successfully repair using the par2s since the .nfo file provided the extra required block.

My thinking is though, that even in this state that sabnzbd should have downloaded the extra available par2 files rather than just failing like that, irrespective of the missing .info file.

[*] I am ofcourse happy to provide (privately) the NZB file in question to a developer/administrator... :-)

The overwhelming response aside...

I'm chalking this one down to faulty memory (my bad)!

There was no response, because this looks to use like just another failed download,
which can happen when dealing with Usenet and NZBs.
It is possible though that the additional par2 files were just badly named, or even unrelated.
We're working on a solution for the "badly named" issue.

shypike wrote:There was no response, because this looks to use like just another failed download,
which can happen when dealing with Usenet and NZBs.

Just want to explicitly state... my comment was very much ill-made and was never meant to sound like a dig at you (or anyone else) for a lack of response!

(Infact I considered the silence "he's an idiot and has done something wrong" and upon discovering the faulty memory - very much justified!)

shypike wrote: It is possible though that the additional par2 files were just badly named, or even unrelated.
We're working on a solution for the "badly names" issue.

I'm more than happy to check if the additional par2 files were badly named, if you have a definition for "badly named" or a pointer to the code where the naming scheme (or whatever) can be discerned!

Thanks,
kmdm

Not offended at all.
We're usually quite responsive, but the flip side of that is that you create expectations

Normally posts have this pattern:
name.of.show.par2
name.of.show.part01.rar
name.of.show.part02.rar
name.of.show.part03.rar
name.of.show.vol.000+001.par2
name.of.show.vol.002+033.par2

There can be some variants.
However, sometimes people post extra par2 files with other names, which end up in NZB files anyway.
name.of.show.hey.extra.par2files.vol.044+099.par2
Or even worse names.

Like I said, we're working on improving handling of par2 files.
Faulty memory is something else. Let's just say that the par2 tool is a merciless memory tester