Show Update Size and allow Pause (not Stop) on active updates

That is correct, which is why I mentioned inactive hours would likely be a non-solution in this case as an individual user, thus I would definitely prefer a bandwidth cap option at my disposal. As I previously mentioned, the irritation is often caused by 2 separate problems, mixing into one.

- Lack of an update size causes an update decision to be a gamble, as I cannot make an educated guess on how long I'll be updating

- Lack of a bandwidth cap causes the gamble to often result in an undesirable outcome, clogging my bandwidth for a long period of time that I was not prepared for or causing me to just abandon the update midway due to taking too long.

So in my opinion, one or the other problem being alleviated would go a long way and minimize the urgency of the other solution, as in:

- If I know the download size, I can reasonably guess whether I can take that 5 minute update now, or if I am better off leaving that hour long update for a more reasonable time

- If I can (manually) set a bandwidth cap, I don't care about the size. I'll download the update at a reasonable cap that allows me to do other stuff on my device, and remove the cap when stepping off. The size of the update and thus the length of the update is no longer a concern (unless I need urgent access to the app I'm updating, but that's an edge case as I likely won't initiate an update in that case anyways)

All fair points - I'll pass these along to the team as they devise a solution.

One clarification on the inactive hours preference - I'm guessing you'd set inactive hours for non-business hours or when you're sleeping. As you've pointed out, the app won't be able to wake up your machine. Is this preference still valuable then? Or does the bandwidth preference accomplish what you're looking for?

Ah I see. I mean, that's a default "Yes please" on the auto-update decision, though I'd prefer an "inactive hours" over the app seeing low usage for 10 minutes and deciding to launch an update with full speed at a bad time. One of the most aggravating things is to randomly lose my internet and then realize it's because CC decided to launch an update in the middle of the day. Windows Update used to be like that.

Though Auto Capping on a manual update, I can honestly see a lot of issues with that. CC doesn't know whether I am going out to do groceries and thus still want the full speed so it can be done before I return, or if I want to be doing other stuff on my PC/Network while updating.

Personally, I am not a fan of "smartification" over just prioritizing surefire caveman tier methods. Not only is it easier (in my mind at least) to develop and implement manual, user choice solutions since you do not need to bother with extensive algorithms to assume stuff about my usage, but also more importantly, it also means an app does not need to "assume" stuff about what I may be doing, which it often cannot guess and makes bad choices in the end. 

Going back to my Windows Update reference earlier, that is the one smart application I have enjoyed in my life. Windows just knows that 99% of the time, I am definitely, certainly, without a doubt sleeping between 5am-8am range and schedules updates then. Which only works for Windows Update, because that's the only thing on the device that has the authority to wake up my PC from sleep. Steam has it, but it doesn't work because it cannot wake up the PC and neither can CC if it were to implement a similar system.

So I really do not see the "smart solution" being "the solution" for CC, at least based on my anecdotal, personal experience.

I'm sorry it's taking so long to add this capability.

Good clarification - when I said "smart", I mean for "auto-update" scenarios, the update would only happen when we detect that system resource usage is low. For manually triggered updates, we would cap the network bandwidth usage (I'll need to check with the architects about what percent level makes sense).

I'll have the team check to see if the update size is available from the services we call. If it is, we should be able to display it with the strings highlighting the update.

> if the app is smart about how it uses network bandwidth

Defining "smart" would be useful. It's been years since CC has been acting this way that I am at the frustration level of "I'll settle at 'not hogging my entire bandwidth' for an update I don't know how long it'll take". Though with that said, I do not actually trust the smartness of an app. It's simple really. There are cases where I am fine with the app to use full bandwidth available, there are cases I want it to leave at least some room that it does not take a minute to refresh my Gmail, there are cases where I want to be able to watch 1080p Netflix or Youtube while the update is running and on and on. 

I know my average top speeds, I simply want to be able to tell CC that it is not allowed to use more than 10Mbps or 20Mbps or whatever.

And as mentioned, it's very much a collection of issues that make this such a big issue. Not knowing the size leads into the uncertainty of how long an update may take, so when I end up updating, there's a huge chance that I will regret starting the update, and at some point, bite the bullet and cancel it.

Thanks for having the update size on the roadmap as well. And while I know not much reasonable comes after an "I'm not a developer but...", CC already shows patch notes on the side of the updates. These patch notes are manually entered there, or somewhere else that the app pulls from. Like... Simple solution, why can't you simply mention the download size on top of the patch notes? No need to work on the app itself if priorities are so hogged away from what should have been simple industry standard features, just mention the update size compared to the previous version in the top line. It should at least give a rough idea, even though some people may not be on the most recent version.

I also realize I didn't mention showing the update/download size and the ability to pause/resume downloads. Those are also on the roadmap.

Sorry, I don't have a good update unfortunately, @boris_8741 , @timpani 26 , @Stuart Gill - UWTSD . The team has investigated some solutions this year but the fix couldn't get prioritized above other features the team was asked to do. I'm asking the team in Q1 to start with automatically limiting how much bandwidth is being used. We're looking into providing a user preference for bandwidth usage (low, med, high) as a subsequent step.

I'm curious to understand - if the app is smart about how it uses network bandwidth, would you still want a preference to override what the app is doing?

@Kalvyn Rasquinha Please can you provide an update on this issue as it's nearing the end of the year.

@Kalvyn Rasquinha

Any progress on this topic?

I fully agree with KaanGT on all points and would a appreciate improvements.

Hi Kalvyn, it's been 7 months, do you have an update on this?

We should be able to see the size of updates, pause updates, allocate bandwidth to updating so it can run in background.

Regards