NB6.50-Some files that downloaded in 6.42 now don't download

[stavros]

Hi,

I've just upgraded from 6.42 to 6.50. The upgrade went well and I can download headers and files seemingly OK, in most cases.

I noticed that some files that I queued for download, disappeared from the download list, but did not appear in the files list, and did not appear in the failed list either.

I queued some files that I had successfully downloaded a few hours ago with 6.42, and these failed in a similar manner, gone from d/l list and nothing in files or failed lists.

I did notice some DEBUG messages in the log that indicated some problem with the AutoPARPlugin:

[05:35:23] DEBUG AutoPARPlugin: Have a listing for all files but, not enough blocks to repair <filename goes here>
[05:35:23] DEBUG PostAssembly - Unable to get PAR Status - Getting largest PAR block: <subject goes here>

The files in question are small (750 KB) and the post properties list 3 records and all posts available.

Autopar is enabled,
auto unrar complete files is enabled,
delete rars and pars on succesful unrar is enabled,
pause pars is enabled

Any idea what is going on here?

Please let me know if you need more info.

regards
Stavros.

[Quade]

I queued some files that I had successfully downloaded a few hours ago with 6.42, and these failed in a similar manner, gone from d/l list and nothing in files or failed lists.

Are they still sitting there on disk already downloaded? Newsbin won't download duplicate files anymore. If it knows the file is already there and the file seems to be the same file that's currently downloading, the download will be aborted.

[stavros]

Thanks Quade - You're right, the files that I re-tried were already there.

But In the past, I would get an entry in the Failed File list, saying that it was a duplicate. I also have the Dup file name - auto rename option set - so if I add it to the download list with bypass filters, as I did in this case, then I would expect it to download again, and then rename the duplicate file.

I tried several more times and got only one instance of a message in the log identifying that a file already exists:
[00:47:55] DEBUG AssembleFiles: File already exists on disk: <filename goes here>

out of over 15 attempts, mostly, nothing happens - the entry just disappears from the download queue.

I also tried with a zero length file on the hard drive, and attempted to download it again - sometimes an entry would appear in the Failed File list as a duplicate, other times it wouldn't. When it didn't appear in the Failed File list, the zero length file on the disc would be overwritten, but no entry was made in the Files list showing a successful download.

I think that there is something strange/inconsistent going on with the way NB6.50 handles these situations.
It is definitely disconcerting to have files disappear from the download list and not find an entry on either the Failed Files list or the Files list.

regards
Stavros.

[Quade]

But In the past, I would get an entry in the Failed File list, saying that it was a duplicate. I also have the Dup file name - auto rename option set - so if I add it to the download list with bypass filters, as I did in this case, then I would expect it to download again, and then rename the duplicate file.

There's no point to trying to save the same file that's already on disk. If it knows the file is already there and verified it's the same data, what's the point of saving a copy? It's different for sure but, the old way wasn't better. It just got you a bunch of clutter you had to clean up. Now there's less clutter.

I've got some users who add the same 50,000 posts a day to the download list. Don't ask me why, I just know they do it. The new way is vastly superior to the old in cases where people are clueless. It's better than the dup checker too because it checks the first 200-600K of the file. Not the 20K the dup checker checks. The dup checker is still there. It still works. This just happens before the dup checker.

What I'm reading is that it's working the way it's supposed to be working. The files list entry, if it's already in the files list like it probably is, isn't replaced.

It is definitely disconcerting to have files disappear from the download list and not find an entry on either the Failed Files list or the Files list.

How often are you adding the same files to the download list over and over again? I added some logging to indicate it's aborting the download. If you have the logging set to debug mode. I think it's in 6.51.

[stavros]

Ok Quade, thanks.

As I said, what prompted this report was doing an upgrade, then seeing things disappear from the download list and not seeing anything appear in either the Files list or the Failed Files list, which was unexpected by me.
I don't knowingly download the same files multiple times, only when they happen to be reposted and I've forgotten that I've already got a copy. I relied on the dup check to identify that it was already downloaded and tell me so by putting an entry in the Failed Files list, with a reason why.

But, as the current behaviour is what is supposed to happen, then that's fine.

I don't normally run with debug, but I could, then if I need to check the reason that files are not being downloaded then I'll look in the log file for info.

Does this mean that the duplicate file rename options are now redundant?

Regards
Stavros.

[Quade]

Does this mean that the duplicate file rename options are now redundant?

No, if you still get two files with the same name but, different contents, you get a rename. I just tested it.

Downloaded a file. Renamed it to some other file. Then downloaded some other file with the same name. I got a rename because the contents were different. Lots of times you get files named as numbers for instance. They'll still get renamed as long as the contents are different.

[stavros]

ok, thanks Quade.

I'll grab the latest beta and try that.

regards
Stavros.