FS#21853 - cb_dl_progress cannot be initialized properly when resuming a file

Attached to Project: Pacman
Opened by Xavier (shining) - Saturday, 27 November 2010, 15:04 GMT
Last edited by Anatol Pomozov (anatolik) - Monday, 10 August 2020, 19:34 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To Anatol Pomozov (anatolik)
Architecture All
Severity Low
Priority Normal
Reported Version 3.4.1
Due in Version 6.0.0
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

dload.c does
handle->dlcb(filename, 0, ust.size);
even when we are resuming a file at a given offset, because that's the only way to tell cb_dl_progress to re-initialize its counters when we are starting a file download.

There are probably many ways to fix this, just unsure which one to choose :
1) track last filename in cb_dl_progress to detect new files and reset counters
2) add a parameter or abuse existing parameters (e.g. filename == NULL) to tell cb_dl_progress to reset
3) add a new callback function to reset or init a new file download at a given offset
This task depends upon

Closed by  Anatol Pomozov (anatolik)
Monday, 10 August 2020, 19:34 GMT
Reason for closing:  Implemented
Additional comments about closing:  git commit c78eb48d915dc22146073162dda08ddf73c4a508
Comment by Dan McGee (toofishes) - Saturday, 27 November 2010, 18:01 GMT
I've noticed this before as well, but never felt motivated to look into it. It messes up the averages we calculate at the end as well.
Comment by Xavier (shining) - Saturday, 27 November 2010, 18:28 GMT
Yeah I know, I just spotted it again today and it pissed me off.
I wanted to go ahead and fix it but I hesitated a bit on which way to go. So instead I put it there to record it.
So feedback welcome :) (1, 2 or 3)
Comment by Xavier (shining) - Tuesday, 01 February 2011, 09:36 GMT
toofishes >> shining^: part of me says the callback itself shouldn't have to track/figure out so much
toofishes >> just have it get passed a shitload of info
toofishes >> the rates and all would get calced in the backend
Comment by Allan McRae (Allan) - Sunday, 22 April 2012, 11:21 GMT
@Dave: I seem to remember this being fixed in all your downloader work. Confirm/deny?
Comment by Dave Reisner (falconindy) - Sunday, 22 April 2012, 13:17 GMT
Nope, not yet.
Comment by Anatol Pomozov (anatolik) - Monday, 10 August 2020, 19:32 GMT
Download codepath in master branch has been massively reworked. Now we have separate init/progress/done events that help to detect when a resuming file starts downloading. See commit c78eb48d915dc22146073162dda08ddf73c4a508

I believe your issue is resolved now. PTAL.

Loading...