Make it possible to define a bandwidth limit for automated updates

[wonderbeel]

Currenty this updater runs without any form of bandwidth limitation: while this is good and what I would expect if I am to invoke it manually it is less than ideal for an automated background service, personally I had a couple of annoyances caused by this (eg, updater started while I was in a video call severely degrading the video quality).
Looking around for possible solutions I found trickle, would it be possible to add it (or something similar) with an option in the .toml file to allow users to set a limit for the daemon?

EDIT: Looking at other options, good old rsync has bandwidth limit incorporated already (and it is really battle tested) but I guess that we can't really use it to run the updater right?

[gerblesh]

good idea, I think we should add some form of internet bandwidth check or something to prevent this from happening in the future, I got some ideas and had a message a while back on how to do this, i'm currently pretty busy but I'll accept PRs/proposals for it

[castrojo]

Also even if there's a throttle if someone is on a video call that should be the priority. Can we do something like "if the gpu is over X% load or actively doing video then don't update"?

[wonderbeel]

Also even if there's a throttle if someone is on a video call that should be the priority. Can we do something like "if the gpu is over X% load or actively doing video then don't update"?

Not sure if GPU load is a good metric in this case because you will have wildly different percentages of usage between a dedicated and integrated GPU (also because there could be some cases were the GPU is under load but we actually want to run the background updates, eg if I am playing a single player GPU intensive game it is fine to run background updates); I was thinking of a bandwidth limit because it seemed the most reliable one, my reasoning is that as an user I can fine tune the limit and it will not bother me if I have backgrounds updates running really slowly.

[bobslept]

Just a thought while reading this issue. A fairly easy to implement "solution" would be a check if Do not Disturb is toggled.

❯ gsettings get org.gnome.desktop.notifications show-banners
true

~ 
❯ gsettings get org.gnome.desktop.notifications show-banners
false

So if toggled don't update, when you are in a video call or something important, you hit the do not disturb toggle and don't get bothered with an update.

Ofcourse a long term solution would be nice to have a real limit on there, but in the mean time this could be a welcome addition to work around the problem?

[gerblesh]

Just a thought while reading this issue. A fairly easy to implement "solution" would be a check if Do not Disturb is toggled.

❯ gsettings get org.gnome.desktop.notifications show-banners
true

~ 
❯ gsettings get org.gnome.desktop.notifications show-banners
false

So if toggled don't update, when you are in a video call or something important, you hit the do not disturb toggle and don't get bothered with an update.

Ofcourse a long term solution would be nice to have a real limit on there, but in the mean time this could be a welcome addition to work around the problem?

I think that psutil has a way of checking network speeds/throughput iirc. Adding this means that it would be desktop-specific, and ublue-update aims to work accross, KDE, GNOME, and official fedora spins. I certainly like the idea though, maybe a dbus property of some sort?