Having developed a bunch of plugins that crawl through masses of data with unknown content, yet still trying to give the user an idea of expected completion, I have sympathy for what Ken must have faced.

- Do you simply report on the number of completed items?
- Do you take past progress into account when estimating time to complete?
- Do you report on the basis of bytes processed?

I usually try to do all of the above, and usually arrange for the task bar to move to a specific point at the completion of each task. For example, for 4 tasks, at 25, 50, 75, 100. It seems from your observation that Ken has done something similar, so that when he starts that last task, he has completed 88% of the tasks, but having an indeterminate amount of processing required to complete the final 12%.

I have one plugin that keeps track of bytes processed and adjusts the progress based on a prediction of the processing needed for remaining tasks. That has the odd result of the progress bar sometimes going backwards!   

(Actually I'm not sure about that - I think what happens is that each task segment's progress moves at a different speed)

I guess he should have tested using your collection. 

Semi-seriously, it is possible that "way back when", the ratio was a bit different, and his progress was based more on percentage of tasks completed, not time.

The custom backup shows 9 main things to backup, one of which is for cover scans. 8/9 is 88.88% so it's possible it's based on that.

A bit of background in a video explaining Why Progress Bars Don't Move Smoothly.

This video is interesting for anyone who wants to know in 5 minutes why this is.

Quoting rdodolak:

Quote:
The custom backup shows 9 main things to backup, one of which is for cover scans. 8/9 is 88.88% so it's possible it's based on that.

Ah, that makes sense. But it's still not very useful information.