SABnzbd Forums

Hi,

I have had for some time, occasionally problems when unpacking archives. The files of the archives are located in directories that are created by unrar also, the files themselves but always end up in the root directory of the archive.


That does not happen in general with every archive on my side, but regularly.

Environment: Windows 2003 / 32 bits - 0.5.0 and 0.5.2 RC1 Sabnzbd +

On my QNAP TS639 I'm not the problem, only under the Windows environment.

Does anyone have a helpful tip about the further analyze and resolve to do?

short unforgiving ...

In these cases, files are included in the subfolder, but larger movie files end up in the unpacking at the root.

The file names differ only in Extention, smaller SFV or NFO files are stored properly. WMV or AVI file end  in to the wrong root place.

Are you using the Season/Movie/General sorting functions?

No, i am not use this option, or do any special pre / after processing, just the regular unpacking option.

SABnzbd does nothing about unpacking, it's all handled by the unrar tool.
It sounds like unrar does what SABnzbd expects it to do,
otherwise you should get warnings about missing files.
RAR files can contain sub-folders and if so these will be re-created too.
I'm not sure what the issue is.

is it possible to track or log  the used unrar command and options, so i could try to reproduce my problem manually at the command line ?

Set logging to debug and hunt the log file afterwards for the unrar invocations.

Thanks, I was not sure if the debug option would give me the info here, so my specific request. I'll see what I can reproduce the behavior even if I can find something insightful, I would like to add here.

I could now watch the behavior more accurately. The problem arises when there are multiple packaged archives which are located in subfolders. In the first round all the files are extracted correctly, in the second round there will not end up the extracted files into the subfolder where the archive are, but in the unpack root folder.

About the Debug Log option, I could not find the exact unrar options, so I can not try to understand exactly and whether it would work better with other parameters.

At the moment I set my Process option of "D" to "U" so I unpack in the flawed cases, the archives again manually.

What surprised me is that apparently no one else has yet been observed and reported this ...

Which unrar do you use?
We did solve a problem that sounds like this and the only way to solve it was to
use a more recent version of unrar (which has an auto-rename option).
Now when SABnzbd detects an older version of unrar it issues a warning and doesn't use the option,
potentially leading to results like you describe.

thank you for the response.

I use the regular version 3.91 from the sabnzbd+ archives. Since today i use the Sabnzbd+ 0.5.2 release version, but get this problems also with 0.5.2.RC1 or 0.5.0. The unrar.exe is binary identical with the last 3.91 version on http://www.rarlab.com/rar_add.htm, and i have no other unrar.exe in the path on this computer.

wodix

In that case, please email the NZB to bugs at sabnzbd.org
including a reference to this email.

I created a little and small test rar file, with that I can reproduce the unpack problem on my side.
It is posted in alt.binaries.test hopefully it helps to fix this issue. The nzb and the test file is send to bugs at sabnzbd.org.

i tested this now on my QNAP TS639 Pro Installation (0.5.0), and get the same results as on my Windows System.

short question, was it allready possible to reproduce the behaviour at the development side, or are more detailed informations need ?