Since the last update Discover became very slow when fetching updates. Downloading then and installing is o.k. (like before). I noticed this during several updates now, so you can say it's reproducible. I have no figures right now like time for n updates to fetch but a rough guess would be ten times as long compared to what I was used to.
Can you run "pkcon get-updates" on the console and tell me if that also takes really long?
pkcon get-updates
Yes, I can do so once there are new updates announced.
O.k., I tested that. It was a second, maybe two. Console output was this: -------------------------------- :~$ pkcon get-updates Getting updates [=========================] Loading cache [=========================] Finished [=========================] Bug fix firefox-51.0.1+build2-0ubuntu0.16.04.2.amd64 (ubuntu-xenial-updates-main) Safe and easy web browser from Mozilla Bug fix firefox-locale-de-51.0.1+build2-0ubuntu0.16.04.2.amd64 (ubuntu-xenial-updates-main) German language pack for Firefox Bug fix firefox-locale-en-51.0.1+build2-0ubuntu0.16.04.2.amd64 (ubuntu-xenial-updates-main) English language pack for Firefox Bug fix libhogweed4-3.2-1ubuntu0.16.04.1.amd64 (ubuntu-xenial-updates-main) low level cryptographic library (public-key cryptos) Bug fix libhogweed4-3.2-1ubuntu0.16.04.1.i386 (ubuntu-xenial-updates-main) low level cryptographic library (public-key cryptos) Bug fix libjavascriptcoregtk-4.0-18-2.14.3-0ubuntu0.16.04.1.amd64 (ubuntu-xenial-updates-main) JavaScript engine library from WebKitGTK+ Bug fix libnettle6-3.2-1ubuntu0.16.04.1.amd64 (ubuntu-xenial-updates-main) low level cryptographic library (symmetric and one-way cryptos) Bug fix libnettle6-3.2-1ubuntu0.16.04.1.i386 (ubuntu-xenial-updates-main) low level cryptographic library (symmetric and one-way cryptos) Bug fix libwebkit2gtk-4.0-37-2.14.3-0ubuntu0.16.04.1.amd64 (ubuntu-xenial-updates-main) Web content engine library for GTK+ Bug fix libwebkit2gtk-4.0-37-gtk2-2.14.3-0ubuntu0.16.04.1.amd64 (ubuntu-xenial-updates-main) Web content engine library for GTK+ - GTK+2 plugin process ------------------------------ I tried then with Discover and it took 2min. 20 sec.. I closed without updating in case you need more tests.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!
I'm having the same issue with very long wait times for update fetching. Linux/KDE Plasma: Neon 5.23 User Edition (available in About System) KDE Plasma Version: 5.23.5 KDE Frameworks Version: 5.89.0 Qt Version: 5.15.3
The problem is that Discover is unbearably slow to query updates, and it doesn't cache them so has to keep re-fetching them. When Discover shows a systray alert to tell me there are updates and I click the popup, it takes about 30 seconds for it to show me the available updates. Despite the fact that it JUST finished checking for updates and told me there are available updates. Why check again immediately, when it only checked a few seconds ago? Why isn't there a cache with an expiration age? Is it the firmware and/or flatpak updates that are slow, as dnf doesn't check for those? Is there not a cache for those updates? Checking using dnf or pkcon is much faster. So much faster that while waiting for Discover to finish fetching updates I can open konsole, run sudo dnf, enter my password, **and download and install the updates** before Discover even finishes checking for them. SOFTWARE/OS VERSIONS Discover: 5.24.3 Operating System: Fedora 34 KDE Plasma Version: 5.24.3 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.2 Kernel Version: 5.16.18-100.fc34.x86_64 (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-8650U CPU @ 1.90GHz Memory: 31.0 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620
I am sorry but this is simply not true. In PackageKitBackend.cpp:107 you can see that we only refresh the cache if it's over 1 hour old. It would be useful if you can provide feedback if you have the same problem when running with: * plasma-discover --backends flatpak * plasma-discover --backends packagekit Also could you state which distros are you on respectively?
I'm on Neon, I'll hold of on updates a while and get back to you. Right now there's just one pending for chrome and when I open with the packagekit backend it takes almost 10 seconds to load the first time. Subsequent times it's done almost instantly. pkcon get-updates is almost immediate, but I suppose that doesn't require image data.
(In reply to Aleix Pol from comment #9) > I am sorry but this is simply not true. In PackageKitBackend.cpp:107 you can > see that we only refresh the cache if it's over 1 hour old. And yet when I've JUST booted up and got the systray popup as soon as I login, it takes 30+ seconds to show the available updates. Is the systray popup using stale data straight after boot, so then when I open the GUI it refreshes? > It would be useful if you can provide feedback if you have the same problem > when running with: > > * plasma-discover --backends flatpak > * plasma-discover --backends packagekit I'll try this and report back. > Also could you state which distros are you on respectively? See above, Fedora 34
Time to run the command and then quit the app as soon as it finishes "Loading..." the updates. $ time plasma-discover --backends flatpak file:///usr/lib64/qt5/qml/org/kde/kirigami.2/private/PrivateActionToolButton.qml:74:5: QML Binding: Binding loop detected for property "value" file:///usr/lib64/qt5/qml/org/kde/kirigami.2/AbstractApplicationWindow.qml:282:5: QML Binding: Not restoring previous value because restoreMode has not been set. This behavior is deprecated. You have to import QtQml 2.15 after any QtQuick imports and set the restoreMode of the binding to fix this warning. In Qt < 6.0 the default is Binding.RestoreBinding. In Qt >= 6.0 the default is Binding.RestoreBindingOrValue. file:///usr/lib64/qt5/qml/org/kde/kirigami.2/AbstractApplicationWindow.qml:282:5: QML Binding: Not restoring previous value because restoreMode has not been set. This behavior is deprecated. You have to import QtQml 2.15 after any QtQuick imports and set the restoreMode of the binding to fix this warning. In Qt < 6.0 the default is Binding.RestoreBinding. In Qt >= 6.0 the default is Binding.RestoreBindingOrValue. real 4m46.710s user 0m22.899s sys 0m8.797s Running the same command again right away: $ time plasma-discover --backends flatpak file:///usr/lib64/qt5/qml/org/kde/kirigami.2/private/PrivateActionToolButton.qml:74:5: QML Binding: Binding loop detected for property "value" file:///usr/lib64/qt5/qml/org/kde/kirigami.2/AbstractApplicationWindow.qml:282:5: QML Binding: Not restoring previous value because restoreMode has not been set. This behavior is deprecated. You have to import QtQml 2.15 after any QtQuick imports and set the restoreMode of the binding to fix this warning. In Qt < 6.0 the default is Binding.RestoreBinding. In Qt >= 6.0 the default is Binding.RestoreBindingOrValue. file:///usr/lib64/qt5/qml/org/kde/kirigami.2/AbstractApplicationWindow.qml:282:5: QML Binding: Not restoring previous value because restoreMode has not been set. This behavior is deprecated. You have to import QtQml 2.15 after any QtQuick imports and set the restoreMode of the binding to fix this warning. In Qt < 6.0 the default is Binding.RestoreBinding. In Qt >= 6.0 the default is Binding.RestoreBindingOrValue. real 0m10.474s user 0m4.988s sys 0m2.028s That's still pretty slow even with a fresh cache. And for PK: $ time plasma-discover --backends packagekit adding empty sources model QStandardItemModel(0x56366b77b160) file:///usr/lib64/qt5/qml/org/kde/kirigami.2/private/PrivateActionToolButton.qml:74:5: QML Binding: Binding loop detected for property "value" file:///usr/lib64/qt5/qml/org/kde/kirigami.2/AbstractApplicationWindow.qml:282:5: QML Binding: Not restoring previous value because restoreMode has not been set. This behavior is deprecated. You have to import QtQml 2.15 after any QtQuick imports and set the restoreMode of the binding to fix this warning. In Qt < 6.0 the default is Binding.RestoreBinding. In Qt >= 6.0 the default is Binding.RestoreBindingOrValue. file:///usr/lib64/qt5/qml/org/kde/kirigami.2/AbstractApplicationWindow.qml:282:5: QML Binding: Not restoring previous value because restoreMode has not been set. This behavior is deprecated. You have to import QtQml 2.15 after any QtQuick imports and set the restoreMode of the binding to fix this warning. In Qt < 6.0 the default is Binding.RestoreBinding. In Qt >= 6.0 the default is Binding.RestoreBindingOrValue. ** (process:795073): WARNING **: 14:40:20.266: System cache issue: The AppStream system cache was updated, but some errors were detected, which might lead to missing metadata. Refer to the verbose log for more information. real 0m3.491s user 0m2.518s sys 0m0.452s So it seems that flatpak is the slow part, even when the cache is up to date. If I just run "plasma-discover" and click on the "Fetching updates..." (which quickly turns into "Update (32)") menu item at the bottom left, the progress bar is still going, at about 95% or so, until at least 10 seconds after starting the app. That matches what I see when I click on the systray popup: it shows a progress bar at about 95% and stays like that for a subjectively long time (sometimes over 30 seconds).
*** This bug has been marked as a duplicate of bug 443555 ***