Page 1 of 1

3.9 final: Unrar to netwrok share (or NAS) is VERY BUGGY. Looses files !

Posted: Sun May 18, 2008 4:44 pm
by tvgeloof
I have discovered that in the last 2 beta's and the 3.9 final the UNRAR feature is very buggy when the target folder for Unrar is on a network share (Windows or Samba, Samba is found in Linux and most NAS boxes are based on Linux).

Basicly, when extracting large RAR-files ( > 1 GB) about 1 in 8 times NL thinks the Unrar went OK so it deletes the RARs itself from disk.
Upon inspection of the extracted files most of them turn out to be missing.
Only the first few files of the archive have been extracted. The rest is simply not there.
This forces you to download the entire post again. Not fun if its a DVD9.

It only seems to happen with multipart rar's, AND only if the par set needed repair. Strangely enough I have not seen it happen with rar-sets that verified OK the first time around.
It does happen with large RAR's containing only a single file (like a DVD iso ina multi-part RAR). I have seen that twice.

As I just downloaded over 300 DVD's over the last 2 weeks I had ample opportunity to test this. About 40 failed :-( .
I used my second PC (triple boot Vista-x64 , XP64, Ubuntu) to test using it as a second NL PC and to host the test-share on all 3 OSses.
Network speed between the PC with NL and the network share doesn't seem the issue. It happens if the share is slower then the NL PC and when it's faster. Verified this by switching the PC's and the NAS box between Gigabit and 100 MBit network.

Hardware/software used:
NL PC 1: XP-Pro-SP3, 1 GB RAM, P4, 2.4Ghz (single core). No other software running.
NL PC 2: XP64-SP2, 2 GB RAM, P4, 2.8Ghz (core-duo). No other software running.
Share 1: Samsung MyBook (Linux based, samba shares)
Share 2: Same XP64 machine as PC2.
Share 3: Same machine as PC2, but running Vista x64
Share 4: Same machine as PC2, but running Ubuntu 8.04 (samba share)
Share 5: Same machine as PC1

On every combination I have downloaded a minimum of 20 DVD's.
8 with NL on 100 MB and the share on 1 GB, 8 the other way around and the rest with both on 1 GB.
I have seen the problem happen at least twice on each combination.
Randomly distributed over the LAN speed combinations.

Posted: Sat May 24, 2008 6:32 pm
by psyk
I had trouble too but not only when destination is NAS but even on local and he lost for my self 20 small movies (only 2 where copied to destination) but all of the other had been deleted from the "standard" newsleecher download folder.

I've noticed bug with very large repair files (> 30 gb) as it repairs, fail then corrupt everything :x imo I won't use this function anymore and will do it by hand like till now.

Posted: Thu Jun 05, 2008 8:17 pm
by tvgeloof
Glad I'm not the only one.
But on local files this really sucks. I have (touch wood) not seen that happen yet.
EDIT: Correction, I have seen it locally as well, only in high CPU/HD load conditions though

I'm back to manual as well.
Quickpar is faster in repairing anyway and when I unrar NL always wants to see at least twice the size of the RAR files in free space, even if the compression rate on the rar's is next to 0%.
WinRar isn't that stupid ands seems somewhat faster as well.

Posted: Fri Jun 06, 2008 3:10 pm
by Archibald
Something similar has been documented here before. Nobody cares.

viewtopic.php?t=16288

Check your log-file. I bet you will find that Newsleecher moves on to delete files before the unRAR procedure has finished. The first few files get extracted OK because Newsleecher can't delete the source RAR files while they are being used by unRAR, but it deletes the rest of the RAR set before unRAR gets to them. :roll:

Posted: Sun Jun 22, 2008 2:25 pm
by tvgeloof
It is obvious to me that the entire unrar handling in NL is shaky.

The unrar.dll get's called but apparently NL doesn't care to check any error-codes returned by it's functions.

Or

The dll happily reports that there is no problem given NL bad info.

Given the other problem Archibald noted in the message above I'm more inclined to believe in the first explanation.