newsbin.com

Wondering why I'm experiencing the following with NB 6.3 RC3:

1. when Newsbin started updating headers in two of the larger groups (multi-million...), a pending AutoPAR operation stalled. Newsbin seems to attribute precedence to this over everything else. Annoying when downloading the headers will take many hours. I can't seem to force the AutoPAR process.

2. Moving the completed download to the top slot has no effect. In the above scenario, downloading headers still takes precedence. Why can't priority be re-assigned based on slot position in NB6?

3. Despite the headers taking precedence, a download in progress BELOW the headers download is continuing.If this is continuing, why can't the AutoPAR assembly proceed in a completed download?

Maybe these rules should be customized by the user?

Thanks.

- Look down at the status bar and see what "Cache" shows. If it's zero, I suspect that this will stall out autopar processing. Autopar needs a cache block to report results when it finishes. It shouldn't stall it long but, might stall it some.

- Autopar runs independently of download both headers and files. The only thing that should slow autopar down is if something else is using 100% of the disk IO bandwidth. That's sort of what this sounds like. Your disk drives are running balls out and don't have bandwidth for both headers and autopar at the same time. I get pretty high header download speeds, 700+ Mbps when I use both astra and giga at the same time (because of header compression). I haven't noticed this. Then again, my machine is exceptionally powerful so, it might not be a fair comparison.

- Each header download is a connection and runs to completion. Files don't work that way. They're split up into chunks which can easily be per-empted when you change the order of the files. That's why moving files around changes download order but, changing header downloads around doesn't. Just thinking about this gave me and idea about that though. How I might make them pre-emptable in the future.

- If you have 10 connections and you use 5 of the connections for header downloads, that leaves 5 connections for the files to continue downloading. Some people will add a copy of their current server. Give it a couple connections then set the original server to "no header download". In that way they can control how many connections header downloads consume.

Thanks for the verbose clarifications, Quade.

Another thing I noticed is that any RAR sets started AFTER the header downloads are in progress start and progress to AutoPAR completion (assembly, extraction, deletion of rar/par sets) while any started BEFORE the header downloads are still un-extracted (even though downloads are complete), seemingly pending the completion of the header downloads. So it wouldn't seem that disk I/O bandwidth or number of connections to server are the limiting factors here. Cache is currently reading 95/100. Thanks for looking into this.