Having the same issue, my screenshot looks identical would be redundant to upload.

Same here - I tried to update manually, but that was not a good idea. any workaround to unstuck discover?

+1 for same issue, when running updates through terminal I got this error message regarding a dependency conflict with libuuid: 
Problem: installed package libmount-2.41.4-7.fc44.x86_64 requires libuuid(x86-64) = 2.41.4-7.fc44, but none of the providers can be installed
  - installed package systemd-259.6-1.fc44.x86_64 requires libmount.so.1()(64bit), but none of the providers can be installed
  - installed package systemd-259.6-1.fc44.x86_64 requires libmount.so.1(MOUNT_2.26)(64bit), but none of the providers can be installed
  - conflicting requests
  - problem with installed package

Might have something to do with it? I tried fixing it but quite frankly I don't dare do anything more than I've already done and my system still works completely fine otherwise

Same here. Have to use dnf until there is a resolution. I wonder if it's specific to Fedora?

Yeah I disabled snap a few days ago no difference for me. I just have to keep updating via konsole until the update tab in discover is fixed.

(In reply to jz5678910 from comment #5)
> https://bugs.kde.org/show_bug.cgi?id=500513
> 
> Check out this thread for the current work-around.
> 
> Appears to be related to snaps

Same as prior comment, I never had snap enabled in Discover.

An update for PackageKit was released today, doesn't resolve the issue though. Still reliant on CLI for updates.

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

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

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

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

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

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

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

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

There are quite a few people reporting this on different distros (Fedora and Neon so far). Raising priority.

This was reported being in terminal output by multiple people

qrc:/qt/qml/org/kde/discover/qml/UpdatesPage.qml:40:5: QML OverlaySheet: Binding loop detected for property "y":
qrc:/qt/qml/org/kde/kirigami/templates/OverlaySheet.qml:121:5
packagekitqt.offline: Properties could not be invalidated "org.freedesktop.PackageKit.Offline" QList("PreparedUpgrade")
packagekitqt.offline: Properties could not be invalidated "org.freedesktop.PackageKit.Offline" QList("PreparedUpgrade")
packagekitqt.offline: Properties could not be invalidated "org.freedesktop.PackageKit.Offline" QList("PreparedUpgrade")
packagekitqt.offline: Properties could not be invalidated "org.freedesktop.PackageKit.Offline" QList("PreparedUpgrade")

However, that was seen by one user after Discover successfully showed updates, so that may be unrelated

Comming from https://bugs.kde.org/show_bug.cgi?id=522169 closed as duplicate of this
Excluding fwupd as a backend, reliably works around the issue for me.

`plasma-discover --backends packagekit,flatpak,fwupd --mode update`
stalls (logging in 522169)

`plasma-discover --backends packagekit,flatpak --mode update`
completes as normal

started as of plasma-discover-6.7.0-1.fc44.x86_64
(Fedora 44 also)

I don't encounter this on KDE Linux; it's likely in the PackageKit backend, or an interaction between it and another backend.

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

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

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

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

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

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

(In reply to Steve Sibelman from comment #21)
> 
> Interesting.  For me, fwupd is AOK.  Excluding snap suffices

There's a separate but related report for the snap backend in bug 500513

Please do not include quoted text in your replies, except where necessary. It adds noise to the report. Thanks for understanding.

Created attachment 193747 [details]
attachment-3427259-0.html

I don't have snap enabled and Discover still doesn't show the updates.

Glad that your Discover app is working now though!

On 6/26/26 15:14, Adam wrote:
> https://bugs.kde.org/show_bug.cgi?id=521682
>
> --- Comment #29 from Adam<blackwar3592@gmail.com> ---
> Yes it's actually snap backend error on the discover, because when i disabled
> snap, every update was visible.
>

(In reply to Steve Sibelman from comment #21)
> ...For me, fwupd is AOK...
I should have included (from my original issue) that fwupd services are all masked disabled under my issue.

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

This Bugzilla ticket is about those *not* using the Snap backend; re-opening.

Bug 500513is the one tracking the issue with the Snap backend specifically.

I have same problem.

`
plasma-discover --mode update
org.kde.plasma.libdiscover: OdrsReviewsBackend: Fetch ratings: false
adding empty sources model QStandardItemModel(0x56039bab4660)
qrc:/qt/qml/org/kde/discover/qml/DiscoverWindow.qml:124:5: QML Shortcut: Shortcut: Only binding to one of multiple key bindings associated with 15. Use 'sequences: [ <key> ]' to bind to all of them.
qrc:/qt/qml/org/kde/discover/qml/UpdatesPage.qml:40:5: QML OverlaySheet: Binding loop detected for property "y":
qrc:/qt/qml/org/kde/kirigami/templates/OverlaySheet.qml:121:5
qt.qpa.services: Failed to register with host portal QDBusError("org.freedesktop.portal.Error.Failed", "Could not register app ID: Connection already associated with an application ID")
packagekitqt.offline: Properties could not be invalidated "org.freedesktop.PackageKit.Offline" QList("PreparedUpgrade")
packagekitqt.offline: Properties could not be invalidated "org.freedesktop.PackageKit.Offline" QList("PreparedUpgrade")
packagekitqt.offline: Properties could not be invalidated "org.freedesktop.PackageKit.Offline" QList("PreparedUpgrade")
packagekitqt.offline: Properties could not be invalidated "org.freedesktop.PackageKit.Offline" QList("PreparedUpgrade")
QIODevice::read (QSslSocket): device not open

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

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

Same here, screen-shot would show the same output just in German.

(In reply to Ty from comment #51)
> I updated title, as the bug -is- snap-related, but specific to
> plasma-discover-snap.
> 
> I believe this should be a medium-priority issue with regards to distros
> that are more reliant on Snap, such as Kubuntu. In fairness, those distros
> will typically hold back a few versions anyway, but I could be mistaken.

I'm on Fedora, I don't use snap, I have no snap packages installed... and yet, this broke discover for me. I wouldn't say this is medium priority. I would say this is very high priority, especially considering anyone that has this issue, and doesn't have technical knowledge to be able to use the terminal, is now completely stuck, unable to update at all, including getting important security updates, which in today's day and age, with all the kernel exploits being found, is a really bad situation to be in.

All of you who are discussing Snap, your bug report is Bug 500513. This is about the case where Snap support is NOT enabled.

(In reply to Anthony Lee from comment #55)
> I'm not familiar with how the KDE project uses this bugzilla with regard to
> their actually development work, i.e. is are these tickets ever changed to
> status 'assigned' once someone is working on it? Is blocked and depends on
> filled once a task is begun?
The status automatically changes to ASSIGNED once there's a merge request open that references this bug using its number.

> ## I concur that the priority of this issue should be bumped. ##
It's already set to VHI ("very high") priority. There is no higher priority level.

(In reply to Nate Graham from comment #56)
> All of you who are discussing Snap, your bug report is Bug 500513. This is
> about the case where Snap support is NOT enabled.

I think both those bug reports should be rolled into one.

Three things:

1st My bug report was rolled into this one, which is why I've been continuing comment on this one.

2nd Snap backend is not enabled for me, yet this still happens anyway. I still need to manually remove the snap backend to get discovered to work again, despite it being already disabled, and it automatically gets reinstalled after a few days.

3rd I think all those issues, whether they're snap related or otherwise should all be rolled into one bug report, because it's not reasonable for back end modules to bring down all of the rest of Discover like this. It shouldn't matter whether it's an issue with snap, or firmware updates, or whatnot...

No one cares what's going on in the backend. People care that discover is hanging on checking for updates. That's the core issue, and we shouldn't lose sight of that.

This behavior is the problem, not what's causing it in the backend. If multiple things are causing this behavior in the backend, then that just means that there needs to be a fundamental change with how these backends are handled within Discover, so they can't break Discover in this sort of way, if those backends misbehave.

Discover is a fundamental and important part of KDE. When Discover breaks in such a way, any user that doesn't know how to navigate through a terminal, is permanently and irrecoverably stuck. That's not an acceptable failure mode. Without using the terminal, those users will never get updates ever again, including the updates that will fix their problem.

Treating this as an issue with those backends, instead of a fundamental issue with Discover, makes Discover fundamentally unreliable and unstable.

I understand from a technical perspective why the focus might be on the individual separate back,ends that are causing this issue but the problem isn't that the issue happened, the problem is that the issue was at all possible in the first place. That's where our focus should be. 

We are all well versed enough to be able to dig ourselves out of this hole in the terminal.
The users that are now permanently and forever stuck, unable to ever update again, are the users that do not have a voice in this thread, and are the users that we should be thinking about when we consider how to solve this issue.

We can't have this kind of thing happen again.

(In reply to Nabeel from comment #58)
> (In reply to Nate Graham from comment #56)
> > All of you who are discussing Snap, your bug report is Bug 500513. This is
> > about the case where Snap support is NOT enabled.
> 
> I think both those bug reports should be rolled into one.
No, because there are two bugs. One affects people using Snap, and goes away when they remove the Snap backend. The other one (this one) is not about that and persists even if you don't have Snap at all.

> 1st My bug report was rolled into this one, which is why I've been
> continuing comment on this one.
> 
> 2nd Snap backend is not enabled for me, yet this still happens anyway.
That means you are affected by both Bug 500513 and this one.

> despite it being already disabled, and it automatically gets
> reinstalled after a few days.
This sounds very bad, but it's not a KDE issue. It would be something coming from the distro's packaging. Please do bring it up with them.

> No one cares what's going on in the backend. People care that discover is
> hanging on checking for updates. That's the core issue, and we shouldn't
> lose sight of that.
Clearly. But you're on a technical bug tracker which is for tracking specific technical bugs. Since there are multiple bugs, they need to be tracked separately.

> We are all well versed enough to be able to dig ourselves out of this hole
> in the terminal.
> The users that are now permanently and forever stuck, unable to ever update
> again, are the users that do not have a voice in this thread, and are the
> users that we should be thinking about when we consider how to solve this
> issue.
> 
> We can't have this kind of thing happen again.
Definitely not! Feel free to be a part of the solution by helping to fix the issue. And afterwards, you can help make sure it doesn't happen again by adding relevant autotests and integration tests.

If you aren't capable of performing those actions, then the next most helpful thing you can do is avoid making too much noise in Bugzilla that distracts and de-motivates the developers (who for Discover are all volunteers!)  who *are* capable of resolving the issue.

Thanks for understanding! No need to reply unless you have new information that can help developers fix the bug.

RE: new plasma-discover 6.7.3, confirm that symptoms of https://bugs.kde.org/show_bug.cgi?id=522169 remain unchanged. Issue still occurring.

It was suggested so I've done some work on investigating this issue.

The issue seems to be as follows (and this is what I put in my commit message):

Before: `StandardBackendUpdater::refreshUpdateable()` skipped `setSettingUp(false)` for a backend that invalidated before setup, but `isFetchingUpdates()` tested only `fetchingUpdatesProgress() != 100` and `m_settingUp`, so both being false let the Updates page finish normally.

Now: commit `401d8e26ac4509a7538c4382daf6063bc40c36a8` appended `|| !m_hasBeenPopulated` to that test while leaving the `if (m_settingUp)` guard that prevents flow into that flag's only write site (`setSettingUp()`), so in this scenario `m_hasBeenPopulated` is never written and stays false for the life of the process, stranding `isFetchingUpdates()` true and leaving the page on a filled bar reading "Fetching updates…".

Fix: the patch calls `setSettingUp(false)` unconditionally in the branch that stands an updater down when its backend has reported itself permanently invalid, so the flag is finally set and `fetchingChanged()` is emitted for `ResourcesUpdatesModel::refreshFetching()` to re-evaluate, which clears `isFetching` and lets the page proceed as it did before the regression.

The fix could look like this (in patch form)

> ---
>  libdiscover/resources/StandardBackendUpdater.cpp | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/libdiscover/resources/StandardBackendUpdater.cpp b/libdiscover/resources/StandardBackendUpdater.cpp
> index 54f786ab1..cbcd75d1c 100644
> --- a/libdiscover/resources/StandardBackendUpdater.cpp
> +++ b/libdiscover/resources/StandardBackendUpdater.cpp
> @@ -175,10 +175,12 @@ void StandardBackendUpdater::refreshUpdateable()
>  {
>      if (!m_backend->isValid()) {
>          qWarning() << "Invalidated backend, deactivating" << m_backend->name();
> -        if (m_settingUp) {
> -            setSettingUp(false);
> +        const bool wasSettingUp = m_settingUp;
> +        setSettingUp(false);
> +        if (wasSettingUp) {
>              Q_EMIT progressingChanged(isProgressing());
>          }
> +        Q_EMIT fetchingChanged();
>          return;
>      }
>  
> -- 
> 2.55.0

The above is based on patching 6.7.3  6f1960f62 .
You can find the original commit here https://invent.kde.org/orthogonaleety/discover/-/commit/71230e3f284ddc30d721eebe91f89064ad218d10

Now I'm not a dev, so I've used a software support approach of localisation and risk managing the limitations while working with Claude.
I'm 100% satisfied with the fix for 'my issue', but I'm only 75% 'confident' in it against the entirety of this bug, and I'm 0% confident it doesn't have a side effect I haven't projected and don't understand, and can't test.

- I have built it.
- And tested it and it works to fix my issue when executing  `plasma-discover --backends packagekit,flatpak,fwupd --mode update` (so including my problematic fwupd backend.)

However, I don't have a fix written for master branch. Claude static analysis reveals the patch would cherry-pick onto master without conflict, and the logic of the fix still applies there - but it would have no effect. Master, apparently moved this state into a cache, so the fix's logic as-is would still leave a stale, still problematic state being tested.

I will continue to look at developing a fix for master, satisfying myself (not just claude) that there aren't any side effects, but I'm not a dev, so no one hold their breath or wait on that.
In lieu of such, I hope this is able to shortcut someone to a fix even so.

Stale commit link, here is the good one.
https://invent.kde.org/orthogonaleety/discover/-/commit/89ad42afbd19e70d18a1aad1223ecb7704c32096