Bug 448690

Summary:	Discover's search is slow if you use it immediately after launching the app
Product:	[Applications] Discover	Reporter:	Martin Tlustos <martin.tlustos>
Component:	discover	Assignee:	Dan Leinir Turthra Jensen <leinir>
Status:	RESOLVED FIXED
Severity:	normal	CC:	aleixpol, nate, postix, s.suther, yvan
Priority:	NOR	Keywords:	usability
Version First Reported In:	5.23.90
Target Milestone:	---
Platform:	Neon
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:	6.0
Sentry Crash Report:

Description Martin Tlustos 2022-01-18 05:03:53 UTC

SUMMARY
When searching for programs, discover takes a lot of time to find anything, but sometimes doesnt't find it anyway (e.g. search for fdupes in discover - takes ~20s, returns empty. Search for it in muon - immediately there). The problem probably comes from searching in knewstuff, but it's making using discover bothersome.


STEPS TO REPRODUCE
1. 
2. 
3. 

OBSERVED RESULT


EXPECTED RESULT


SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION

Comment 1 Nate Graham 2022-01-20 21:34:04 UTC

Note that discover will never find fdupes, because it is a command like program with no AppStream metadata, and Discover only shows search results for user-facing software (typically GUI apps)  with AppStream metadata.

Does the issue reproduce when you search for user-facing GUI apps that certainly *do* have AppStream Metadata, such as Blender or VLC or Dolphin?

If so, does this happen only when you search immediately after launching Discover? Is it better if you launch Discover, wait 10 seconds, and then search?

Comment 2 Martin Tlustos 2022-01-23 13:20:19 UTC

Ok, so i tried blender vlc and dolphin. Right after the start it takes some time (it actually finds background images and knewstuff first), but it finds all of them. After a while (I guess after looking for updates), search results are quick.
It still doesn't find a lot of programs that muon lists (like vlc - discover only finds the flathub version, but not the one in the normal repository, it also only finds the flathub version of handbrake, not the normal one etc.), but that's a different bug... (although it could be that those packages don't have appstream metadata, which would explain this behaviour...)

I'm leaving closing the bug for you as I don't really know what kind of solution I should choose from the list... ;-)

Comment 3 Nate Graham 2022-01-23 18:44:15 UTC

> discover only finds the flathub version, but not the one in the normal repository
That's because Neon deliberately strips out AppStream Metadata for 3rd-party apps to encourage people *not* to use the versions in the repo. They want you to get your 3rd-party apps from Snap or FlatHub.

Let's use this bug report to track the issue of the search being slow if you use it immediately after launching the app, which I can reproduce and is a valid issue in Discover itself.

Comment 4 Samuel Suther 2022-02-11 10:26:37 UTC

huge downside of this application. Therefore I do use pamac.manager where ever I can.
Should be fixed, because generally discover is the better one of both, but seach-functionality feelts like 1998.

Comment 5 Nate Graham 2023-10-19 21:05:11 UTC

This is fixed for me with Plasma 6.0. Maybe the newer 1.0 version of AppStream has helped too.