Bug 134565 - progress bar goes backwards!
progress bar goes backwards!
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: sound-juicer (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Monty
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-04 13:43 EDT by Bill Nottingham
Modified: 2014-03-16 22:49 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-23 10:20:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch which fixes the progress bar to always be percentage of duration (728 bytes, patch)
2006-04-19 14:37 EDT, John Thacker
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 339062 None None None Never

  None (edit)
Description Bill Nottingham 2004-10-04 13:43:11 EDT
Description of problem:

SSIA.

Version-Release number of selected component (if applicable):

sound-juicer-0.5.13-1

How reproducible:

Every time

Steps to Reproduce:
1. Wait for it to finish a track
2. Bottom progress bar jumps forward a little...
3. ... then jumps backwards
  
Additional info:

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*.
Comment 1 John Thacker 2006-04-14 15:29:34 EDT
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.
Comment 2 John Thacker 2006-04-19 14:13:31 EDT
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.
Comment 3 John Thacker 2006-04-19 14:24:37 EDT
Filed as upstream GNOME bug 339062
Comment 4 John Thacker 2006-04-19 14:37:21 EDT
Created attachment 128000 [details]
Patch which fixes the progress bar to always be percentage of duration
Comment 5 John Thacker 2006-04-23 10:20:27 EDT
Fixed upstream now, in HEAD and 2.14.x branch.

Note You need to log in before you can comment on or make changes to this bug.