SUMMARY This may be related to bug 455046 or bug 451393, but I think it is different enough to be its own distinct thing. Before the update to Plasma 5.26.0, selecting a media player in the widget would keep it selected as long as the application was open. After 5.26.0, pausing playback means that the selection is not respected any more and other media players can become the active ones. To give a practical example, if I am listening to music with Strawberry and pause it, and then I watch a video on YouTube using Firefox, the media player widget will show Firefox as the active application, so I can no longer control Strawberry even if I had manually selected it earlier. STEPS TO REPRODUCE 1. Select a media player manually in the widget and use it to play media content 2. Pause playback 3. Start playback of media content with another application OBSERVED RESULT The other application hijacks control and is the one that actually receives commands e.g. from media keys. EXPECTED RESULT The selected application stays selected so that it received input e.g. from media keys. SOFTWARE/OS VERSIONS Linux: KDE neon KDE Plasma Version: 5.26.0 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.6 ADDITIONAL INFORMATION
I think I can reproduce this. When I manually set the media player to Elisa and then play a YouTube video in Firefox, the global play/pause shortcuts target Firefox, not Elisa. However the widget still shows Elisa.
(In reply to Nate Graham from comment #1) > I think I can reproduce this. When I manually set the media player to Elisa > and then play a YouTube video in Firefox, the global play/pause shortcuts > target Firefox, not Elisa. However the widget still shows Elisa. In my case, the widget shows Firefox as the active application, which is why I had set the title to be more general (and why I am reverting it back to the original).
There was no real change in mpris2 https://invent.kde.org/plasma/plasma-workspace/-/commits/master/dataengines/mpris2 And I remember the mediacontroller will always switch to the current active player regardless of the previous selection, so I think this is a feature request?
(In reply to Fushan Wen from comment #3) > There was no real change in mpris2 > https://invent.kde.org/plasma/plasma-workspace/-/commits/master/dataengines/ > mpris2 > > And I remember the mediacontroller will always switch to the current active > player regardless of the previous selection, so I think this is a feature > request? I don't know if this is related to mpris2 so I trust you on that, but in previous Plasma versions I used to select a player and it would remain the active one until I selected another one. I am sure of this as I used to use this feature daily, which is why I noticed the regression.
With 5.27, the widget shows the selected media player, but media keys ignore that. As an example (formatting as a list for better readability): - I listen to music using Strawberry and pause it - then watch a video on YouTube with Firefox and pause it - then click on the Media Player widget and select Strawberry as the active player - then use media keys to resume playback with Strawberry the YouTube video is the one that actually receives the input. The only way for Strawberry to be controlled again through media keys is to resume playback manually (either from the program itself or using the button in the widget) so that it becomes the active media player again.
Don't have media keys but I seem to know the cause. Will look into it.
Unfortunately it's not easily fixable. There can be more than one media controller widget, so the global media shortcuts can only operate on the default media player, otherwise the logic will be confusing.
(In reply to Fushan Wen from comment #7) > Unfortunately it's not easily fixable. There can be more than one media > controller widget, so the global media shortcuts can only operate on the > default media player, otherwise the logic will be confusing. The "easy" solution would then be to synchronise the user's selection across the widgets, but I guess that is not technically easy to implement.
*** This bug has been marked as a duplicate of bug 409190 ***