add configuration option for bus type

[eladyn]

This adds a new configuration option to configure which bus should be used by spotifyd. It addresses situations like #944 or one I personally found me in, where access to the MPRIS interface on headless systems would really help a lot.

Since I'm quite new to the codebase as well as the Rust ecosystem in general, I'm not sure if everything I changed / added was a good idea. Therefore, I'm always happy to take improvement proposals and adapt the PR accordingly. 😀

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[eladyn]

This PR might be somewhat obsolete, if #977 gets accepted. It would be great to get some feedback from the maintainers, what I should do about this PR!

Edit: I also rebased on the latest master, if you want to consider merging it.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[eladyn]

Anyone able to look at this (or decide that it is no longer relevant / needed)?

[eladyn]

I rebased this on top of master. @simonpersson could you have a look at this? (Or someone else from the maintainer team, of course)

[SimonTeixidor]

Hi! This looks OK to me, but I don't use dbus myself so I don't feel comfortable to merge. If you could fix the rustfmt check I'll approve, and then we hope some other maintainer can show up to test it a bit more.

[eladyn]

Thanks for your feedback! I ran rustfmt (and the other pre-commit hooks) on the PR and CI should be fine now.

[eladyn]

I just noticed that this PR had merge conflicts since quite some time and resolved them. The changes are not too complex, so it should be easy enough to review.

[GChalony]

For what it's worth, I can confirm that this PR works for me on a Raspberry Pi.
I've been looking for a way to control spotifyd without the Spotify Web API (too slow), so I tried to use MPRIS and ended up here.

However, the situation is still unclear to me :

• does spotifyd run network calls to answer MPRIS queries ?
• is this PR unnecessary because system DBUS is already supported ? I stumbled upon Dbus not avalible when headless #244 or Upgrade librespot to 0.2.0 #977 and I don't understand if they fixed it or not

Feedback :
Installation was relatively smooth, I just had to install libdbus-1-dev to be able to compile it properly. I've also edited /usr/share/dbus-1/system.conf to allow the spotifyd to access system dbus (with a systemctl reload dbus to reload the config).
I can see the org.mpris.MediaPlayer2.spotifyd service over the system dbus (I use python-dbus).

[eladyn]

@GChalony, glad to hear that it works!

• does spotifyd run network calls to answer MPRIS queries ?

Unfortunately, it has to, at least in some cases. Simple operations though like Play, Pause, Next or VolumeUp are executed locally.

• is this PR unnecessary because system DBUS is already supported ? I stumbled upon Dbus not avalible when headless #244 or Upgrade librespot to 0.2.0 #977 and I don't understand if they fixed it or not

At least as far as I know, the issue is still not resolved. The first thing you linked to was closed by the stale bot and the second one did not introduce the possibility to use the system bus for MPRIS, it only reworked some backend stuff.

[GChalony]

Right that's basically what I suspected. It's still a win if it doesn't take 2s to pause.

Well as far as I'm concerned thus PR can be merged. I don't know much about Rust, but I can review if you need an approver :)

[slondr]

cool

[eladyn]

Thank you!