newsbin.com

Using NBP 6.31 build 1877 on windows XP SP3

It's not a particularly annoying bug, if in fact it is a bug, but I'm finding that after a large batch of downloads, some, but not all, nb2 files are being left on the hard drive. It's not that the extension isn't being changed. The finished versions are there too & the par2 check works fine. It's just that I always seem to have a few nb2 files that haven't been deleted after the download is complete.

It's not that the extension isn't being changed. The finished versions are there too & the par2 check works fine

This is good information. If suggests that maybe Newsbin uses a different rename mode "Copy Mode" and copy mode isn't cleaning up properly.

Thanks.

This has happened to me as well.

Windows 7 Home Premium
NB 6.40b2

The files decode properly, but there are some (IIRC usually just one) .NB2 file left over.

Do you have it set to download all the PARS? I wonder if it's repairing a file into existence that's already an NB2 so, the NB2 rename process fails.

Quade wrote:Do you have it set to download all the PARS? I wonder if it's repairing a file into existence that's already an NB2 so, the NB2 rename process fails.

I don't know if that could be one possible cause or not, but I've seen it happen where there were no pars.

I had already moved my files from a download directory to another hard drive, and ran my 3rd party duplicate file checker, and it found the nb2 copy and the renamed file in the same directory, so they even have a hash check match. There were no pars for that set of files.

I have no idea what causes it, but it's pretty rare. My experience with running autohotkey scripts on Windows2000 and WindowsXP revealed that Windows2000 pretty reliably does what you ask it to do, and XP sometimes does, and sometimes it's off doing something else for a while and it gets around to processing your request eventually, so I had to add timing delays to my autohotkey scripts to allow for this XP behavior. I'm not suggesting you do this to Newsbin, as I think this problem is small enough to live with, but I would guess it's some kind of timing issue. These random nb2 files can be deleted or moved...it's the nb2 files that can't be deleted (without shutting down Newsbin) that are a bigger issue for me, when I try to remove incomplete downloads.

My AutoPar settings are:

Automatically UnRar
Delete RARs and PARs on successful repair
Pause PARs and only download the ones needed for repair

Been trying to reproduce this. So, I am looking at it.

I'm on a fully updated version of Windows XP Pro. SP3 build 2600
I'm using Newsbin Pro 6.30 build 1837.
I have a Giganews Diamond account. Since I've been a NBP user longer than I've been a Giganews user, I don't have the version of NPB that comes specifically set up for GN. It's the standard Pro version.
I just downloaded a batch of 107 files, which came with a single par2 set for the lot of them.
I'm set to Automatically UnRar & Delete Rars & Pars, but this set did not include any rar files, so it should have only run the par2 test.
I have Aggressive Assembly Mode selected.
I do not have Enable Post UnRar Filter selected.

The files all downloaded, including all the par2 files. (they are, as usual still in the download list, marked as downloaded.

Running the par2 check by hand gives me "no repair needed".

As well as the original 107 binaries & the full set of par2 files, I have 8 undeleted nb2 files, corresponding to numbers 94 & 100-106 of the 107 files.

Hope this helps.

I'm using Newsbin Pro 6.30 build 1837.

I'd upgrade. I still think my theory is valid. The files were repaired into place during the download and it left the NB2's behind. I'll have to think of some way around that. It's a timing issue.

I am also getting several *.nb2 files. It appears that Newsbin sometimes fails to rename the files. Sometimes it is fixed by AutoPar (AutoPar renames before extraction).
BTW, running 6.40B2.

Quade wrote:

I'm using Newsbin Pro 6.30 build 1837.

I'd upgrade. I still think my theory is valid. The files were repaired into place during the download and it left the NB2's behind. I'll have to think of some way around that. It's a timing issue.

I misread. It's build 1877, not 1837. I somehow missed the last upgrade notice. Getting 6.33 now.

Sometimes it is fixed by AutoPar (AutoPar renames before extraction).

Autopar never renames NB2 files. Just say'in....

Autopar repairs the files into place meaning you had no files, autopar kicks in and creates these files out of thin air while the downloads are still NB2's. That's why the NB2's get left behind. Newsbin notices that the files are already there and throws up it's hands. I'll bet this mostly happens with "split set" meaning the PARS aren't combined with the files.

After upgrading to 6.40b3 (build 1929) I do not see any more residual .NB2 files.

That's good to hear. I did re-do some things that might be related.