newsbin.com

Once in a while I'm still getting the problem where the download list has some open items that are paused.

In the last case I had 3 sets of files, all of which were PARs for content that was already downloaded before. I believe they were all the product of automatic group downloading (using a filter).

The files were all paused and obviously were not needed. Any ideas why they were still on the lists?

Pars only or pars mixed with other files?

I will check next time. If there was a file, it might have been a single sample file.

Hi - I have what sounds like a similar/same issue. Should I make a new thread or hijack this one to describe my issue? Hope hijacking is ok.

I'm using NewsBin Pro v6.0 on a Win 7 box. I'll download a combined RAR/PAR set. All RARs will download, but the PARs (except first one which does download) get auto paused and never download. Yet often the RAR set is corrupt and needs the other PARs downloaded, but NBP doesn't realize this and just sits there. The RAR set never gets unRAR'd.

My workaround is to go in and select the remaining PARs and "Resume Download" manually.. then they download, at which time either NBP goes ahead and repairs the RARs automatically or I can do it with QuickPar. But it's a pain.. I have to remember to go in manually with every download set and forcibly resume the PARs ahead of time just in case they will be needed once the RARs finish downloading.

I looked for a feature in NBP 6.0 to disable the auto-pausing of PARs but did not find it. If such a feature exists (does it?), this should fix my issue, but I would still wonder why the presumedly more intelligent method (NBP only downloading PARs if it needs them) isn't working for me.

It does.

I'd probably upgrade to 6.11 and I'd delete the autopar2.db3 files, on the chance that it's corrupt.

I am on build 1342, issue occurs exactly as Pork describes...

I am sure the issue is related to partial downloads or some error in the rar files since this doesnt happen every time.

I have exactly the same problem. All the files download except the par files so I have to select them and the unpause them and then everything works. THis has only started happening with version 6

Did you try any of the things that I suggested?

Please remind me what to try.

I checked and there is always at least one non par dile when this happens. I am not sure why it gets stuck but 9 times out of 10, unpausing pars will get it all worked out.

I think it is waiting on a partially complete file, and when it gets stuck it doesnt bother checking the pars although they can fix the issue. So, it sits and waits for that file to become available rather than try to unpar.

Reporting back... I closed v6.0, deleted the autopar2.db3 file, and then upgraded to v6.11 build 1342.

I've done a few downloads in 6.11 now and so far no problems, but then again this problem didn't occur with *every* download before (the auto-pause of PARs happens every time, but in many cases the download is not corrupt so they are not needed), so not sure this worked yet or if I've just been lucky so far. I'll have to watch it over time.

Quade, you mention there *is* a feature to disable auto-pausing the PAR files.. I looked around and for some reason I'm still not finding it. Can you point out where said feature is? Thanks.

I've been running build 1342.
I left NB; deleted autopar2.db3; and restarted NB 6.11
The download in process was deleted. (not the end of the earth)
But the symptom of needing to do the manual unpause, quickPAR, unRAR remains.
Is it a clue that almost all queued segments in the download list that isn't "Downloading" or "Downloaded" says "Paused" and not "Idle"?

Quade

I now have about 10 files in my queue that have this problem now.

1. Contains a sample files, all files in this batch seem to be par2 files. I'm 90% sure this came from an automatic download regex rule. The first Par2 file has been downloaded, all others are paused. Unpausing would probably make this decode and go away (they are in my queue awaiting your instructions).

2. A second batch of just Par2 files, same behavior, same probable source.

3. A proper file. It seems that the main RAR file is missing (it's not on the download list!). Block count is 2235/2372, so obviously it cannot repair them. However, there are 10 PAR2 files paused that would have allowed this sequence to finish. Again, in all likelihood this came from a rule, so it might be possible the RAR, that the rule missed it somehow, or even that it was either never uploaded or uploaded last. I just unpaused the PAR2 files and almost immediately it started repairing itself.

4. The rest are pretty much either a variation on 1+2 or 3.

My conclusions from this:
a. If a critical file like the RAR file itself is missing, NBP doesn't try to see if there's a way to repair it, it prefers to wait for that critical file even when not doing anything else at all.

b. If there are regex rules that cause it to download just PAR2 files, it never tries to download them or see if they can repair. Note that theoretically - someone can upload just PAR2 files that can repair into a proper file. In the case where there are no actual files to decode, the PAR2 files should unpause.

c. If NBP is just sitting there not doing anything or downloading anything and it has just paused PAR2 files, any reason in the world why it's not just unpausing them to try and finish the sequence? Seems pretty obvious to me...

1 and 2 are to be expected. When you have a bunch of pars sitting there, Newsbin is waiting for the rest of the files to show up and complete the pars.

So, this is normal.

3 - 6.2 might address this problem. It'll start to dribble through par files if it notices a file just sitting there doing nothing. There are other cases where the main RAR is missing from the PARS but still downloaded. In that case, again with 6.2, Newsbin will look on disk for the main rar.

At some level, having to manually intervene when you get weird sets like this isn't unusual. All Newsbin can do is make a best effort guess at what's going on. It can't know, when it's got a block of pars sitting there, whether the files the pars belong to have already downloaded or are about to be downloaded or will ever download. Most people would rather not download useless pars unless they're needed.

Note that 1&2 dont contain any actual files because those were included in another file batch that was downloaded and decided long ago.

The solution is simpler than that.

If nbp has nothing else to do and there are paused pars, unpause the first par... Once thatis done, unpause the next one.

This will solve 100% of these issues.

No it won't. It might solve your problem but, it'll cause problems for other people. I'm not saying the way it works now is the best but, I'd probably get just as many complaints or more if I implemented your scheme. "Why is it downloading pars for files I decided not to download". Do you actually need these pars? Seems like they're getting into the download list but, the files themselves are long gone.

They are gone because nbp already downloaded them. They should either download or deleted.

I think if they are in the download list they should be downloaded.

I cant see why anyone would complain.

oferlaor wrote:They are gone because nbp already downloaded them. They should either download or deleted.

I think if they are in the download list they should be downloaded.

I cant see why anyone would complain.

I've noticed that too, PARs stick around long after the rest of the files have all been successfully downloaded. Unpausing these would cause unnecessary bandwith. If the main PAR2 checks out, then the rest of the PARs should be discarded, IMO.

For some reason the pars are in their own download group rather than the same one where the main file resided.

Maybe thats the real culprit for my issues 1 & 2 ?

oferlaor wrote:For some reason the pars are in their own download group rather than the same one where the main file resided.

Maybe thats the real culprit for my issues 1 & 2 ?

I regularily have PAR2 files in a separate group to the main file set. This seems to cause no problem if both the main set and the par2 set are in the download list beofre the download starts. Whatever the order Newsbin seems to be able to sort them out.

What I an see IS likely to cause a problem is if the PAR2 set is added AFTER the main file set has completed its download. I suspect that in such a case Newsbin is unable to associate the PAR2 set with the now vanished original main file set. It realises that the PAR2 files in isolation cannot recreate the file set purely from the PAr2 files and therefore sits around waiting to be told what to do.

What I an see IS likely to cause a problem is if the PAR2 set is added AFTER the main file set has completed its download. I suspect that in such a case Newsbin is unable to associate the PAR2 set with the now vanished original main file set. It realises that the PAR2 files in isolation cannot recreate the file set purely from the PAr2 files and therefore sits around waiting to be told what to do.

This is what I suspect is happening too.

since this happens as part of a REGEX autodownload, this might explain it if the upload sticks the PAR2 section at the end of the upload process.

NBP would then see the first set only, and then add the second one incrementally.

I still think that unpausing the PARs in NBP's idle time would be of help - it would download the pars, and then when it sees there's nothing to fix, just delete them after the PARs are fully downloaded.

oferlaor wrote:I still think that unpausing the PARs in NBP's idle time would be of help - it would download the pars, and then when it sees there's nothing to fix, just delete them after the PARs are fully downloaded.

That is OK if you do not care about excess volume. However many people will have ISP accounts that apply monthly limits so they do not want files downloaded if they are not needed..

Compaction won't work with autodownload because the pars typically show up after the RARs do. In the case of perfect RAR's, it'll unrar them even with no pars so, that's probably why you occasionally get naked PARS like this.

So, what's the solution? remembering that the files were already extracted?

It's really annoying to see this up, since it needs manual intervention, which I'm trying to minimize.

Will 6.2 resolve the other issue I mentioned (issue 3)?

Pork wrote:Reporting back... I closed v6.0, deleted the autopar2.db3 file, and then upgraded to v6.11 build 1342.

I've done a few downloads in 6.11 now and so far no problems, but then again this problem didn't occur with *every* download before (the auto-pause of PARs happens every time, but in many cases the download is not corrupt so they are not needed), so not sure this worked yet or if I've just been lucky so far. I'll have to watch it over time.

Quade, you mention there *is* a feature to disable auto-pausing the PAR files.. I looked around and for some reason I'm still not finding it. Can you point out where said feature is? Thanks.

Almost 2 weeks now (and maybe 10 large downloads) running with 6.11 and I'm happy to report no stuck downloads so far. Again, maybe I've just been lucky and had no RAR corruptions, but with v6.0 I couldn't go more than 1 or 2 downloads without this issue so I think 6.11 addressed it. Good deal.

Quade, still curious where the feature is you mentioned to disable autopause of PARs...

Quade wrote: Most people would rather not download useless pars unless they're needed.

No shit? Then why do you code Newsbin to download every par it can find if autopar is turned off? Wouldn't "Disable Autopar" suggest that you want to download pars manually? And since you can't delete pars from the download list without deleting everything else, the only way around it is to manually expand every file you want to download, and make sure that no pars get into the download list.

Why do you make us fight your software?

What do you want? Should they stay in the download list or queue to the wish list? I really have no opinion about what happens to the pars if you turn off autopar.

Quade wrote:What do you want? Should they stay in the download list or queue to the wish list? I really have no opinion about what happens to the pars if you turn off autopar.

Queuing them to the wish list would be great. An option to queue them to the wish list even when autopar is turned on would be even better. There is an option on the autopar panel that says "Disable Automatic PAR unpausing," but unless you just hooked it up in the last couple of releases, it doesn't work. It definitely didn't work in 6.11.

I don't suppose there's any way to talk you in to putting the V6 internals into the V5 UI? I think all the UI changes in V6 (separate autopar window gone, can't delete individual parts of a file from the download list, can't keep the pars paused, etc.) have been for the worse, but V5 just can't handle the big newsgroups any more.

And sorry about my tone in the last post, but I was pissed when NB downloaded about half a gig of useless pars yesterday. My ISP has cut their bandwidth cap down to 5 GB a day (they have a higher tier that I would gladly pay for, but they don't offer it in the small town where I live, and the only other ISP here has an even lower cap), so that was 10% of my daily limit wasted.