[Suggestion] Show Remaining Download Time

[Ethaneus.8537]

This is a really simple request, just display the estimated time your download will be done in the client.

[Danikat.8537]

I agree that would be really helpful.

 

Even if it kept jumping around like other downloads do it would give us an idea of how long we need to wait.

[Steve The Cynic.3217]

> @"Danikat.8537" said:

> I agree that would be really helpful.

>

> Even if it kept jumping around like other downloads do it would give us an idea of how long we need to wait.

 

Given that my GW2 download rate ranges, on every single new download, from a few tens of KB per second all the way up to 25-30MB per second(1) during the same patch, that's one heck of a jump-around. And if you use the average rate so far, then it responds very slowly to sudden loss of rate at the end.

 

But yes, some indication (assuming that the total expected size in MB is actually known during the download) would be nice to at least give a hint, even if the hint turns out to be wildly inaccurate (which it will). The progress bar shows the fraction of files remaining, not the fraction of megabytes remaining, and some files are multi-megabyte while others are very small.

 

(1) I have fibre internet(2). A couple of months ago, I had some time off and downloaded WoW during the middle of a weekday so I could look at it (bleah). The download averaged around 80MB/sec with peaks beyond 110MB/sec. And yes, I know about the difference between MB and Mb.

 

(2) Real fibre, with the fibre coming all the way from the fibre equivalent of the local phone exchange (probably *in* the local phone exchange) to the back of my router.

[StinVec.3621]

The download progress used by GW2 is the only instance I've ever encountered since the dawn of the Internet where the download progress meter is based on the **number** of the files being downloaded instead of on the **total size** of all files being downloaded.

 

As the update progress is currently configured, you can have 100 files where 99 are mere kilobytes, but that 100th file is several hundred megabytes. As a result, you rocket to 99% and then you sit there at 99% for the entire time it takes to download that last file.

 

It has been requested for a very long time for the download percentage to reflect the progress of the entire download based on the total update size instead of being a reflection of the percentage of files remaining in the update to be downloaded (which is something that is of absolutely no use to the player sitting and waiting for the update to finish).

 

A file manifest of altered files included in the update already includes the size of the files being downloaded in addition to the number of files. As both the size and number of all files to be updated is already known, why the launcher download progress is based on the total number of files instead of the total size of the files baffles me.

 

(Additionally, as the game appears to download the entire altered version of the file to replace the existing one, to dramatically lessen the amount of data required to be downloaded by players, the update process could be changed to the more efficient and commonly used method of updating only specified lines of code in existing versions of files with the lines of code altered in the new build version of files in the update. Perhaps they would consider looking into switching over to this method - I'm sure many with slow Internet download speeds or data caps would greatly appreciate it.)

[Steve The Cynic.3217]

> @"StinVec.3621" said:

> (Additionally, as the game appears to download the entire altered version of the file to replace the existing one, to dramatically lessen the amount of data required to be downloaded by players, the update process could be changed to the more efficient and commonly used method of updating only specified lines of code in existing versions of files with the lines of code altered in the new build version of files in the update. Perhaps they would consider looking into switching over to this method - I'm sure many with slow Internet download speeds or data caps would greatly appreciate it.)

 

Except that diffable files are all text, and text-oriented files in MMORPGs are universally *much* smaller than binary (map data and images) files (which, in general, are not diffable), so it would increase the complexity of the download process without providing a big savings.

 

Add to that the fact that in the current schema, if I miss five or six patches, I download each updated file once and once only rather than having to apply multiple diffs or multiple copies of the same binary blob.(1)

 

(1) Probable redundancy. In database terminology, "blob" is a contraction of "Binary Large OBject", and therefore I said "binary binary large object"...

[Zaklex.6308]

ArenaNet can't tell you the remaining time because that isn't how their system works, this has been asked for before and the simple answer is they can't do it because downloads are not based on time, but files...which is why you see the total number of files being downloaded and how many are remaining. There is no possible way to determine how much time it will take to download those files because it will vary from person to person based on several factors involving the internet.

[Healix.5819]

GW2 supports patching from multiple versions, so they don't actually know the size of the files they're downloading until the file has begun to download. They could certainly find out if they wanted to however, which would require making a potentially huge and wasteful request (this can currently be done by requesting the headers of each file). What they currently do know prior to patching is the uncompressed size of each file, which can be used to estimate the total size. It can be somewhat accurate for a fresh install, but patching existing files can be wildly inaccurate, since partial patches can be anywhere between <1KB to the full file. Personally, I use this method to estimate the total size / download time in my app.

[Menadena.7482]

> @"Ethaneus.8537" said:

> This is a really simple request, just display the estimated time your download will be done in the client.

 

It may sound simple but it would be about as accurate as the estimate of remaining time when you copy a bunch of files in a WIMP operating system.

[StinVec.3621]

> @"Steve The Cynic.3217" said:

> > @"StinVec.3621" said:

> > (Additionally, as the game appears to download the entire altered version of the file to replace the existing one, to dramatically lessen the amount of data required to be downloaded by players, the update process could be changed to the more efficient and commonly used method of updating only specified lines of code in existing versions of files with the lines of code altered in the new build version of files in the update. Perhaps they would consider looking into switching over to this method - I'm sure many with slow Internet download speeds or data caps would greatly appreciate it.)

>

> Except that diffable files are all text, and text-oriented files in MMORPGs are universally *much* smaller than binary (map data and images) files (which, in general, are not diffable), so it would increase the complexity of the download process without providing a big savings.

>

> Add to that the fact that in the current schema, if I miss five or six patches, I download each updated file once and once only rather than having to apply multiple diffs or multiple copies of the same binary blob.(1)

>

> (1) Probable redundancy. In database terminology, "blob" is a contraction of "Binary Large OBject", and therefore I said "binary binary large object"...

 

That was extremely helpful information and I thank you for sharing your knowledge on the workings of it. It makes perfect sense to me and I can now see why it would not be a beneficial change to the update process. I also clearly failed to account for potentially 'missed' updates between the existing client version and the update to be downloaded in my thought process.

[Illconceived Was Na.9781]

Somewhat relevant [XKCD](https://xkcd.com/612/)