After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 339062 - Progress bar goes backwards - % of tracks vs. % of time duration
Progress bar goes backwards - % of tracks vs. % of time duration
Status: RESOLVED FIXED
Product: sound-juicer
Classification: Applications
Component: interface
2.14.x
Other Linux
: Normal trivial
: ---
Assigned To: Sound Juicer Maintainers
Sound Juicer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-04-19 18:30 UTC by John Thacker
Modified: 2006-04-23 12:04 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
Patch which fixes the progress bar to always be percentage of duration (728 bytes, patch)
2006-04-19 18:44 UTC, John Thacker
none Details | Review

Description John Thacker 2006-04-19 18:30:19 UTC
In sj-extracting.c, on lines 308-309, before extracting each track the progress bar is updated thusly:

/* Update the progress bars */
gtk_progress_bar_set_fraction (GTK_PROGRESS_BAR (progress_bar), CLAMP (1.0 - ((g_list_length (pending) + 1) / (float)total_extracting), 0.0, 1.0));

This sets the progress bar to the percentage of tracks extracted.  However, while in the middle of extracting tracks, the progress bar is set to the percentage of TIME DURATION extracted.  See line 383-385:

float percent;
percent = CLAMP ((float)(current_duration + seconds) / (float)total_duration, 0, 1);
gtk_progress_bar_set_fraction (GTK_PROGRESS_BAR (progress_bar), percent);

These two percentages are clearly not the same, and differ more the greater variance in track lengths.  For example, ripping a very short song increases the % of tracks extracted much more than the % of time duration extracted.  So, depending on the CD, the progress bar can swing wildly back and forth as it completes each track.  Since current_duration and total_duration are already properly defined where the first progress bar is used, they should be used there as well.  Since intra-track progress can't be measured any other way-- unless you want something more complicated, like % of tracks done + (current track %)/(# of tracks).
Comment 1 John Thacker 2006-04-19 18:44:15 UTC
Created attachment 63892 [details] [review]
Patch which fixes the progress bar to always be percentage of duration
Comment 2 Ross Burton 2006-04-23 12:04:30 UTC
Fixed in HEAD and gnome-2-14, thanks!