SABnzbd Forums

Shypike, I am downloading on a Windows box, and want to move the final files to my network NAS. I want to repair/unpack the files locally on the Windows box, and move the final file to the NAS (since repairing/unpacking directly on the NAS is much slower, since it's being done over the network).

I think I raised this subject on this forums while on the 7.0 beta cycle, and I was told this was how sab already did it, that I just needed to specify a directory on the NAS for completed download folder.

I took the answer as correct, but during some unpacks today, and noticed, that repairing/unpacking is done on the NAS directly. And after everything is done, the files are just moved up one directory (the temporary unpack directory).

While sab is reporting unpacking xx/xx, there's a temporary directory on my NAs, where the file is being expanded...

Is this something that could be tackled on a future beta? Using the "temporary download folder" to repair/unpack/expand the files, and when they're done just move them to the completed download folders (compared to repairing/unpacking/expanding on the completed download folder directly).

I ran some comparisons between unpacking directly on the NAS, or doing it locally, and then moving the resulting file to the NAS (using a post process script), and I managed to shave several minutes (specially on big files).

Thank you.

For most people the difference won't be noticable.
I don't think the added value of such a feature is worth the effort,
especially since you already have a working script.

As a fellow developer, sometimes I end up re-writing code, even tough it works fine, or the added value is minimal. It's like thorn on my side, when there's something being done that way it's not supposed to, that doesn't go away. In the end, sometimes a rewrite is better, because you end up making it smaller/quicker or more efficient.

IMHO it seems logical, that repairs/unpacks should be done on the "temp" drive, not the final destination.

Still, I understand your answer, and I know you guys probably have finite resources, and they are better applied to more pressing matters.

Thanks anyway for taking the time to reply.

dogzipp wrote: IMHO it seems logical, that repairs/unpacks should be done on the "temp" drive, not the final destination.

No, it's not.
It may be in your specific case, but it's not universally true.
Repairs are done on the "temp" location, there's no other way.
We advise to keep the "incomplete" folder one one drive and the final destination on another drive.
For local drives, this is the optimal solution.
It may not be optimal when an external drive or share is involved.
The result depends on the combination of the OS, the external drive and unrar.
One would expect that unrar would be more efficient as doing a copy after unpacking.
In your specific setup, it's not.
To be honest, I have done little or no testing in this area.
But then again, it would only tell how my setup performs.

You're right about the to-do list being full with more pressing matters.

I know this is an old thread, but I've only just come across it.

I think the way it works now on a Server to NAS set up is actually as if not more efficient - I use UNC paths to my media NAS for all the destinations. When unpacking from the local machine to the NAS with a good LAN link, it will be faster than unpacking to the same drive as it won't be fighting itself for drive access. Ideally a separate spindle for the unpacking would alleviate this, but you still have the time it takes to move the final files to the NAS so you'll not gain very much (plus it will be far more complex to set up). Once unpacked, the final files already being on the destination again makes things quicker as all you have to do is move the files, which is zero data transfer.

Also, I believe repairs are local and separate to the unpack which won't commence unless the files are solid.