If you are using windows and have disabled DirectWrite, try enabling it and see if it makes a difference. There was a bug (fixed in r1022) that can cause incomplete files even if the articles were downloaded correctly.
Giganews/Supernews once claimed to be the only provider not suffering from slower speeds on older articles. What kind of difference are you seeing? Are you sure the age is the only factor? Article size can have an impact on the overall transfer rate, but you could fix that by using more connections.
Ah ok, I tested again with m_bAllOKMessageReceived == true and it successfully downloaded and extracted 12 "overlapping" jobs without unrar.exe ever touching a single tmp file! Looks like the handle inheritance really is the root cause.
Although descriptors for opened files doesn't have inherit-attribute by default, it still looks like for every file opened in NZBGet to the time where unrar is started the handle is also passed to unrar. That might be it! This would explain why I'm only seeing "CloseFile" operations, unrar.exe migh...
Working directory is correct, changing the path didn't help either. I even mounted the Ram Disk into "{MainDir}\tmp" instead of using a drive letter and now unrar.exe shows it's accessing "\Device\ImDisk1\4333.068.tmp" etc...
Nope, interdir is set to ${MainDir}/intermediate and MainDir is c:\NZBGet. I verified that the image path of the process accessing the tmp files is in fact "C:\NZBGet\unrar.exe" with the following command line: "C:\NZBGet\unrar.exe" "x" "-y" "-p-" "-o+" "*.rar" "d:\downloads\NZBNAME\_unpack" Unfortu...
R: is my Ram Disk (empty and not used by anything else), I set this TempDir intentionally and disabled DirectWrite because my SSD (c:\) can't handle the IO... The perfect solution would be If nzbget could somehow do full article caching in memory, but this is a pretty simple workaround with a huge p...
Didn't get any errors from fclose, but I might have found the culprit: http://i.imgur.com/xBYc1XP.png It looks like unrar.exe is accessing the .tmp files while unpacking a previous job. I did a few more tests and the problem only appears during active unpack jobs. No clue why it would do that... May...
I have done some further testing with other ram disk tools and settings, unfortunately that didn't help. Using the resource monitor only shows nzbget.exe and the system process accessing files on the ram disk. So I'm suspecting nzbget is somehow blocking itself? I tried disabling compiler optimizati...