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 565089 - in downloading x of y text, y never decrements
in downloading x of y text, y never decrements
Status: RESOLVED WONTFIX
Product: banshee
Classification: Other
Component: Podcasting
1.4.1
Other All
: Normal enhancement
: 1.x
Assigned To: Banshee Maintainers
Mike Urbanski
gnome[unmaintained]
Depends on:
Blocks:
 
 
Reported: 2008-12-19 12:39 UTC by David Nielsen
Modified: 2020-03-17 08:25 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description David Nielsen 2008-12-19 12:39:52 UTC
When downloading podcasts the total list might say 2 of 19, however as 2 downloads finish this does not become 2 of 17, it stays at 19.

Other information:
x86_64, Fedora 11 (Rawhide), da_DK.UTF-8
Comment 1 Bertrand Lorentz 2008-12-19 16:25:15 UTC
I think that in "2 of 19", 19 is supposed to be the total number of items to download (remaining items and completed items). It's a bit like a percentage.

So I'd say the behavior is "by design".
Comment 2 David Nielsen 2008-12-19 16:36:47 UTC
you have the progress bar with the procentage already, if this is the design it seems awfully redundant not to mention confusing.
Comment 3 David Nielsen 2008-12-20 12:57:46 UTC
Upon further reflection I noticed that for every other task we increment x to indicate progress, however we do not do this for downloading. Which might be why it looked strange to me in the first place.

Adding tracks, converting tracks and so on all indicate progress by doing 10 of 12, 11 of 12, etc. However for downloading x is static, it's always 2. For consistency we should probably increment it.
Comment 4 Mike Urbanski 2008-12-24 16:58:44 UTC
By design?  Yes.  Sucks big toes?  Oh you better believe it.

The old download AUE was cluttered, but, all things considered, it was probably clearer:  http://michaelcurbanski.com/gallery/main.php?g2_itemId=775

As download tasks execute concurrently x represents the total number of active downloads.  X seems to be pegged at two as the HTTP v1.1 spec recommends keeping at most two connections to any given server open at any given time.  If you have more than two downloads queued, x will spend a good chunk of its time with a value of 2.

As downloads are paused, canceled, or completed x is decreased accordingly.  As seen here:  http://vimeo.com/1619239?pg=embed&sec=1619239&hd=1

The data needed to resurrect the old AUE is available in the GroupStatusChangedEventArgs class if anyone is interested...    

(http://svn.gnome.org/viewvc/banshee/trunk/banshee/src/Libraries/Migo/Migo.TaskCore/EventArgs/GroupStatusChangedEventArgs.cs?view=markup)

Comment 5 Gabriel Burt 2009-10-27 20:18:43 UTC
Bulk changing the assignee to banshee-maint@gnome.bugs to make it easier for people to get updated on all banshee bugs by following that address.  It's usually quite apparent who is working on a given bug by the comments and/or patches attached.
Comment 6 André Klapper 2020-03-17 08:25:09 UTC
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived.

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect
reality. Please feel free to reopen this ticket (or rather transfer the project
to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the
responsibility for active development again.
See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.