https://bugs.kde.org/show_bug.cgi?id=391545
--- Comment #1 from Friedrich W. H. Kossebau <kosse...@kde.org> ---
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
expected.
# 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
https://specifications.freedesktop.org/mpris-spec/latest/Player_Interface.html#Property:CanPlay
. 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
assumption.
--
You are receiving this mail because:
You are watching all bug changes.
