Discover's update section is randomly restarting the search for updates after displaying/flashing the results for few seconds. I don't have the technical knowledge to replicate this issue. I just noticed that it has a higher chance of happening when it displays many items to update. There must be something that doesn't prevent the section from automatically searching for updates after displaying the results. If this issue is found, please check if the same issue happens when searching for apps.
Can you attach a screen recording that shows the issue happening? Thanks a lot!
Created attachment 165628 [details] An smaller scale of the issue. Managed to record this issue on a very smaller scale. Normally the waiting time to display the updates again is much longer.
Created attachment 165629 [details] Notice the extra search flashing for few frames. You can notice that after the updates being displayed, it does a second search for them. This is the issue. One that can take a very long time depending on the number of items.
There's also another issue in which instead of searching one more time after displaying the results, it keeps searching multiple times (very likely forever). But I won't be able to record that specific glitch anytime soon, and in any case the video would be too big to be here. And fixing the issue I've recorded would likely fix the looped version anyway.
Thanks, that's helpful. The fact that you are using Kinoite is very relevant as it has a whole special backend for it.
I don't know if this is the right place to ask this, but is there a reason to why searching for updates hides the lastest results? Why can't it show the latest results while searching for updates at the same time?
Managed to record the long loop issue. The results are flashed at: 1:23, 2:32, 3:42, 4:52, 6:02, 7:12, and 8:21. https://www.youtube.com/watch?v=yi5UFATsGnE
A possibly relevant merge request was started @ https://invent.kde.org/plasma/discover/-/merge_requests/818
Created attachment 175311 [details] The results are flashed at: 1:23, 2:32, 3:42, 4:52, 6:02, 7:12, and 8:21. I'm not currently using Fedora, so I don't know if this got fixed since it became "ASSIGNED".
A possibly relevant merge request was started @ https://invent.kde.org/plasma/discover/-/merge_requests/1096
Git commit e0907397d9b8f0cc4223c358d654a094eff5163e by Timothée Ravier. Committed on 28/05/2025 at 09:19. Pushed by ravier into branch 'master'. rpm-ostree: Fix rpm-ostree driver registration Properly initilize the boolean responsible for trigerring the logic to register Discover as an update driver to the rpm-ostree daemon. This will keep the rpm-ostree daemon running (but mostly idle) as long as the Discover main window is open, and will avoid re-loading the list of deployments and update every ~60 seconds, when rpm-ostree would have exited due to being idle, releasing the name on the bus. Fixes: https://bugs.kde.org/show_bug.cgi?id=480947 M +7 -1 libdiscover/backends/RpmOstreeBackend/RpmOstreeBackend.cpp M +3 -0 libdiscover/backends/RpmOstreeBackend/RpmOstreeBackend.h https://invent.kde.org/plasma/discover/-/commit/e0907397d9b8f0cc4223c358d654a094eff5163e
Git commit 8b8f9fd32cf8bb40bd800b8e6777476277295a5b by Timothée Ravier. Committed on 28/05/2025 at 09:24. Pushed by ravier into branch 'Plasma/6.4'. rpm-ostree: Fix rpm-ostree driver registration Properly initilize the boolean responsible for trigerring the logic to register Discover as an update driver to the rpm-ostree daemon. This will keep the rpm-ostree daemon running (but mostly idle) as long as the Discover main window is open, and will avoid re-loading the list of deployments and update every ~60 seconds, when rpm-ostree would have exited due to being idle, releasing the name on the bus. Fixes: https://bugs.kde.org/show_bug.cgi?id=480947 (cherry picked from commit e0907397d9b8f0cc4223c358d654a094eff5163e) M +7 -1 libdiscover/backends/RpmOstreeBackend/RpmOstreeBackend.cpp M +3 -0 libdiscover/backends/RpmOstreeBackend/RpmOstreeBackend.h https://invent.kde.org/plasma/discover/-/commit/8b8f9fd32cf8bb40bd800b8e6777476277295a5b