Red Hat Bugzilla – Bug 134565
progress bar goes backwards!
Last modified: 2014-03-16 22:49:04 EDT
Description of problem:
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Wait for it to finish a track
2. Bottom progress bar jumps forward a little...
3. ... then jumps backwards
The time estimation code seems to be based on the speed it's running
at at that instant, not the speed over the entire operation. Which
means it jumps around a *lot*.
Yeah, that's how it works, and it still does this. Sounds to me like this is a
category for an UPSTREAM bug instead, though. I really don't think it's worth
the effort to patch it to change this.
No, wait, I looked at the code and that's not it. It actually does do the time
estimate based on the speed over the entire operation.
What's happening is that it sets the progress bar at two different times:
right as it starts a new track, it sets the progress bar to the percentage of
tracks extracted. But inside, while ripping the tracks, it sets the progress
bar to the percentag of TIME DURATION extracted.
Thus, the greater the variance in song lengths, the more that will jump around.
Ripping a very short file increase the percentage of tracks extracted by much
greater than the percentage of total time duration extracted.
Filed as upstream GNOME bug 339062
Created attachment 128000 [details]
Patch which fixes the progress bar to always be percentage of duration
Fixed upstream now, in HEAD and 2.14.x branch.