Downloading soundpacks sometimes doesn't show known total file size #81
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes remyroy#660
The current downloading progress reporting relies on Qt's downloadProgress signal https://doc.qt.io/qt-5/qnetworkreply.html#downloadProgress which includes a bytesTotal value that is assumed to be the total number of bytes expected. Kind of what you would expect.
Except or the bit that says 'If the number of bytes to be downloaded is not known, bytesTotal will be -1', which is happening in some cases, overriding the known size from soundpacks.json.
This fix remembers any defined size for the selected soundpack and uses that in the statusbar if we get a bytesTotal == -1.
Testing: Download soundpacks where
(a) there was a defined size:
(b) there was no defined size:
In this case the downloadProgress signal did know what size to expect.
Note:
This is a largely cosmetic issue, so no hurry to release.