newsbin.com

Prior to RC6, if you had a partially downloaded file set on your hard drive (usually because you had to shut down Newsbin for whatever reason), when you restarted Newsbin it would sense that there were already existing files from the set on the hard drive, and flag those as "Downloaded". Once that was done, it would proceed to download only the files in the set that you hadn't already had a copy of in your download path, thus permitting you to resume from where you left off.

With RC6, on restarting, Newsbin ignores whatever files already exist, and simply starts downloading everything in the set again. When it comes to saving the newly redownloaded files in the download path, it appends "-(0001)" to the filenames, so you end up with at least two duplicate files for each file in the set.

I never changed any settings from RC5 to RC6, and the file sets are added in what I would regard as a completely normal way (selecting posts from groups or NZB importing).

As you can imagine, redownloading the same gigabytes of files that you've already downloaded previously is pretty annoying.

Note that this only affects Newsbin when it hasn't already flagged any files as downloaded, such as when the program starts. If files are flagged as downloaded (e.g. during the one session, you moved the set down the list for some reason), Newsbin will skip the download files as it should when it comes to them.

TL;DR RC6 can no longer detect previously downloaded file sets existing in the download path. It will start from scratch if the same set is re-queued.

How big are the individual files you're trying to resume? Bigger than 2 megs?

Quade wrote:How big are the individual files you're trying to resume? Bigger than 2 megs?

The fault isn't with resuming individual files, it occurs when you try to resume the download of a SET of files, in which any individual file may be of any size. As they are typically RAR files, yes, they're typically bigger than 2MB.

For a simple example, imagine there's a 30GB "filename.extension" archived up into 600 x 50MB rar's, along with 30 PAR files. These are posted to a newsgroup as a 630 part set, which you then download an NZB for. You import the NZB into Newsbin, let it download the first 300 files of the set, then you have to reboot for some reason.

The 300 downloaded files already exist in the download path. You reload Newsbin, and instead of recognising the 300 files already downloaded, it starts downloading the whole set again from scratch, putting a "-(0001)" at the end of each of the 300 duplicate files.

If you want to try it for yourself, find any NZB for something big with a lot of files. Let Newsbin download half of it, then shut it down. When you reload, it will start the download from scratch. I've had this happen with any NZB from any source I've tried it on, and with individual file sizes in the set ranging from 10MB to 250MB.

Again, I haven't changed any settings since RC5, where it worked properly at recognising existing files of a set in the download list. It would "grey" these out and proceed to download only those ones it couldn't find in the destination path.

Didn't see this topic earlier but I'm having the same problem as I mentioned here viewtopic.php?p=223691#p223691

It's a pain in the butt if you have a slow internet connection and I shut my notebook down at night and then discover I've downloaded 15gig for nothing.

UPDATE: regarding the use of "-(0001)" suffixes on duplicated filenames.

I stopped Newsbin last night after it had downloaded only two files in a large set, then restarted it this morning (and, of course, it proceeded to redownload those two).

Looking at the file dates for the downloaded files of that set, it turns out that only the previous downloads are renamed with the "-(0001)" suffix. In other words, all files with the correct name were the ones from this morning, and all files with the suffix were from last night.

This means that Newsbin knows enough to see that target files already exist in the destination, but no longer validates them as correct/preexisting for the set. It just renames the old ones and downloads them all again.

Here's what I'm talking about (12/03/18 is last night, 13/03/18 is this morning):

Code: Select all

13/03/18  10:16           117,976 z9J6MPFt5wWzXf1Kz902gIT8GJtLWnH33NxSWF65Q46Nd5vadLbh.36A17113.par2
12/03/18  23:41        52,428,799 z9J6MPFt5wWzXf1Kz902gIT8GJtLWnH33NxSWF65Q46Nd5vadLbh.part01-(0001).rar
13/03/18  10:17        52,428,799 z9J6MPFt5wWzXf1Kz902gIT8GJtLWnH33NxSWF65Q46Nd5vadLbh.part01.rar
12/03/18  23:41        52,428,799 z9J6MPFt5wWzXf1Kz902gIT8GJtLWnH33NxSWF65Q46Nd5vadLbh.part02-(0001).rar
13/03/18  10:18        52,428,799 z9J6MPFt5wWzXf1Kz902gIT8GJtLWnH33NxSWF65Q46Nd5vadLbh.part02.rar
13/03/18  10:18        52,428,799 z9J6MPFt5wWzXf1Kz902gIT8GJtLWnH33NxSWF65Q46Nd5vadLbh.part03.rar
13/03/18  10:19        52,428,799 z9J6MPFt5wWzXf1Kz902gIT8GJtLWnH33NxSWF65Q46Nd5vadLbh.part04.rar
13/03/18  10:19        52,428,800 z9J6MPFt5wWzXf1Kz902gIT8GJtLWnH33NxSWF65Q46Nd5vadLbh.part05.rar
13/03/18  10:20        52,428,800 z9J6MPFt5wWzXf1Kz902gIT8GJtLWnH33NxSWF65Q46Nd5vadLbh.part06.rar

Waiting for Newsbin to start a new set before closing is one way to workaround this incredible annoyance.

Another way is to pause the files in the set that would cause wasted duplicates, then monitor the progress of the remaining downloads and delete the job when it goes back to trying to download the duplicates (which it will, there's no way to stop it).

Either way, "unattended" is no longer an option if you find yourself in the situation of having to restart Newsbin for whatever reason.

I've just tested RC7 wth a number of partially downloaded file sets, and I can confirm that a restarted Newsbin once again resumes from where it had previously left off, only downloading those files that do not exist in the destination.

Thank you for fixing this.

Cool, thanks for confirming

This is happening to me in 6.82 for large files. What should my settings be in Newsbin?