Bug 341205

Can you check the output of CanGoPrevious/CanGoNext/CanPause/CanPlay? If that returns false, it's a client bug since the mediacontroller disables the button when the client announces it cannot go back/forward/pause/play

Created attachment 89719 [details]
screenshot

qdbus org.mpris.MediaPlayer2.tomahawk /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.CanGoPrevious 
true

qdbus org.mpris.MediaPlayer2.tomahawk /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.CanGoNext
true

qdbus org.mpris.MediaPlayer2.tomahawk /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.CanPause
true

qdbus org.mpris.MediaPlayer2.tomahawk /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.CanPlay
true

No they're all true

Created attachment 89856 [details]
D-Bus log from bustle

For me all buttons except "pause" are disabled. (Pause doesn't work too anyway).

If I run kquitapp5 plasmashell and open it again, then the media controls work fine.

It looks like the bug always occurs if Tomahawk is opened after plasmashell. It looks like the plasmoid bugging out since it querys mpris before tomahawk's service comes online. I've attached the relavent logs.

Created attachment 90374 [details]
plasmashell log

Thanks! I've seen that with VLC but I thought that was due to us blacklisting the parent vlc instance (it creates multiple mpris services), so this is a different issue then if it affects Tomahawk as well.

This seems to have been fixed by dropping the VLC workaround.

How would that be related? That workaround just completely skipped/ignored one vlc mpris instance, that should in no way affect tomahawk, no?

should this be fixed in Plasma 5.2? Because i'm still not able to controll tomahawk via plasma widget

5.3* not .2

is there something we can do to help you fixing this bug? because it really kills my workflow on plasma5

I can control Tomahawk using the applet, seeking, pause, next, etc. The Previous/Next button is  a bit glitchy (the Previous button is greyed out all the time whereas the Next button is never, even at the end of the playlist). Sometimes I cannot skip to the next track but that doesn't work when I go directly through DBus either when that happens.

this is the situation for me on 4 computers:
https://youtu.be/p7jfgD_n1VE

i simply cant use the controlls..

Tomahawk 0.8.4
Plasma 5.3.1

I'm using Tomahawk 0.7.0
Martin, any idea on this one?

Tomahawk 0.7.0 here, works fine.

Tomahawk 0.8.4 does not. Perhaps they broke something. I'll have a closer look.

Alright so issuing the dbus command to tomahawk directly (qdbus) works fine. However running bustle I can see that when you press play/pause in the applet, no dbus command is sent at all, so this is clearly a bug in the applet.

I know exactly what's up. Upon opening, this is what tomahawk sends to Plasma for "org.freedesktop.DBus.Properties.GetAll org.mpris.MediaPlayer2.Player"

@a{sv} {"CanControl": <@b True>, "CanGoNext": <@b False>, "CanGoPrevious": <@b False>, "CanPause": <@b False>, "CanPlay": <@b False>, "CanSeek": <@b True>, "LoopStatus": <@s "None">, "MaximumRate": <@d 1.0>, "Metadata": <@a{sv} {}>, "MinimumRate": <@d 1.0>, "PlaybackStatus": <@s "Stopped">, "Position": <@x 0>, "Rate": <@d 1.0>, "Shuffle": <@b False>, "Volume": <@d 0.75>}

The same query from qdbus *when the playback is on*.

@a{sv} {"CanControl": <@b True>, "CanGoNext": <@b False>, "CanGoPrevious": <@b False>, "CanPause": <@b True>, "CanPlay": <@b True>, "CanSeek": <@b True>, "LoopStatus": <@s "None">, "MaximumRate": <@d 1.0>, "Metadata": <@a{sv} {"mpris:artUrl": <@s "file:///tmp/Dragonforce_Inhuman%20Rampage%20(Bonus%20CD)_tomahawk_cover.png.ou9476">, "mpris:length": <@x 441000000>, "mpris:trackid": <@o "/track/b96d6647dd6745219ed0c9cee4ee14dd">, "xesam:album": <@s "Inhuman Rampage (Bonus CD)">, "xesam:artist": <@as ["Dragonforce"]>, "xesam:title": <@s "Through The Fire And Flames">}>, "MinimumRate": <@d 1.0>, "PlaybackStatus": <@s "Playing">, "Position": <@x 207138000>, "Rate": <@d 1.0>, "Shuffle": <@b False>, "Volume": <@d 0.75>}.

I just noticed that this has more data and also things actually work when tomahawk is running and plasma is restarted.

It kinda makes sense - tomahawk sets "CanPause/CanPlay" only when there is an active playback. Now the dataengine is actually checking for these being present and if they are not, the controls won't have any effect.

This looks like a bug in tomahawk after all because it does signal out "PropertiesChanged" for various properties, but never for "CanPause/CanPlay".

On the other hand, perhaps the controls should be working when "CanControl" is true (which it is from the beginning), or the applet should query again for "CanPause/CanPlay" when the playback status changes.

All and all, ultimately this bug is because of how vague the mpris2 spec is. Again.

Couple clarifications after I reread the spec (after years):

CanPlay
When this property changes, the org.freedesktop.DBus.Properties.PropertiesChanged signal is emitted with the new value.
Whether playback can be started using Play or PlayPause.
Note that this is related to whether there is a "current track": the value should not depend on whether the track is currently paused or playing. In fact, if a track is currently playing (and CanControl is true), this should be true.

...
So in fact, the behavior our media applet has is absolutely correct. When there is no song in the playlist, "Play/PlayPause" wouldn't do anything and in that case "CanPlay/CanPause" is correctly false (according to spec). When the playback changes, Tomahawk however must update the "CanPlay/CanPause" property (as per the spec) which it doesn't and this should be reported to Tomahawk devs. Furthermore, Tomahawk's own context menu has "Play" action which also does nothing when pressed (it also has enabled "Play" action in the main window which also does nothing at all).

***
So, I take back my previous comment about this bug coming from the vagueness of mpris, this is, in fact a bug in Tomahawk as can be seen all around its own UI.
***

I'd probably still recommend to recheck for "CanPlay/CanPause" ourselves when the playback changes; in the worst case we update the property twice (once from players sending the "PropertiesChanged" signal).

But as far as I'm concerned, this bug can be closed as INVALID/UPSTREAM.


http://specifications.freedesktop.org/mpris-spec/latest/Player_Interface.html#Property:CanPlay

Closing as per Martin K's in depth analysis