UnRAR progress bar inaccurate
UnRAR progress bar inaccurate
I usually only download full Blu-ray rips lately, so the behavior of the progress bar where it zips up to 100% almost immediately then spends the rest of the time stuck there is a lot more noticeable since it can take quite a bit of time to finish. I can't even try to guess how far along it is.
Re: UnRAR progress bar inaccurate
UE just runs unrar, unrar returns progress.
But we need to check it is not windows handling of progress bar, can you give me an example, here or better email screenshots, I'll check if the same is here.
But we need to check it is not windows handling of progress bar, can you give me an example, here or better email screenshots, I'll check if the same is here.
Re: UnRAR progress bar inaccurate
Sorry for the delay. I don't download 50GB posts that often. And the one I just downloaded didn't misbehave this time under my watchful eye 
Does unrar provide progress by percentage of files unrared rather than actual bytes unrared? If that's the case, unraring Blu-ray with a couple hundred small files followed by one huge movie .m2ts file could make the progress bar seem very lopsided as say 267 of 268 files were already processed, but the 268th file was 48GB in a 50GB archive.
Does unrar provide progress by percentage of files unrared rather than actual bytes unrared? If that's the case, unraring Blu-ray with a couple hundred small files followed by one huge movie .m2ts file could make the progress bar seem very lopsided as say 267 of 268 files were already processed, but the 268th file was 48GB in a 50GB archive.
Re: UnRAR progress bar inaccurate
It is difficult to tell, there is a callback function from winrar which provides the progress, unrar is third party code (but I fixed several bugs there). Ideally it should work the same as in winrar of the same build, but there are differences.
If the progress bar works ok otherwise and winrar shows the progress correctly then it is some peculiarity with the code of the unrar library.
If the progress bar works ok otherwise and winrar shows the progress correctly then it is some peculiarity with the code of the unrar library.
Re: UnRAR progress bar inaccurate
I think it's just multi-part rars created with RAR 5.0. I've created some with passwords and they all behave the same way. I'll play around and see if I can narrow it down more. Nothing created with RAR 2.0 behaves improperly.
Re: UnRAR progress bar inaccurate
Any updates on this? It definitely is WinRAR 5.0 archives that don't display the progress properly. Some extraction operations can easily take upwards of 45 minutes (especially if the poster is one of those nitwits who doesn't use store mode on something that's already compressed). It would be nice knowing how far along it is.
Re: UnRAR progress bar inaccurate
Finally figured it out after encountering the issue when unraring a multipart file containing a large number of small files.
The calculate file size function is called too early in the unrar source code (not sure if it is modified or the original code).
Yes, it might be only for unrar 5 format, the information about "new numbering" is contained in a rar header flag somehow.
NewNumbering=(MainHead.Flags & MHD_NEWNUMBERING)!=0;
Otherwise it considers the files as the "old" numbering .r00 .r01 etc., now I made it to recalculate the total size once when the numbering type changes from old (initial) to new as the result of the rar header, it should be enough to fix that.
So if such situation arose, it would reach 100% on the first rar part. It is only related to the shown progress, the files are unrared normally.
In the meantime no other known issues and it is maybe not enough for another release right now given the last one was only a week ago.
Both currently maintained versions with the fix can be downloaded here:
https://www.usenetexplorer.com/temp/ue_ ... essfix.rar
When integrating third party code on the source code level there is always risk, I tried to integrate newer unrar code, but when trying to use it asynchronously there are rare statistical crashes in the code, and as the functionality is the same it doesn't make sense to turn users into guinea pigs, so it made more sense to adapt older working code to work asynchronously, the code which was fixed to have zero problems many years ago, along with adding an option to run the command line unrar utility as a separate process whatever version the user wants.
The calculate file size function is called too early in the unrar source code (not sure if it is modified or the original code).
Yes, it might be only for unrar 5 format, the information about "new numbering" is contained in a rar header flag somehow.
NewNumbering=(MainHead.Flags & MHD_NEWNUMBERING)!=0;
Otherwise it considers the files as the "old" numbering .r00 .r01 etc., now I made it to recalculate the total size once when the numbering type changes from old (initial) to new as the result of the rar header, it should be enough to fix that.
So if such situation arose, it would reach 100% on the first rar part. It is only related to the shown progress, the files are unrared normally.
In the meantime no other known issues and it is maybe not enough for another release right now given the last one was only a week ago.
Both currently maintained versions with the fix can be downloaded here:
https://www.usenetexplorer.com/temp/ue_ ... essfix.rar
When integrating third party code on the source code level there is always risk, I tried to integrate newer unrar code, but when trying to use it asynchronously there are rare statistical crashes in the code, and as the functionality is the same it doesn't make sense to turn users into guinea pigs, so it made more sense to adapt older working code to work asynchronously, the code which was fixed to have zero problems many years ago, along with adding an option to run the command line unrar utility as a separate process whatever version the user wants.