Open ghost opened 5 years ago
I also receive this error message when running in a terminal (not through a hotkey) (playerctl:24510): GLib-GIO-WARNING **: 11:05:53.840: Received property Position with type i does not match expected type x in the expected interface
I'm looking at their issue tracker and like half the issues are mpris-related. This player is very buggy. I'll see what I can do.
We fixed almost all of the issues regarding MPRIS on the master branch. As of https://github.com/Spotifyd/spotifyd/issues/276, it looks like it still doesn't work. The only problem we currently still have is a wrong PlayerStatus
property implementation as their Web API changed and we didn't get around fixing this (Tracking issue https://github.com/Spotifyd/spotifyd/issues/353).
Edit: the wrong PlayingStatus got fixed with the latest release of v0.2.19 as well.
Oh ok if you're doing web requests for the properties, this explains the delay.
There's a call to GetAll
on the properties interface that the glib dbus library does to get all the properties to init the property cache.
We use properties to determine if the command is supported. So like the case when CanPlay
is false, we don't send the command. The normal assumption is that all the player properties are in memory.
So I guess there's an opportunity for some optimization on my side (and yours) to make this faster.
I experience the same, with playerctl 2.0.2-1 and spotifyd compiled from latest master as of today:
❯ time playerctl status
Playing
playerctl status 0,02s user 0,00s system 0% cpu 25,047 total
I'm also having this issue but not on Spotify. It takes about 25 seconds to interact with Google Play Music Desktop Player. Works fine with other players.
$ time playerctl -p google_play_music_desktop_player play-pause
real 0m25.035s
user 0m0.005s
sys 0m0.005s
$ time playerctl -p chrome.instance3220 play-pause
real 0m0.011s
user 0m0.006s
sys 0m0.003s
edit: Perhaps this has nothing to do with player-ctl. After restarting the player, it seems to be working.
Possibly related: #174
I have this problem with spotifyd as well, but the issue is not the command (eg. Play / Pause), but the "Properties.GetAll" that precedes it. I don't know what spotifyd is doing, but it takes 4s. Maybe it's fetching the song metadata from Spotify each time?
The actual command is very quick as can be seen in this dbus trace:
No. | Time | Source | Destination | Destination Path | Message Type | Length | Info |
---|---|---|---|---|---|---|---|
127 | 4.007486 | :1.205 | :1.137 | /org/mpris/MediaPlayer2 | Method call | 178 | GetAll() @ /org/mpris/MediaPlayer2 |
128 | 8.037043 | :1.137 | :1.205 | Method reply | 1040 | -> 'a{sv}' | |
129 | 8.037343 | :1.205 | :1.137 | /org/mpris/MediaPlayer2 | Method call | 144 | Pause() @ /org/mpris/MediaPlayer2 |
130 | 8.037407 | :1.137 | :1.205 | Method reply | 56 | -> '' |
Is this GetAll
related to playerctl's job as a proxy, or is it needed for the command invocation in some way? Maybe it can be skipped, at least for commands that don't depend on the current state of the player.
Currently having what I think is the same issue, here's the timing from literally just status (along with firefox for reference):
➜ playerctl -l
firefox.instance36115
spotifyd.instance35280
➜ time playerctl status -p firefox
Playing
playerctl status -p firefox 0.01s user 0.00s system 80% cpu 0.017 total
➜ time playerctl status -p spotifyd
No player could handle this command
playerctl status -p spotifyd 0.01s user 0.00s system 0% cpu 25.039 total
(decided to see if it was different while spotifyd was playing)
➜ time playerctl status -p spotifyd
Playing
playerctl status -p spotifyd 0.01s user 0.00s system 0% cpu 27.049 total
as a temporary solution i adapted scripts from this thread to directly address the dbus without playerctl
and the delay is now prety much gone.
#!/usr/bin/env bash
# to specifically select spotifyd:
# player=$(dbus-send --session --dest=org.freedesktop.DBus --type=method_call --print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames | grep org.mpris.MediaPlayer2.spot | awk -F '"' '{print $2}')
# to send directly to playerctl:
player=org.mpris.MediaPlayer2.playerctld
if [[ "$1" == "--play-pause" ]]; then
qdbus $player /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.PlayPause
elif [[ "$1" == "--next" ]]; then
qdbus $player /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.Next
elif [[ "$1" == "--prev" ]]; then
qdbus $player /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.Previous
fi
and then the bindings (i use hyprland):
bindl = , XF86AudioPlay, exec, $SCRIPT/controls/media --play-pause
bindl = , XF86AudioPrev, exec, $SCRIPT/controls/media --prev
bindl = , XF86AudioNext, exec, $SCRIPT/controls/media --next
surprisingly you can send the command directly to playerctl
daemon, and that seems to not have any delay. the advantage of that is it will pick the active player itself.
The player I am using is Spotifyd
there seems to be a delay between a command and the action. sometimes it is as long as several seconds. there's no delay e.g. with this controller https://github.com/mariusor/mpris-ctl