NB 6.42 B2146 Finished files placed at bottom of DL queue

[cujo67]

Hey there, first post so please go easy on me

I don't know where to start, but I searched the forum for this problem and haven't bumped into anything similar to it, so here goes...

I have a filter setup to sort only epub and mobi files. I add the downloads to folders based on year-date, so it's not just one massive folder.

Problem is, after a certain amount of time downloading, doesn't do it initially I'd say maybe 30 minutes to an hour, the files that disappear from the list as downloaded get re-added to the bottom of the download queue. And if I take a file and move it to the top of the queue, most disappear without showing anything in the failed, downloaded, or log, but a few will display as a duplicate download.

At first I thought this was an automatic download error, as I had tried enabling that initially to automate the process, so I stopped the auto and did it manually and it's still tossing the completed files down to the bottom of the queue.

I've erased the .db3 files and reinstalled to a previous version but the issue still remains. I'm scratching my head as to what is causing this. Another thing to note is autopar is disabled because I prefer having a .rar to ensure file integrity is legit in the future.

Any further information can gladly be given, thank you.

Cujo67

[Quade]

Problem is, after a certain amount of time downloading, doesn't do it initially I'd say maybe 30 minutes to an hour, the files that disappear from the list as downloaded get re-added to the bottom of the download queue. And if I take a file and move it to the top of the queue, most disappear without showing anything in the failed, downloaded, or log, but a few will display as a duplicate download.

I've seen another report of this. I wonder if it could be retries? Retries will re-add a file assuming that actual file is still there in the list. If it's not there, it might get re-added. If you have the duplicate checker enabled, it should catch this though that's not ideal. I'll have to see if I can reproduce this. Maybe it'a an issue when you have a shitload of files in the download list.

Another thing to note is autopar is disabled because I prefer having a .rar to ensure file integrity is legit in the future.

You might just want to disable unrar but, leave autopar turned on so, Newsbin can repair the files. RAR's don't ensure integrity. If the RAR file gets damaged, its' just as useless as if the file inside it gets damaged. Keeping PARS around though, would ensure you can check and repair files as necessary.

[cujo67]

Think I've figured it out.

The list was about 50k of files last night, each one ranging from 200k - 1 meg.

Signature file is 28 megs. I think the duplicate checking got backed up, because I paused all files on the download list, not by the big pause button at the top but selecting all files then 'Paused Download'. New files are still popping up at the bottom and dropping off, typically as duplicates in the log file.

Appreciate the prompt reply to this problem, after it's done popping new files at the bottom of the queue I'll move the signature file out of the directory and see if that'll fix it.

Are there any utilities available for the signature.db3? I'd love to be able to just scan directories to use when leeching different groups. I'd love to hold on to this signature file but at this rate it's bogging down progress . Thanks!

[Quade]

Signature file is 28 megs. I think the duplicate checking got backed up, because I paused all files on the download list, not by the big pause button at the top but selecting all files then 'Paused Download'. New files are still popping up at the bottom and dropping off, typically as duplicates in the log file.

I don't think Signature DB has anything to do with this issue. I think there's a timing problem brought on by having a crapload of files in the download list. That a retry is triggered and by the time it's processed, the file that triggered it has already left the download list so, the retry adds the file instead of updating an existing file. In 6.50, retries are handled inline meaning there is no potential for the file to be added again. The reason you see the signature matcher killing the re-added files is because you've paused the other 50K files in the list. If you just let it run, eventually when these dup files downloaded, they'd get caught but the dup checker.

There's a tools somewhere on the main site that lets you feed existing files into the duplicate checker. Might be in the download page.