Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spotifyd appends *.instanceXXX to the D-Bus service name #1261

Open
2 of 6 tasks
itsdeyan opened this issue Jan 28, 2024 · 6 comments
Open
2 of 6 tasks

Spotifyd appends *.instanceXXX to the D-Bus service name #1261

itsdeyan opened this issue Jan 28, 2024 · 6 comments
Labels
bug A functionality or parts of a program that do not work as intended

Comments

@itsdeyan
Copy link

Description
The D-Bus service name for Spotifyd always has a random number at the end, for example org.mpris.MediaPlayer2.spotifyd.instance378
This way I can't control it with playerctl on my machine.

To Reproduce
Run spotifyd with the use_mrpis = true and dbus_type = system options.

Expected behavior
Spotifyd to register as org.mpris.MediaPlayer2.spotifyd and not have the .instanceXXX at the end

Compilation flags

  • dbus_mpris
  • dbus_keyring
  • alsa_backend
  • portaudio_backend
  • pulseaudio_backend
  • rodio_backend

Versions (please complete the following information):

  • OS: Arch Linux, headless
  • Spotifyd: 0.3.5-1
@itsdeyan itsdeyan added the bug A functionality or parts of a program that do not work as intended label Jan 28, 2024
@eladyn
Copy link
Member

eladyn commented Jan 28, 2024

Thank you for the issue. That is actually an intentional feature that has been added some time ago and should be in line with the MPRIS specification.

The reason, why you cannot use playerctl to control your spotifyd application is that playerctl only supports the session bus, while you want to run spotifyd on the system bus. So there are two possible fixes for this:

  • Launch spotifyd from within a dbus-launch process and connect with playerctl to the same bus.
  • Manually call the relevant endpoints: You can still manually use the interface e.g. with the following command:
    qdbus --system $(qdbus --system | grep spotifyd | xargs) /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.PlayPause

@itsdeyan
Copy link
Author

The reason, why you cannot use playerctl to control your spotifyd application is that playerctl only supports the session bus, while you want to run spotifyd on the system bus.

I was actually able to control spotifyd with playerctl. Things got complicated when I also ran shairport-sync. When both daemons are running, only shairport-sync responds to playerctl (even while it's paused and spotifyd's playing).

I can temporary make it work by addressing both players by their names, for example:
$ playerctl play-pause -p ShairportSync, spotifyd.instance32214
But that'd only work for a while, and then the .instanceXXXX part changes. That's why I'd help in my case if there was an option to turn off the random numbers at the end....

@eladyn
Copy link
Member

eladyn commented Jan 30, 2024

Oh, that's interesting and good to hear. IIRC, playerctl also accepts -p spotifyd and then it should look for the relevant bus name.

If not, you can also get the number dynamically, since it's always the PID of spotifyd. So you should be able to add -p spotifyd.instance$(pidof spotifyd) or something. (untested)

@klemensn
Copy link
Contributor

klemensn commented Feb 4, 2024

The reason, why you cannot use playerctl to control your spotifyd application is that playerctl only supports the session bus, while you want to run spotifyd on the system bus. So there are two possible fixes for this:

playerctl(1) works just fine against the system bus, at least on OpenBSD where the audio/spotifyd package's rc.d(8) daemon script runs spotifyd on the system bus.

dbus-monitor --system run as root confirms that playerctl run as my local user comunicates just with with spotifyd running as unprivileged _spotifyd user (given a proper D-Bus service policy, of course).

@klemensn
Copy link
Contributor

klemensn commented Feb 4, 2024

Oh, that's interesting and good to hear. IIRC, playerctl also accepts -p spotifyd and then it should look for the relevant bus name.

FWIW, that is enough to pick, e.g. spotifyd.instance68391 amongst multiple players, i.e. no need for me to specify the full name as playerctl seems clever enough to do that.

@klemensn
Copy link
Contributor

klemensn commented Feb 4, 2024

The reason, why you cannot use playerctl to control your spotifyd application is that playerctl only supports the session bus, while you want to run spotifyd on the system bus.

I was actually able to control spotifyd with playerctl. Things got complicated when I also ran shairport-sync. When both daemons are running, only shairport-sync responds to playerctl (even while it's paused and spotifyd's playing).

I also use both daemons, but I think it depends on the order of startup and/or which daemon is currently playing.

I can temporary make it work by addressing both players by their names, for example: $ playerctl play-pause -p ShairportSync, spotifyd.instance32214 But that'd only work for a while, and then the .instanceXXXX part changes. That's why I'd help in my case if there was an option to turn off the random numbers at the end....

Either way, instead of forcing spotifyd under its dynamic name, have you tried ignoring shairport-sync?

     -i NAME, --ignore-player NAME
             Ignore the specific player NAME.  Multiple players can be
             specified in a comma-separated list.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A functionality or parts of a program that do not work as intended
Projects
None yet
Development

No branches or pull requests

3 participants