Fix legendary download progress bar percentage for updates

[RoguedBear]

closes #4190

Issue:

as discussed in #4190, the current method of calculating progress percentage for updates provides a misleading output.

This PR attempts to fix this by:

• preserving the existing functionality of using already downloaded files into progress bar calculation for installs
• and ignoring download cache for updates to better represent the game update progress.

For more context and clarity, a detailed discussion is present in the linked issue

Testing:

I am using Rocket League as an example here. I redownloaded the game from an old manifest that legendary had saved locally, then triggered an update from Heroic.

Before (Heroic 2.15.2)

• 

logs:

• 

After (my dev branch)

• 

logs:

• 

---

Use the following Checklist if you have changed something on the Backend or Frontend:

• Tested the feature and it's working on a current and clean install.
• Tested the main App features and they are still working on a current and clean install. (Login, Install, Play, Uninstall, Move games, etc.)
• Created / Updated Tests (If necessary)
• Created / Updated documentation (If necessary)

[flavioislima]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[RoguedBear]

I have read the CLA Document and I hereby sign the CLA

[arielj]

To be sure I understand, this will match the % displayed by legendary in its output in the different cases of downloading, updating, and pausing/resuming? or it's still there something different?

because if that's the case I guess we could just change this to read the % from the output

something like:

progress.percent = data.match(/Progress: (\d+\.\d\d)%/m)

and replace all the calculation?

[RoguedBear]

To be sure I understand, this will match the % displayed by legendary in its output in the different cases of downloading, updating, and pausing/resuming? or it's still there something different?

From what ive seen experimenting with legendary by default all downloads are resumable regardless of it being installation or update. However for updates i noticed with each download session the "GBs to download" decreases as it takes into account what is already downloaded, and the progress starts from 0%.

In the beginning I was thinking of adding progress.percent = data.match(/Progress: (\d+\.\d\d)%/m) too but I found that the reason this calculation was introduced (in this commit 223b915 ) was as a way to include already downloaded files as part of the progress percentage.

This approach works really well for new installs as the progress bar correctly reflects how much is downloaded in each pause/resume session.
But when updating a game you can see from the screenshots i posted here and in the linked issue that we get a very misleading percentage bar (as the calculation is including the already downloaded game size as part of the update the moment actual update beings to download)

I figured a middle ground approach could work fine here where the existing behavior is preserved for new installs, but for updates do what legendary does -> current downloaded in this session / total to download in this session %

---

I still think that for users not familiar with legendary it could cause confusion even after this PR is merged as for updates the progress starts from 0% each session, but I think that can be resolved if we display total size to download on the client side.
Then the users would notice that the remaining download size decreases each time they pause/resume, and get reassurance it is actually resuming.

Also this doesn't "exactly" match legendary's percentage, but is very close to it. I am doing size downloaded / total size to download, whereas legendary does number of files downloaded / number of files to download.
You can verify this from the legendary logs screenshot in PR description

[RoguedBear]

looking at #2239, Although pause/resume has worked well in all the time ive used heroic & legendary, If there is more experimentation we can do regarding new installs, updates and pause/resuming, I would be open to help with that.

[arielj]

Also this doesn't "exactly" match legendary's percentage, but is very close to it. I am doing size downloaded / total size to download, whereas legendary does number of files downloaded / number of files to download. You can verify this from the legendary logs screenshot in PR description

Yeah, I didn't mean exactly, but wanted to understand is: if we are showing a similar % than legendary in the 3 different scenarios (start from beginning, resume paused/canceled, update), then we don't need the calculation, if we have some consideration to do something different I guess it's fine to keep the calculation.

One thing that I know is a problem with the calculation from Heroic's side is that since it's based on size downloaded and not in files downloaded, stopping/cancelling a download will actually discard the current files that didn't finish downloading (at least for epic games), which can be a problem with games that come with big files (I understand that's the main issue in #2239), so a user will see a % (based on size) when they want to pause, legendary will discard whatever it is downloading at this point, and when resumed the % will be different. With small files downloads it's not that much of a difference, but it's a problem in many cases with big files. So size % is what most people want to know in general, but file % is what people should care when pause/resume/crash. Showing just one is a bit misleading to the user (as reported in that other ticket).

I really don't know what's the best solution, but I do think that screen is missing some information in general:

• progress based on files downloaded (and making it clear that this is the % to reference for pause/resume)
• total to be downloaded (now we have a % and amount downloaded, but it's not great UX)
• disk split into write/read

I honestly don't know what's the right answer, personally I would err on the side of showing as much information as possible (the things I listed + the things we already show), and maybe improve the pause message to say "THIS is the % where we will restart the download, are you sure?????" with a (?) to explain why it's that % (based on files) and not the other % (based on size).