v6.70- large queue files from nzb..files d/l but not found

[bevo]

If you have a large queue of files set for download about half way through, I don't have the exact number it requires for this happen, the files will continue to "download" but cannot be found on disk.

I've seen this happen two different times now after upgrading to 6.7. The first time I set up a large queue and walked away. When I returned I saw that the files had supposedly downloaded without failure, but I couldn't find half of them. I have a very simple setup for download and extraction path (E:\DOWNLOAD\$(NZBFILE)\).

I watched this actively occurring with a very large set of files, they were showing as downloading, there is traffic on the NIC, but there is absolutely nothing being written to disk....at least that I can find. The logs do not seem to reflect this activity, but the size column under downloading files is definitely growing.

[Quade]

You have a couple choices.

1 - If this really bugs you, in the performance options enable "Pause download during unrar/repair". This will prevent the download from getting ahead of the assemble.

2 - On the other hand, you can just leave it be because what's really happening is that the download is continuing, the chunks of the files are being stored in the chunks folder and the file will assemble once repair/unrar is finished.

The main problem is that download is faster than you disk drives (when including unrar and repair) so, the assembly of files lags behind the actual download.

So, you can either go for maximum download speed which is how it's configured now. Or you can lock-step the download and unrar by pausing download during the unrar/repair step. This will actually speed up the unrar and repair because whenever you have 2 things writing to disk at the same time, the performance hit is more than expected. Commodity drives aren't really designed for simultaneous writes. If you factor in any security software dicking with the data, it gets even worse.

I'm toying with the idea of switching back to not writing the chunks and using a different mechanism that might work better for this but the problem is, security software interaction makes this less reliable than just using chunks and assembling from chunks.

[bevo]

Ahhh...this makes sense. Checking the "chunks" dir it was loaded with approximately 60 Gb of data.

Problem is ... it seems that the application never does get around to assembly after the other rars have completed. I did not remove the file parts from the download list the application does this on its own, and there is no final assembled file.

[Quade]

Problem is ... it seems that the application never does get around to assembly after the other rars have completed. I did not remove the file parts from the download list the application does this on its own, and there is no final assembled file.

Did they end up in the failed list?

I downloaded 100 gigs in one shot to test this and got 100% download, repaired and unrared.

You might want to check your security software logs and see if they logged anything related to this.