UnRar 111% Completed

[coyote2]

I've noticed filesets going over UnRar 100%, to 111%. (I've seen occasional enormous % numbers like 10-ish digits long.)

Otherwise all is well. I don't recall this happening before.

6.80b5

[Quade]

Thanks. I'll have to check it out.

[Biship]

Occasionally see the same thing.

[coyote2]

here's a screenshot:
<image that shows the problem but TMI for this forum>
-----------------------------------------------------------------------------------------------
Edit: Sorry about that! Here's a revised image with the filesetname erased: (I hope that resolves the original TMI.)

[jbakers]

Mine sometimes go's all the way up to 300/400 %

[coyote2]

Here's one that went to 4240129715%


(I've also seen the ten-digit number start with 6, 8, or 9. However please note that such ten-digit number-high % numbers may only happen due to a PAR repair issue reported over in http://forums.newsbin.com/viewtopic.php?f=44&t=42130&p=220376

(In other words, in the absence of the PAR repair issue [which for now I deal with by renaming par2Repair.dll], the PAR repair % is never > 3 digits.)

[RayMark]

I also just got 1115% or 1116% with beta 6.

The rar had 1116 parts:
part0001.rar - part1116.rar
- so, clearly, 1% per 1 rar part

What is interesting here: the rar contained inside a folder with 24 .mkv files inside the folder, but the folder was lost - the rar was extracted without the folder, as if command e was used instead of x.
I've seen many cases when NewsBin extracted with folders, so this is strange - perhaps discarding folders is a new feature of 6.80 beta 6?

[kirm]

I've seen many cases when NewsBin extracted with folders, so this is strange - perhaps discarding folders is a new feature of 6.80 beta 6?

Quade is already aware of that issue. It just started last week with beta 6. I believe he said something along the line with the changes made to handle long paths and or filenames. Hopefully fixed in next release.

[coyote2]

I also just got 1115% or 1116% with beta 6.

The rar had 1116 parts:
part0001.rar - part1116.rar
- so, clearly, 1% per 1 rar part

Interesting!
I had only noticed that the % got bigger the larger the total fileset size.

[Quade]

Quade is already aware of that issue. It just started last week with beta 6. I believe he said something along the line with the changes made to handle long paths and or filenames. Hopefully fixed in next release.

Yeah, it's already fixed.

[RayMark]

Quade is already aware of that issue. It just started last week with beta 6. I believe he said something along the line with the changes made to handle long paths and or filenames. Hopefully fixed in next release.

Yeah, it's already fixed.

It would be great to get that fixed version as soon as possible. Because I had multiple mishaps with beta 6, the worst - with BluRay disks extracted together, and they have BACKUP folders, so many -(0001) files and it was difficult to reconstruct exactly the original BluRay folder structure. Even worse - several BluRay disks extracted together. It was faster to re-download with auto unrar switched off.

[coyote2]

Because I had multiple mishaps with beta 6, the worst - with BluRay disks extracted together, and they have BACKUP folders, so many -(0001) files and it was difficult to reconstruct exactly the original BluRay folder structure. Even worse - several BluRay disks extracted together. It was faster to re-download with auto unrar switched off.

I had that happen too w/a Bluray . Wish I'd thought to switch off auto-unrar!

[kirm]

I had that happen too w/a Bluray . Wish I'd thought to switch off auto-unrar!

This is why I keep my settings to not delete rar files after auto-unrar. Always have the original on hand for situations like this.

[RayMark]

If you download a lot, deleting manually (but first, matching with extracted, checking if extracted correctly) becomes way too much work.

Actually, it might be even dangerous: sometimes pars show that rars are OK, but when extracting - they are not. So, if rars are not deleted after they are successfully extracted, it is difficult to be sure if the post was extracted successfully or not. Although, if there is a problem, usually there are multiple attempts and multiple copies of extracted files.

[coyote2]

If you download a lot, deleting manually (but first, matching with extracted, checking if extracted correctly) becomes way too much work.

Absolutely.

Actually, it might be even dangerous: sometimes pars show that rars are OK, but when extracting - they are not. So, if rars are not deleted after they are successfully extracted, it is difficult to be sure if the post was extracted successfully or not.

Also true; it's easy to simply know that all went well because the rars have disappeared. (I guess one could find that out from the logs instead, but I've almost never looked at those.)

Although, if there is a problem, usually there are multiple attempts and multiple copies of extracted files.

[RayMark]

I also just got 1115% or 1116% with beta 6.

The rar had 1116 parts:
part0001.rar - part1116.rar
- so, clearly, 1% per 1 rar part

Interesting!
I had only noticed that the % got bigger the larger the total fileset size.

Also, if a rar has only 33 parts, the progress indicator goes to 33% only and then suddenly the unrarring ends successfully.

[Quade]

I haven't looked at it yet. I agree it's still messed up.