Disable Repair
Posted: November 15th, 2010, 1:35 am
Hi Folks,
I'm running this great piece of software in a very resource-limited hardware (a Synology NAS), and therefore, when par2 reports an issue on a downloaded file and sabnzbd instructs it to repair the archive set, it takes *several* hours to go thru the repair process, 'cos of the hardware limitations. My desktop PC is a quad-core machine, and if I run the very same repair from it, accessing the files via NFS in the very same NAS, the process takes only some dozens of minutes.
Therefore, hence the question: Is it possible, somehow, to instruct sabnzbd to unpack an archive only if a quick check (or even a par2 check) reports that it isn't corrupted and otherwise (repair needed) leave the fileset untouched for manual intervention?
I'm asking this because I have a repair task that is running for almost 16 hours now (it's at 85%, the fileset has about 8.3GB) and it has created a huge backlog queue (62GB) for post-processing that based in the previous occurrences of this scenario, will take *days* to be processed.
Best Regards,
Ed.
I'm running this great piece of software in a very resource-limited hardware (a Synology NAS), and therefore, when par2 reports an issue on a downloaded file and sabnzbd instructs it to repair the archive set, it takes *several* hours to go thru the repair process, 'cos of the hardware limitations. My desktop PC is a quad-core machine, and if I run the very same repair from it, accessing the files via NFS in the very same NAS, the process takes only some dozens of minutes.
Therefore, hence the question: Is it possible, somehow, to instruct sabnzbd to unpack an archive only if a quick check (or even a par2 check) reports that it isn't corrupted and otherwise (repair needed) leave the fileset untouched for manual intervention?
I'm asking this because I have a repair task that is running for almost 16 hours now (it's at 85%, the fileset has about 8.3GB) and it has created a huge backlog queue (62GB) for post-processing that based in the previous occurrences of this scenario, will take *days* to be processed.
Best Regards,
Ed.