Disk full due to chunks

[gquiring]

I am still having issues since upgrading to 6.72 with how backed up my queue is processing downloads. I never saw this before. My chunks folder is 140gig! Why is newsbin taking so long to par/unrar files?

[Quade]

People ask for it to be able to unrar and download at the same time but then they don't factor in the fact that the download SLOWS DOWN the unrar and repair. There's only so much you can do with the disk before it bogs down. Clearly you can download faster than you can unrar (and unrar and repair are made slower by continuing the download).

Seems to me like you want to pause the download during unrar/repair. it's in the performance options.

[gquiring]

What I don't understand is I hit the pause button and it still took forever for the unraring to happen. It did not go to the next file and start processing after it finished a prior one. It sits there, appears to be doing nothing for well over a minute before it starts the next file. What's it waiting for?

[Quade]

What I don't understand is I hit the pause button and it still took forever for the unraring to happen. It did not go to the next file and start processing after it finished a prior one. It sits there, appears to be doing nothing for well over a minute before it starts the next file. What's it waiting for?

You know all those chunks sitting in the chunks folder? They have to be turned into files and PAR checked before they can repair and unrar. That's likely what your delay is from.

[gquiring]

Currently my chunks are created on C: (SSD). Then the files are placed on T: (HD). Then the unrar is done to Q: (HD). Would it be faster to have the chunks created on drive T:? Could that be a move of the data or will it be a copy?

[Quade]

Fastest would probably chunks and download to the C and then unrar to the Q. What kinda drive is the Q drive? If it's slow, it'll bottleneck the whole process. It somewhat depends on what the T drive is too.

Assembling files just means reading the chunks from the chunks folder and writing them to the output file. So, while there might be a performance benefit to chunks on one drive and files on another, it really depends on how fast the T drive is.

Most of the time the files are generated from RAM so, no chunks are used. The chunks folder fills when you fall behind. When download is faster than assembling, repair and unrar.

UnRARing is slow. It's not code that I wrote and it has a bunch of legacy cruft in it. Since most posts to Usenet are uncompressed rars. I wonder if I it would be faster for me to handle the unrar in cases where they're uncompressed? Might be worth experimenting with.

[gquiring]

T: is an old drive, SATA/300 according to Crystal Disk info. 54,000 hours - I would say I got my money's worth out of it. I can't get a Seagate 3TB drive to last a year let alone 6 months in some cases. Drive Q: is also old (41,000 hours) but it's a SATA/600 interface. My internet is 1gig service (uVerse), I average anywhere from a low of 400meg to over 800meg, it's random during a download.