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.
Yeah.
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).
I don't, sorry.
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.
(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).
> 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
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.
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!).
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.
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).
Ooh, this was done recently for Plasma 6.