Par2 thread hangs checking blocks (causes other things to fail)

[Hecks]

Quick, more virgins needed to summon him!

[thebeing]

2 month update:

The Par2 bug is definitely triggered by joining multiple NZBs (either on index sites or in altbinz) into a single collection. While it was a bit of an inconvenience, I took Hecks suggestion to never join NZBs into a single collection, have each NZB download to its own folder, and make use of the UnRAR directory functionality, I've not run into the bug again *knock on wood*.

[thebeing]

Found another workaround to this issue which doesn't require avoiding creation of NZB collections, and downloading to separate folders.

If I move all the unpaused PAR2 & SFV for all the files to the very end of the NZB collection, I never get PAR2 hangs, and everything is checked/joined/unrared as normal after downloading completes. This takes trivially longer than checking at the same time as downloading, but never hanging is a major advantage.

Maybe having a "Move all PAR2 & SFV to the end of the queue" option would be useful, if a proper solution for the PAR2 thread hanging on NZB collections is never found.

[dh2]

The following bug has happened in all versions of Alt.Binz I've used (Free version & 3.7.1 - 3.8.5). It has finally gotten annoying enough to report.

Using ver 0.39.9 right now. (Win Xp, Intel i7 920, Asus p6t6 ws Revolution)
Yes, this is has been a definite issue for quite a few versions now. I need to find the last "stable" version or just write off Altbinz as useless and find an alternative.

Hard to know what kicks it off, but joining multiple pars of say all the episodes in a season into 1 is one way to do it. Just last night: mkv files of bluray rips  12 episodes +14 episodes +12 episodes. each episode had it's own nzb from teevee group, with each show joined. When I wake up 8 hours later, 1st 12 episodes checked & unrared, the next 14 par check is jung on ep 9 while all 14 are DLed + 3+ episodes of the next 12

Sooner or later the program just starts to eat CPU and go into molasses mode in checking the pars. If you're willing to wait for many hours, it will actually get finished checking the pars and unraring. 

Nirsoft's ProcessActivityView show altbinz to be slowly reading through the files that were written to disk hours before. I have a jpg pic of this.

can you please fix this or point me to the last "stable" version of AltBinz

[Rdl]

So, you're saying you had one collection with 38 par2 sets in it? Ep 9 files it appears to 'hang' on - were they complete?
May I suggest 38 collections each with one par2 set instead.

In any case I'll take a look as soon as I can.

[thebeing]

What dh2 describes is identical to the issue I originally reported.

100% CPU bug combined with extremely sluggishly reading files of files, which loops ~30 times per par2 set @ KB/s speeds.
Files which normally would take less than a minute to check, suddenly take hours.



The issue never occur when you have only a single par2 set per nzb collection.

The more par2 sets you have in a nzb collection, the more likely it is for the problem to occur.

More often than not, the par2 issue will be triggered when checking a file with 0 missing blocks (100% complete). Likely no relation.

[Rdl]

One more question. Were all 38 par2 files loaded (pushed in front on import) before download of the main files?

[dh2]

So, you're saying you had one collection with 38 par2 sets in it? Ep 9 files it appears to 'hang' on - were they complete?
May I suggest 38 collections each with one par2 set instead.

what I quoted was just the latest.
1 collection of 12 joined nzb you (do have 'join' like joinging all the episodes of a season so that they all end up in the same folder)= 12 pars files, with par being checked right after 1st of the 12 parts is DLed while next is being DLed. Collection 2 14 nzb joined = 14 par files, & collection 3 12 joined nzb = 12 par files

each par file es DLed after each episode is in the 'joined' collection

It could've gone into molasses mode at anytime while I was sleeping. This is just one example of a problem that has been coming up for quite a while. I can't remember at which version that it started. And looking at the bugs reported lately, that it is actually the same problem that people are trying to explain in their own way.

[thebeing]

In my case, I've seen it occur both ways. I normally have the "move small par2 files to front of queue" option enabled, but occasionally I would join a NZB within Alt.binz. The only way to fully avoid the problem would seem to be having nothing downloading from a particular NZB collection when the PAR2 files from that collection are being checked. Hence my "move small par2 files to end of queue" suggestion as a potentially effective workaround if a fix cannot be found.

I suspect that it may only have a chance of triggering when downloading gets ahead of par2 checking the previous file. In other words, at least 2 par sets which need checking from the same NZB collection, are in the PAR2 tab at the same time. That said, for the past year this issue has caused me to go out of my way to avoid using NZB collections in Alt.Binz, so aside from once again trying an NZB collection and experiencing a problem a few weeks ago, the details aren't as clear in my mind as when I originally reported it.

[Rdl]

And few more questions:
-Once it starts going slow through files, how many par2 sets are there in par2 tab.
-File that is currently processed (using Nirsoft's ProcessActivityView) by altbinz. Is there such named file in any par2 set loaded by altbinz?
-Once that file is finished - was that file complete 100% or not?

[thebeing]

I've seen it occur after only two to three 250MB files (out of around five in a collection) were downloaded to the same empty directory.

For how many par2 set in the par2 tab, it would depend how quickly I noticed.

After further investigation with Process Monitor, it looks like Altbinz is getting stuck in a loop when parsing files. It is doing ~30 loops reading each file part in 640KB chunks (which happens to be the par2 block size) at 1280KB offsets for a total of ~1500 read operations per file part in this case.

I've never used Nirsoft's ProcessActivityView, so I don't understand that question. But I did previous use Sysinternals Process Monitor with an AltBinz.exe filter, and the file currently being checked/read by the par2 thread would fill the log. Though I'm unsure if that's what you were asking or not.

If a file happened to be download incomplete with missing parts, and this par2 checking issue occurred, altbinz would not make any attempts to automatically download additional par2 files and repair. If par2 files needed for repair were downloaded manually, they would not be added to the par2 tab under the small par2, nor checked.

[dh2]

And few more questions:
-Once it starts going slow through files, how many par2 sets are there in par2 tab.
-File that is currently processed (using Nirsoft's ProcessActivityView) by altbinz. Is there such named file in any par2 set loaded by altbinz?
-Once that file is finished - was that file complete 100% or not?

1. I don't know at what time it went into slow mode this time ( i was asleep) but when I became aware of it around 20 par set had been verifiied and unrared. about 3 par sets were loaded, red in color, with no progress on them. And at least 9 more sets (about 2.2GB of rar w pars file)  had been already DLed to HD without showing in the par2 window.

2. No; altbinz is SLOWLY reading thru files (rar) that it had already written to HD hours before. I can manually check the pars of a set already written to HD and all is fine; checking pars of file that Altbinz is currently "slow" reading gives a pars result of "unkown".
I can manually unrar a set that the slow reading hasn't come to yet with no problem, but when manually unraring a set the altbinz is slowly reading through results in winrar asking for that particular rar file as though it is not present. Waitin a few seconds til altbinz is finished with it, saying OK to winrar and it goes on, til it reaches the next file that altbinz is slow reading.

3. None of the files have problems before or after. I'm sure if I had just let altbinz work it's slow ass on, that a lot of hours down the line that it would've been done.

if I had figured out someway to explain the problem in written form I would've reported it long time ago, cause even  now I do not do a good job of it. I do have a ProcessActivityView log file that I saved some weeks ago: here is a sample of what is in it when altbinz goes into molasses:
"18:55:34.3436076","altbinz.exe","2896","ReadFile","Z:\Main\00.Daily\Modern.Family.S03E01-24.BDRip.XviD\modern.family.s03e22.bdrip.xvid-demand.r04","SUCCESS","Offset: 0, Length: 768,000"
"18:55:34.3678107","altbinz.exe","2896","ReadFile","Z:\Main\00.Daily\Modern.Family.S03E01-24.BDRip.XviD\modern.family.s03e22.bdrip.xvid-demand.r04","SUCCESS","Offset: 768,000, Length: 384,000"
"18:55:34.3905134","altbinz.exe","2896","ReadFile","Z:\Main\00.Daily\Modern.Family.S03E01-24.BDRip.XviD\modern.family.s03e22.bdrip.xvid-demand.r04","SUCCESS","Offset: 1,152,000, Length: 384,000"
"18:55:34.4131893","altbinz.exe","2896","ReadFile","Z:\Main\00.Daily\Modern.Family.S03E01-24.BDRip.XviD\modern.family.s03e22.bdrip.xvid-demand.r04","SUCCESS","Offset: 1,536,000, Length: 384,000"

[Rdl]

But that sample is 70ms long. Based on that I would estimate around 1sec for whole file?? It would help if you got whole log for slow processing file. In this one I don't see anything unusual. First 2 blocks read and then block by block. I really need to know if that slow file was complete or not and if there was par set (for that file) loaded before slow checking of that file.

[dh2]

But that sample is 70ms long. Based on that I would estimate around 1sec for whole file?? It would help if you got whole log for slow processing file. In this one I don't see anything unusual. First 2 blocks read and then block by block. I really need to know if that slow file was complete or not and if there was par set (for that file) loaded before slow checking of that file.

I can't see how to attach the log file here to my post
The whole log file is 12675 lines long  just the processing (slow reading) of 1 15mg par file is 1887 lines with start time "18:55:36.4668250"
and end time of "18:56:21.5671605". That's 45 seconds for a 15MG, which usually takes less than 1 second when all if fine and par files are checked.

[dh2]

What dh2 describes is identical to the issue I originally reported.

thebeing,
Thanks for starting this thread and not giving up on it!! I seldom checked the forum, and didn't know how to describe the problem, which has bothered me for some time. It's only thanks to your post, and that I saw what you had written, that I decided to add my 2 cents worth.
I think some of the other 'bug' posts recently have been other users' attempts to describe the same problem, without much success.