Yeah, this has been a complaint since forever, but it's very noticeable on openSUSE distros because of hong a refresh takes. On Arch or deb-based distros, it's very fast, so people don't really complain about it anymore. Dunno about Fedora.

(In reply to Nate Graham from comment #1)
> Yeah, this has been a complaint since forever, but it's very noticeable on
> openSUSE distros because of hong a refresh takes. On Arch or deb-based
> distros, it's very fast, so people don't really complain about it anymore.
> Dunno about Fedora.

Yeah OK, it might be faster on other distros, but it still costs time on every system and I don't really see why it's behaving that way at all.
But you said that it's a complain since forever, is there a reason why it hasn't been changed? Just because it's not that time consuming and annoying on some distributions anymore? :D

Because it's hard to fix. :)

(In reply to Nate Graham from comment #3)
> Because it's hard to fix. :)

Oh okay, that explains it. :P

It's not only that it's hard to fix. We used to refresh less often but then sometimes people would get errors that their update wasn't fresh and we'd have to tell them to F5 and try again, which is very confusing.

In the end, even if we know that 1h ago the cache was refreshed, we can't tell for sure that all the packages are still current.

(In reply to Aleix Pol from comment #5)
> It's not only that it's hard to fix. We used to refresh less often but then
> sometimes people would get errors that their update wasn't fresh and we'd
> have to tell them to F5 and try again, which is very confusing.
> 
> In the end, even if we know that 1h ago the cache was refreshed, we can't
> tell for sure that all the packages are still current.

Yeah OK, but wouldn't it be possible to refresh when the user actually tries to install updates then? 
The same problem occurs at the moment, when you have discover open for a few hours and press "install updates" then. I know, not very probable, but also not completely unthinkable. 
So, instead of checking for updates when the user opens discover because he may update his system, wouldn't it be more useful to check when the user actually tries to update?
And to know that updates are available, it should be checked at system boot and after a given time. 
And to make it less confusing for the user that when he hits "install updates" but it's checked for updates first, the text of the button could be changed to "search for updates & install", which would be better than the second solution I describe below I think. 
This solution here would also have nearly the same behavior as it has now, but just checks for updates when it's *really* necessary. 

A second usable solution would also be to check how old the cache is (like when it's 10 seconds old, it's not very probable that there're new updates), but when it's 5 or 10 minutes old, it might be necessary, so discover shows a dialog, saying that the last check for updates is XX minutes ago and new updates might be available and whether it should check for updates again or not. But that might also be confusing and just unsettle the user (and users who understand the message would probably just hit "yes" anyway all the time and then we have the same behavior as described above, just with extra steps, users who don't understand it would probably hit "no" all the time and then there might be errors with invalid updates, which confuses the user even more, so the solution described above is really better).

Git commit d38e7ad9f2aeb69127b6e62ac50f655077d26e1c by Aleix Pol.
Committed on 28/11/2022 at 20:48.
Pushed by apol into branch 'master'.

flatpak: Do not check for updates immediately

Wait for a bit to check for updates, instead just show the locally
available data ASAP.
Related: bug 439050

M  +14   -5    libdiscover/backends/FlatpakBackend/FlatpakBackend.cpp
M  +2    -1    libdiscover/backends/FlatpakBackend/FlatpakBackend.h

https://invent.kde.org/plasma/discover/commit/d38e7ad9f2aeb69127b6e62ac50f655077d26e1c

(In reply to Nate Graham from comment #1)
> Dunno about Fedora.

It's a problem on Fedora (yum repos have a ton of metadata which gets fetched when checking for updates). The time it takes to fetch that metadata seems to be exacerbated by things like Bug 457408 and Bug 466671, so that refreshing the updates is even slower in Discover than for pkcon or dnf.

> Yeah OK, but wouldn't it be possible to refresh when the user actually tries
> to install updates then?

Hi Tobias, this describes the current behaviour, no?

If the user wants to install updates and/or new software, they will open Discover (which refreshes the cache) and then browse the up-to-date list of applications to install and/or click 'update all'.

If they don't want to install updates and/or new software, then they won't open Discover in the first place and won't encounter this issue?

I understand your frustration, but the 'forced-refresh' of the cache upon opening Discover seems intentional to me and serves a valid purpose.

> The same problem occurs at the moment, when you have discover open for a few
> hours and press "install updates" then. I know, not very probable, but also
> not completely unthinkable.

There is a 'refresh' button on the 'updates' page of Discover. I'm unaware if this was present when you first reported this ticket (version 5.21.0), but it exists now. If you are opening Discover and keeping it open, you can use it to manually refresh the cache.

There are basically two options:
1. Refresh when launching the app
2. Refresh when installing an app, uninstalling an app, or starting an update.

Each has a problem associated with it:
#1 makes the app take a longer to launch or present a useful UI.
#2 makes the app take longer to respond when you install or uninstall an app, or install updates.

There's no free lunch here; the time to refresh has to be spent eventually. If that time is really long, it's moving it around doesn't solve much. Would it really be less annoying if Discover launched immediately, but then when you install an app, it wait 20 seconds before doing anything? I don't think that would be a better UX; we'd simply get complaints about that instead.

A better approach here would be to figure out why refreshing the sources takes 20 seconds. That's a really really long time! Some work has been done already for Plasma 6.5 to speed things up here, and more will probably be done in the future. If you still experience such a long time in Plasma 6.5, I'd request a new bug report, and in there we can investigate why it's taking so long.

(In reply to Nate Graham from comment #10)
> There are basically two options:
> 1. Refresh when launching the app
> 2. Refresh when installing an app, uninstalling an app, or starting an
> update.


But there's another option:

Don't refresh if the cache was already refreshed in the background "recently" (for some value of recent).

We know if refreshes in the background, because the systray widget appears when it refreshes and new updates have been detected. So the system refreshes the cache in the background, makes the "Updates available" widget appear in the systray, I click on it immediately ... and then have to wait while it re-refreshes the cache which is only a few seconds old.

Why is it necessary to refresh again when you open Discover, or start the updates?

DNF doesn't do that. If I run it twice, the second time won't refresh the cache:

~$ sudo dnf check-update
Updating and loading repositories:
 RPM Fusion for Fedora 42 - Nonfree - Updates                                                                       100% |   5.2 KiB/s |   7.9 KiB |  00m02s
 RPM Fusion for Fedora 42 - Free - Updates                                                                          100% |   6.5 KiB/s |   7.7 KiB |  00m01s
 Fedora 42 - x86_64 - Updates                                                                                       100% |  16.8 KiB/s |  18.7 KiB |  00m01s
Repositories loaded.
~$ 
~$ 
~$ sudo dnf check-update
Updating and loading repositories:
Repositories loaded.
~$

If new packages appeared in the repos between the first and second `check-update` command, I wouldn't know about them. I would have to add the `--refresh` option to force DNF to re-fetch.

If Discover did the same thing (only refreshing when the cache is stale, or the user clicks Refresh) it would mean that some updates are potentially "missed" if they were published after the last refresh. The user wouldn't get those updates until the next time the cache is refreshed (automatically in the background, or by pressing the Refresh button). But that is apparently acceptable for DNF. Surely that's a possibility for Discover too?

"We don't want to do that" is a valid response, but "there are only two options and this isn't one of them" just seems untrue.

Hmm, that would work, but then the time Discover takes to refresh would be variable: some of the time you launch Discover, there's been a background update check and the app would be snappy, and at other times the background update check was too far in the past, so DIscover would refresh things, and it would be slower. This also wouldn't be easily predictable by a user.

Would this really be better?

*** Bug 439050 has been marked as a duplicate of this bug. ***

> This also wouldn't be easily predictable by a user.

You are right, this introduce another usability issue, it is a tradeoff issue.

Personally, if sometimes Discover is long to start, I am a bit annoyed. But, when I see a notification telling me to update and I click on it, I am really frustrated to see that updates availability needs to be checked again: the "update mechanism" interrupts my task and then "tells" me to wait before I can validate the update.

Moreover, update happens almost every day, while browsing software or installing a new one happens much less frequently.

Regards

Let's track that with Bug 510395, which is more narrowly-scoped.