Bug 436277 - Allow skip checking for updates when using metered network connection
Summary: Allow skip checking for updates when using metered network connection
Status: RESOLVED FIXED
Alias: None
Product: Discover
Classification: Applications
Component: discover (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Dan Leinir Turthra Jensen
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-04-27 18:45 UTC by martonmiklos
Modified: 2022-11-24 06:10 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 6.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description martonmiklos 2021-04-27 18:45:26 UTC
When using a tethered connection from a SIM card which has traffic limited data plan it would be useful to being able to disable the checking of the software updates. Networkmanager has a metered attribute for relatively long time which can be used to check whether the update check should be skipped or not. 

I am not familiar with the software layers used in periodic call of the discover for update checking but it is possible that the metered check could/should implemented in upper layers.
Comment 1 Nate Graham 2021-04-29 14:02:30 UTC
Yeah.
Comment 2 martonmiklos 2021-04-29 16:27:34 UTC
Hi Nate!

Are you aware of any other KDE application which handles the metered attribute?
I would be curious to see how it is implemented (via DBUS I guess).
Comment 3 Nate Graham 2021-04-29 16:39:46 UTC
I don't, sorry.
Comment 4 Aleix Pol 2021-05-05 13:10:27 UTC
Discover does to decide whether to issue an unattended update from the notifier. You can see the code in notifier/DiscoverNotifier.cpp:130.

For actual discover it's a bit more delicate, as we probably need to cover some other use-cases. I agree that we probably want to be more fine-grained there.

If what your bug report means that the notifier should never issue a refresh on metered connections that's easier to solve, we just need to make more use of that information.
Comment 5 martonmiklos 2021-05-05 16:59:51 UTC
(In reply to Aleix Pol from comment #4)
> 
> If what your bug report means that the notifier should never issue a refresh
> on metered connections that's easier to solve, we just need to make more use
> of that information.

Many thanks for sharing the details!

My report was written from end user perspective, but given the fact that the notifier already checking the network connection type before issuing  the unattended update that would be the best place to implement. I think the "only do unattended updates on Ethernet/Wifi" should be revised: one could tether a data limited SIM card to both Ethernet as well. 

I see that the QNetworkConfiguration is utilised here unfortunately I was not found any API for query the metered property. It might worth to open an idea in the Qt bug tracker about implementing such an API (Windows 10 also has metered property).
Comment 6 martonmiklos 2021-05-05 17:03:17 UTC
> I see that the QNetworkConfiguration is utilised here unfortunately I was
> not found any API for query the metered property. It might worth to open an
> idea in the Qt bug tracker about implementing such an API (Windows 10 also
> has metered property).

FYI it looks I am not the first who thinking about this see:
https://bugreports.qt.io/browse/QTBUG-91024
Comment 7 Kevin Kofler 2022-07-22 09:35:47 UTC
Why is this still open? This issue costs your users real money!

E.g., while I normally have mobile data disabled on my PinePhone, today, I had to enable it, and while my actual usage only cost me 2 or 3 eurocents, I had to reboot the PinePhone twice because of crashes, which each time triggered Discover, resulting in twice 18 eurocents (so a total of 0,36€) wasted by Discover for no reason in only a few minutes.

There is already the isConnectionAdequate() check in Discover for unattended updates. The same check should be used to decide whether to automatically check for updates. By default, since users can still check for updates manually if they need it. If you insist on making it an option, it should be opt-in.
Comment 8 Kevin Kofler 2022-07-22 09:41:16 UTC
The metadata that the check for updates downloads is already around 20 MB. This can be more than even the update itself. It is a very bad idea to download that at 0.009€/MB (20 MB * 0.009 €/MB = 0.18€. At every boot!).
Comment 9 Kevin Kofler 2022-07-22 10:19:29 UTC
If you wonder why I know this so precisely: I had mobile data enabled for less than an hour, with, as I already wrote, two reboots, and the call detail record has the data usage per connection:
* in the ~45 minutes before the reboot: 0.170 MB up, 2.368 MB down → 0.023€,
* in the 4 minutes between the two reboots: 0.329 MB up, 19.625 MB down → 0.180€,
* in the <10 minutes after the second reboot: 0.299 MB up, 19.579 MB down → 0.179€,
and I would not know what else downloads so much at startup time other than Discover.
Comment 10 Kevin Kofler 2022-07-22 10:33:57 UTC
If you can live without Discover checking for updates any time at all (even on WiFi or Ethernet), then:

systemctl --user disable --now app-org.kde.discover.notifier@autostart.service
systemctl --user mask app-org.kde.discover.notifier@autostart.service

should "fix" the issue through the sledgehammer method, and I have done that on my PinePhone, though I am not in a mood right now to try reenabling mobile data to confirm (and if not, wasting at least 0,18€ again). In any case, it definitely does stop the notifier from autostarting (but you need to actually mask it with the second command, just disabling it through the first command does not work).
Comment 11 Nate Graham 2022-11-24 06:10:00 UTC
Ooh, this was done recently for Plasma 6.