--- Comment #1 from Friedrich W. H. Kossebau <> ---
Hi, thanks for the report & sorry for having caused trouble for you by getting
slightly more strict about MPRIS usage.

By your report I for now suspect this might be a bug with Spotify's (or some
wrapper to it? no clue about spotify code) implementation of the MPRIS spec. I
do not have/use spotify myself, so cannot test.

This is what you can do to help with this problem: 
On the commandline when spotify is running you can inspect its MPRIS
properties. Please tell what you get as results when spotify is not reacting as

# Find the D-Bus MPRIS service name of spotify
# Should return something like "org.mpris.MediaPlayer2.spotify"
qdbus | grep org.mpris.MediaPlayer2

# Assuming the name is "org.mpris.MediaPlayer2.spotify" (adapt if needed)
# now check the states of the properties "CanPlay" & "CanPause"
# (each qdbus call can also be done in one line, using multiline with \
# just because of this input field)
qdbus org.mpris.MediaPlayer2.spotify /org/mpris/MediaPlayer2 \
    org.freedesktop.DBus.Properties.Get org.mpris.MediaPlayer2.Player CanPlay
qdbus org.mpris.MediaPlayer2.spotify /org/mpris/MediaPlayer2 \
    org.freedesktop.DBus.Properties.Get org.mpris.MediaPlayer2.Player CanPause

The property query results ("true" or "false") should match what the MPRIS spec
requires for them giving the current state the spotify app is in. See
. Especially important in the spec is this bit:
"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."

Chance is that this is not matched given your description. But for now just my

You are receiving this mail because:
You are watching all bug changes.

Reply via email to