-
Notifications
You must be signed in to change notification settings - Fork 201
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mod installation progress tracking #1625
base: download-completed-callback-improvement
Are you sure you want to change the base?
Mod installation progress tracking #1625
Conversation
e433150
to
911baa4
Compare
4ef5cbc
to
f27752a
Compare
f27752a
to
0ca299f
Compare
5242ff6
to
9ca4173
Compare
…talling and display it on the UI
dfb6b56
to
03af2b9
Compare
9ca4173
to
db6a4f9
Compare
61bd4bb
to
17bfa4f
Compare
db6a4f9
to
7ea20ca
Compare
17bfa4f
to
0845cb9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition to these there was some buggy behaviour shared in voice chat.
7ea20ca
to
9ca4173
Compare
0845cb9
to
03af2b9
Compare
03af2b9
to
c359b28
Compare
Buggy behaviour should be at least better now, I'll have to test a bit more to see if it still fails in some conditions. |
https://github.com/ebkr/r2modmanPlus/pull/1617/files#r1939046141 "Any error from .getModList() is silently ignored" has been fixed |
https://github.com/ebkr/r2modmanPlus/pull/1617/files#r1939046141
These two seem a bit trickier, I think we shuld create a new ticket for these if it is something we want to do. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't consider any of the comments alone a blocker, but given there's a few of them, consider if some should be implemented now.
Ideas for future tasks:
- Prevent background mod list updates while there are active downloads
- Allow clearing one/all completed downloads via DownloadMonitor
- Allow retrying failed downloads via DownloadMonitor
- Use the actual file size information in ThunderstoreVersion to give different weights to different size mods when determining the progress
downloadCount += 1; | ||
} else { | ||
console.error(`Ignore unknown status code "${status}"`); | ||
return; | ||
} | ||
totalProgressCallback(totalProgress, combo.getMod().getName(), status, err); | ||
totalProgressCallback(Math.round(totalDownloadProgress), modInProgressName, status, err); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think other places use Math.floor, any reason to use .round instead here? (If changed, should be changed to TSMM sibling PR as well.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason was that the generateProgressPercentage()
sometimes returns like 99.9999999 instead of 100 (floating point number calculations are sometimes a tiny bit inaccurate) and therefore the download progress got stuck at 99%. Should the generateProgressPercentage
actually only return integers (round the number before returning)? (I implemented that as a part of the changes)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the change is OK, should/could the rounding of the progress percentage be removed from the UI components or is it a best practice to round just in case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In hindsight this whole thing should probably be designed so that it's the Vuex module that receives updates of each mods progress and internally keeps tracks how many mods is completed out of how many mods total, and what's the process of currently downloading mod. And it should then be the one that provides a getter or some other mechanic for providing the total progress to UI (rounded in one place and in one consistent way). That would also allow us to show it as percentage for progress bars, or as "Downloading mod 5 out of 6" for other status indicators.
Anyway, I'd be careful in changing generateProgressPercentage()
as it's called from elsewhere too. If you think this change improves the overall situation, feel free to go ahead with it, but do test it thoroughly (all functions that call generateProgressPercentage()
and related UI parts).
628656b
to
c868b98
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bonus: it seems at some point the order of downloads has changed. Develop downloads the target mod first and then the dependencies, while this branch downloads dependencies first. IDK if it matters at all, but inadvertently changing feels like begging for problems.
c868b98
to
82ad2c5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm now happy with these changes, with exception of this comment not being addressed:
Bonus: it seems at some point the order of downloads has changed. Develop downloads the target mod first and then the dependencies, while this branch downloads dependencies first. IDK if it matters at all, but inadvertently changing feels like begging for problems.
I think you should either change the order back; or get a confirmation from ebkr that changing the order doesn't matter.
It's probably easy to overlook the comments that are not assigned to any row, so I'll try to avoid them in future reviews even if the comment isn't really related to any specific row. That being said, read the non-line review comments anyway.
82ad2c5
to
a04686c
Compare
Fixed the main mod vs. dependencies ordering thing 👍 |
src/pages/DownloadMonitor.vue
Outdated
<Progress | ||
:max='100' | ||
:value='100' | ||
:className="['is-success']" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is the failed state using is-success
? Wasn't this fixed once already? Are there likely be other regressions with the latest changes? Why wasn't this detected when you tested the changes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤦♂️ Oops, my bad, should be all good now.
bda4456
to
b1395dd
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition my testing revealed some buggy behaviour that is hard to reproduce. We can discuss these in the daily. Until I understand what happened in those cases, I don't feel this is ready for release yet.
src/pages/DownloadMonitor.vue
Outdated
<Progress | ||
:max='100' | ||
:value='100' | ||
:className="['is-error']" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The diff says this used to be is-danger
. As far as I can tell, the component doesn't support is-error
class at all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could've sworn I copied it back from the diff, but I guess not. 💩💩💩
b1395dd
to
a362322
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, looks finally good to me. Couldn't reproduce the problems from yesterday anymore so lets hope they were once in a blue moon sort of thing.
No description provided.