Opened at 2011-08-29T14:47:44Z
Last modified at 2015-08-18T17:01:03Z
#1515 new enhancement
more precise progress indication for MDMF retrieve
| Reported by: | davidsarah | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | undecided |
| Component: | code-mutable | Version: | 1.9.0a1 |
| Keywords: | mdmf statistics | Cc: | |
| Launchpad Bug: |
Description (last modified by warner)
From the commit message for 9756146d61673552:
More improvements to consider:
- progress is currently 0% or 100%: should calculate how many segments are involved (remembering retrieve can be less than the whole file) and set it to a fraction
- "fetch" time is fuzzy: what we want is to know how much of the delay is not our own fault, but since we do decode/decrypt work while waiting for more shares, it's not straightforward
Change History (4)
comment:1 Changed at 2011-08-29T14:48:29Z by davidsarah
- Component changed from code-frontend-web to code-mutable
comment:2 Changed at 2012-04-01T04:42:01Z by davidsarah
- Priority changed from minor to normal
comment:3 Changed at 2012-04-01T04:42:20Z by davidsarah
- Type changed from defect to enhancement
comment:4 Changed at 2015-08-18T17:01:03Z by warner
- Description modified (diff)
Note: See
TracTickets for help on using
tickets.
Yeah, mutable/retrieve.py currently only calls set_progress() twice: once with 0.0 at the start, and once with 1.0 at the end. This was correct for SDMF, but with MDMF we can make an update after each segment is finished downloading. The place to do this will be inside _decode_blocks(), in the _process() function, where it logs "now decoding segment X of Y". Basically add a set_progress(X/Y) there.