autounrar issue in 0.28.4 & 0.28.5

[rtfmx9]

OK, here is the problem. OS:XP.  In both altbinz versions the same happens. I am using this nzb that has 2 parts of the movie (two avi files) plus subs, they are all listed in the par2 tab. Once all rars for the first avi are downloaded, it pauses (pause while unrar is set in options), autounrar is set to unrar into different directory. That happens (I can monitor while it's doing it), on PAR2 tab, unrar doesn't complete - progress bar goes up to some small percentage (anywhere from 3% to 30%) but log says "unrar finished", rar icon in th eunrar column on th epar2 tab gets its checkmark even though progress bar is still in low percentages and at that time, it deletes both rar files and the extracted avi file! It is set to delete only rar files! Then it proceeds and downloads the other avi rars and does the same with them - again resulting avi is deleted after unpacking!! Subs are extracted fine, though and progress bar on par2 tab is up to 100%. This happened with both versions of the Altbinz I tested with. If there is a single avi in the nzb it works OK. Very annoying.

If I set the options to not delete rar files after extraction, then they stay undeleted but resulting avi is still deleted. I can manually extract avis from rars without an issue!

Any suggestions?

Thanks!

[Hecks]

Very peculiar.  Do you have a link to the NZB (@ Binsearch, say)?

[rtfmx9]

I've sent you a PM with a link to the nzb...

[Hecks]

I'll forward it to Rdl.

[Hecks]

OK, just tested and all files in that NZB downloaded & unrared fine here with 0.28.5, and I didn't see any of the behaviour you describe.  Sorry I can't help more.

[rtfmx9]

That's too bad.  Obviously something in my setup is not the same? 
Why would it unrar and then delete the extracted file here? It doesn't make any sense!
I guess as a workaround I can set it to save rars after decompression so in case it decides to delete the unpacked file(s) at least I don't have to re-download everything again. Maybe delete to recycle bin would be better for cases like this? If it happens at least I could salvage rar files from there? Why not include that option with the unrar options?

[Rdl]

That's too bad.  Obviously something in my setup is not the same? 
Why would it unrar and then delete the extracted file here? It doesn't make any sense!
I guess as a workaround I can set it to save rars after decompression so in case it decides to delete the unpacked file(s) at least I don't have to re-download everything again. Maybe delete to recycle bin would be better for cases like this? If it happens at least I could salvage rar files from there? Why not include that option with the unrar options?

Does this happens everytime? Only with this nzb? It would help if you can reproduce it everytime. I'll try to fix test version in a next couple of days, so we'll see if that will help

[Hecks]

The only thing I noticed about that NZB (apart from the bizarre par set just for the NFO) was that the a & b files were alternating, so that both completed download at the same time (-ish).  But as I said, no problem unraring at my end, with 'Pause downloading while unraring' enabled.

[rtfmx9]

Does this happens everytime? Only with this nzb? It would help if you can reproduce it everytime. I'll try to fix test version in a next couple of days, so we'll see if that will help

Happens with this nzb every time. I tried it 3 times using different versions of Altbinz. On my third try, I turned off delete rars after unpack, autounrar deleted resulting avi that time as well but not the rars. I unpacked them manually and they worked fine. Can you include additional check that avi is present after deleting the rars or at least delete them to recycle bin? I don't get why and how this would happen?? And if it does, why not with other nzb-s as well? If I have one avi file in nzb (other nzb than this one), then it unrars fine and resulting file stays undeleted.

[stavros]

I can remember having had this problem in the past with 'interleaved' posts;  sorting the articles by name (and therefore reducing the likelihood two un-rar operations will overlap) prevents it from happening.   Given that 'pause download whilst un-rar' also circumvents the problem,  it's just got to be a race-condition in the un-rar/delete code.

[Rdl]

I can remember having had this problem in the past with 'interleaved' posts;  sorting the articles by name (and therefore reducing the likelihood two un-rar operations will overlap) prevents it from happening.   Given that 'pause download whilst un-rar' also circumvents the problem,  it's just got to be a race-condition in the un-rar/delete code.

There is no possibility for that. Everything is done in the same thread