Delay

[ghost]

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

[ghost]

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

[acrisci]

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.

[mainrs]

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.

[acrisci]

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.

[varac]

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

[hirowatari]

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.

[cashpw]

Possibly related: #174

[diegov]

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.

[Oman395]

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

[haykh]

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.