Closed FrostiiZ closed 1 year ago
Can confirm, the same's happening here. For now, I'll just mask the update :/
Operating System: Fedora Linux 36 (Kinoite) KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.93.0 Qt Version: 5.15.3 Kernel Version: 5.17.12-300.fc36.x86_64 (64-bit) Graphics Platform: X11 Multimedia Framework : PipeWire
sudo flatpak update --commit=51df931abc1fca310d736d61acd178f063d98f63d5b4a769c2c15eff5234c8c3 com.spotify.Client
sudo flatpak mask com.spotify.Client
Another solution is to mute notification all sounds.
Another solution is to mute notification all sounds.
Thank you for your input and advice, but this does not sound like a viable solution to me. I'm using Linux for work, I might miss important notifications from other applications related to my job. This is a radical solution that may artificially hide the problem but does not fix the underlying issue. I understand this can be a temporary fix tho.
If you want to see real fix then reporting it here isn't enough. Maybe try asking about it in libnotify as its update triggered issue. If it's genuine spotify problem then chances for seeing a fix are pretty low.
I believe too that this isn't necessarily a Spotify issue, I haven't digged in the source code to find if a libnotify call may have changed inside the library thus Spotify triggering another type of event, or if a flag is required to dismiss the notification sound or anything else. I thought I would bring this issue to your attention, as other users may face the same problem and see on GitHub that this is known.
From libnotify's 0.8.0 changelog, as it is the version that introduced the issue for Spotify :
* Use Desktop Portal Notification when running confined (snap and flatpak)
Now the library acts like a wrapper in such scenario, with some limited
capabilities, but this will enforce security and user control over the
allowed notifications. [Marco]
I'm guessing that using flatpak's Desktop Portal Notification now triggers the ding sound, but I don't know how flatpak is configured.
From flatpak's Portal Notification documentation, it seems like there is a priority setting in the AddNotification() method that is maybe called by Spotify or libnotify with a priority set to something else than low (its default value seems to be normal) and KDE plays a sound when this low priority is not set within a notification event. Maybe there is something there.
There should be no difference in priority, or any property probably, between using the portal and not. If there is that may be a libnotify bug. KDE not allowing configuration of notifications for the portal sounds like a clear bug on their end and it behaving differently in general could be a KDE bug. Certainly needs more investigation.
Another solution is to mute notification all sounds.
Or to disable notifications when a song changes in the Spotify settings.
I have created an issue on libnotify's GitLab, I hope they have any information regarding this new behavior with notifications.
Would it be possible for the priority setting to be patched into each notification in the Flatpak version?
Actually, I just found these:
https://bugs.kde.org/show_bug.cgi?id=457672 https://invent.kde.org/frameworks/frameworkintegration/-/merge_requests/13
Spotify sends a notification for each played song, which is the expected behavior. Nonetheless, since the update that includes libnotify-0.8.0, every played song notification makes a "Ding" sound that is quite annoying and distracting on KDE Plasma 5.24.6. I've tried to disable the notification's "Ding", but no option is available in Plasma Settings, Spotify is marked as "not allowing to configure notifications" and even disabling contextual windows or notification badges does not make the "Ding" disappear.
I've rolled-back to the Flathub commit
51df931abc1fca310d736d61acd178f063d98f63d5b4a769c2c15eff5234c8c3
, which uses libnotify-0.7.12 and the issue disappeared.Command used to list FlatHub commits :
flatpak remote-info --log flathub com.spotify.Client
Last Flathub commit that does the expected behavior with libnotify-0.7.12 :
Related GitHub commit : 0b61f264069fc3eaa99be5f0e2bda5ae5b6d565e
First Flathub commit that introduced the issue :
Related GitHub commit : 9ea6776dadc8683f8ce343beff8125c3e824dfd4
Latest Flathub commit to this date that still includes the issue :
Related GitHub commit : a8b9c26e20683ccb4be20d4a0cedb6ea02943342
I've found how to rollback with Flatpak thanks to this comment in another issue : Issue #202
Some infos about my system :
I hope I have been helpful in a way or another. Thank you for your time and have a very great day !