Some archives not unraring

[Chuckle123]

The files are d/ling fine and log says they extracted fine; this is not the case.  One thing I did notice when looking over files was that the sfv files was missing.  I would assume a par file would have been d/led and repaired the set before extracting, but that no extraction would take place if any part of set was missing.  Despite the log saying the file was extracted no file was extracted.  I previously had the option enabled that would cleanup directory.  This was deleting all files and leaving me with the .nfo file; thus my previous post which I quickly retracted.  I currently have the option that does cleanup disabled and extract the target file by hand.  I hope this explaination helps.  If I can further help in troubleshooting this issue don't hesitate to ask.

ce

[Hecks]

So what do you see on the PAR2 tab for those files?

[Chuckle123]

I see all green Par2 icons, and green check marks on rar icons.  By looking at Par results it looks like all is good.  Looks like sometimes the contents are extracted and other times they are not.  I will continue to look for a pattern.

ce

[Hecks]

If the progress bar on the PAR2 tab reads 'Unraring 100%' I would be very surprised if Alt.Binz hasn't actually unrared it.  This would be a first, and so steps to reproduce would be a must.

[Chuckle123]

Ok, I found the issue.  Hecks you are right again.  The files are being extracted but under c:\...... Let me recheck my settings and confirm that they are pointing to my extra drive.  The files are being d/led to the correct drive, but the extraction going to c:\.

ce

[Chuckle123]

When the last version came out I only copied over the exe file.  You think I should have copied the whole archive?

[Chuckle123]

It looks like other people are experiencing the same problem; target is extracted to drive Alt.Binz launches from.  Not sure if this is going to help or not but if I queue up a set to d/l a second time it does extract to correct location.  Setting a different destination folder for unrar does correct the issue, but my d/l and extract folder are the same so I don't use that option.

ce

[Hecks]

Now I'm a bit confused. Could you please state the steps to reproduce unsuccessful vs successful unrar on your system as clearly as possible.

[Chuckle123]

My Setup:
- I do not have option checked to unrar to different directory.  I let the unrar occur in same directory as d/l.

Issue:
- When a set is d/led it is extracting to root of c:\.  Note: Alt.Binz is installed on drive C
- If I queue the set a second time it extracts to the configured d/l folder. Note: Thought this was worth mentioning.
- In config I have the d/l folder set as e:\Inbox\Alt.Binz.

My workaround:
- I have checked unrar to different directory.
- I have set target directory to same as d/l folder.

I know most people use a different unrar folder/drive so you probably won't see this issue.

ce

[Hecks]

What I don't get is the queuing for the second time thing.  Is it consistently the case that each time you import an NZB, the first time it unrars to the wrong folder, the second time it's OK? Please confirm if this wasn't just a one-off glitch.

What path appears in the Unrar column of the queued item, and does this correspond with what you see on the PAR2 tab?

[gerkula]

I can also confirm that the very same issue occurs to me as he describes. Also another weird issue with unraring;
Although everyting is green and unraring 100%, I discover sometimes that there was no unraring at all. Upon investigating, I discovered a part or two of the rar archive had a bad CRC that was misreported to be good by the program. Therefore, I had to manually try to repair within winrar itself, which sometimes works. I could not recognize when or how this occurs and no pattern at all, as well as the unraring to the C:\ drive.

[Chuckle123]

Gerkula,

    Have you tried to d/l the set a second time not removing the directories and files created on the c:\ drive?  Since I did not notice they were extracting to C:\ I was resubmitting them and getting the target file in the correct folder.  When performing a par check by hand I also noticed that there were issues with set and would have expected for par files to be d/led to correct.  My work around seems to me working for me so far, so you may want to try it until the next version comes out with a possible fix; fingers crossed RDL can reproduce.  I also changed the min par file size to be paused ensuring that at least a few par files get d/led.  If you find anything else out I would appreciate a heads up; I will do the same.

ce

[Hecks]

As I said, check which path appears in the Unrar column of the queued item, and whether this corresponds with what you see on the PAR2 tab Unrar column.

[Chuckle123]

The Download Queue tab, Download Folder column : E:\Inbox\Alt.Binz\A.B.xvid\SetName\
The Par2 Tab, UnRar column : \A.B.xvid\SetName\

Relative path is being used for UnRar if "UnRar to different folder" is not selected.

ce

[Hecks]

Well, I can't reproduce that at all here. Unrar column in queue shows whole path, which is same as path in Download column, and Unrar column in PAR2 tab is also whole path, and everything unrars fine to download folder (using collection for folder name).

Are there any unusual characters in your NZB collection names? Have you tried with a different drive?