Dbus not avalible when headless

[insoPL]

Session DBUS is not avalible without X11. It would be neat to add option in config to make MPRIS avalible through system dbus. When I edited dbus_mpris.rs
let c = Rc::new(Connection::get_private(BusType::Session).unwrap());
and changed Session to System and recompiled it everything worked great. I would make pull request but i cannot into rust so it will be mess anyway. Please can somone make it? It's big deal for headless raspberry users.

[ius]

I just ran into this as well (due to Arch/AUR enabling all features):

Jun 14 13:09:42 system spotifyd[11995]: 13:09:42 [ERROR] Caught panic with message: called `Result::unwrap()` on an `Err` value: D-Bus error: Server address of type unix was missing argument path or abstract (org.freedesktop.DBus.Error.BadAddress)
Jun 14 13:09:42 system systemd[1]: spotifyd.service: Main process exited, code=exited, status=101/n/a

Interestingly it still doesn't work for me if a user DBUS session is available (ie. when run as root via SSH) - it will start and become visible in proprietary Spotify clients, but exits as soon as playback is switched to spotifyd.

I don't see an obvious error in the debug logs, but the Ok(NotReady) does seem suspicous. When I rebuild without dbus_mpris and dbus_keyring everything works fine.

12:56:37 [DEBUG] dbus_tokio::adriver: Polling message stream
12:56:37 [DEBUG] dbus_tokio::adriver: msgstream found Ok(NotReady)
12:56:37 [DEBUG] tokio_reactor::registration: scheduling Write for: 6
12:56:37 [TRACE] mio::poll: [<unknown>:905] deregistering handle with poller
12:56:37 [DEBUG] tokio_reactor: dropping I/O source: 6
12:56:37 [DEBUG] librespot_connect::spirc: drop Spirc[0]
12:56:37 [DEBUG] librespot_playback::player: Shutting down player thread ...
12:56:37 [DEBUG] librespot_playback::player: drop Player[0]
12:56:37 [DEBUG] librespot_core::session: drop Session[0]
12:56:37 [DEBUG] librespot::component: drop MercuryManager
12:56:37 [DEBUG] dbus_tokio::adriver: Dropping AMessageStream
12:56:37 [DEBUG] dbus_tokio::adriver: AMessageStream telling ADriver to quit
12:56:37 [TRACE] tokio_threadpool::pool: [<unknown>:138] shutdown; state=pool::State { lifecycle: Running, num_futures: 0 }
12:56:37 [TRACE] tokio_threadpool::pool: [<unknown>:186]   -> transitioned to shutdown
12:56:37 [TRACE] tokio_threadpool::pool: [<unknown>:207]   -> shutting down workers

[julie-is-late]

Having the same issue, however it works for me after disabling only dbus_mpris, dbus_keyring seems to work fine.

[mainrs]

I can introduce a new config entry for this one.

[mainrs]

Going to push a change on this one today. The naming is a little bit off. As far as I understood dbus_keyring, which uses the Linux secrets api, needs dbus. But I didn't know that a system bus is always available. Because of that, the feature would probably be better of named keyring only.

Looks like it isn't that easy to add a new flag...

[mainrs]

Note to self: It needs a little bit more refactoring as the relevant information doesn't get passed down to the dbus server creation method:

spotifyd/src/dbus_mpris.rs

Lines 114 to 119 in ea66c13

	fn create_dbus_server(
	handle: Handle,
	api_token: RspotifyToken,
	spirc: Rc<Spirc>,
	device_name: String,
	) -> Box<dyn Future<Item = (), Error = ()>> {

Either we should pass down the whole SpotifydConfig, which is IMO too much. Or we could just pass down a flag called is_session_bus that gets set within the config.rs file inside of the SpotifydConfig struct. I would opt and prefer method 2.

[azrdev]

1. Even if you manage to put spotifyd's MPRIS interface onto the system bus, I'm not sure if the consumers of that interface look at the system bus at all.
2. That said, you can spawn an own session bus "just for spotifyd" by wrapping its invocation with a call to /usr/bin/dbus-run-session /path/to/spotifyd. Such might be useful for a headless (i.e. server/non-desktop) usage of spotifyd. To use that bus with other applications (e.g. mpris clients), look here
3. I use spotifyd in such a headless setup, and IMHO dbus/mpris seem to me like a bit heavy an interface for that case. Would it be possible to offer another more lightweight interface to tell spotifyd to play/pause/next/louder ?

[mainrs]

As far as I know, MPRIS seems to be a standard a lot of media players comply to. I do not know of any other specifications around media consumption. If you have an alternative, feel free to mention it. I know of mpd and there own protocol they use over stdout/stdin. But to be honest, I think MPRIS is a cleaner way to do this and I am not eager to introduce another custom protocol.

[johnalanwoods]

@sirwindfield,

This works well, however I see unusual CPU usage, it seems dbus spawns many Spotifyd processes, mostly running at 100% CPU usage.

@azrdev, are you seeing this issue?

[johnalanwoods]

Running as root seems to stop the high usage, still have about 4 processes though!

[mainrs]

Running as unprivileged user under WSL. The CPU usage is due to the host system. It spawned one single instance as well. Not sure, maybe something's wrong with your setup. Do you start it automatically on system start or inside of some bashrc related files? Maybe those are spawning it multiple times.

I run it with default configuration, just changed the backend because I don't have ALSA installed.

dbus-run-session ./target/release/spotifyd --no-daemon --backend rodio

Edit: If you run it as non-root, does it work? Can you stream music to it? Maybe it tries to fetch for resources (like accessing your device sound card) but fails due to missing rights. I'm just guessing right now though.

[0phoff]

I'm trying to setup a spotify player on a raspberry pi, but have been unsuccessful so far.
I followed what @azrdev explained and I can see my spotifyd process running in htop and can connect through spotify connect, but the MPRIS interface does not seem to be working.

I compiled this library from source, making sure to enable the dbus_mpris feature.

I tried the following command, but as you can see from the reply it does not seem to work:

> dbus-send --address="unix:path=/run/user/1000/bus" --print-reply --dest=org.mpris.MediaPlayer2.spotifyd /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.PlayPause
Error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Anyone that can help me out ?

[J-u-n-o]

After recompiling updated dbus_mpris.rs:
Commented-> //Connection::get_private(BusType::Session).expect("Failed to initialize DBus connection"),
Replace -> Connection::get_private(BusType::System ).expect("Failed to initialize DBus connection"),

I needed to change /usr/share/dbus-1/system.conf:
<policy context="default">
Added-> <allow own="org.mpris.MediaPlayer2.spotifyd"/>

[paxswill]

As a slight refinement of @juno72's D-Bus config change, I defined the policy for MPRIS for all members of the audio group by using this for /etc/dbus-1/system.d/audio-mpris.conf:

<?xml version="1.0"?><!--*-nxml-*-->
<!DOCTYPE busconfig PUBLIC
 "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
        <policy group="audio">
                <allow own_prefix="org.mpris.MediaPlayer2"/>
        </policy>
</busconfig>

Restricting it further based on user name would probably be better, but this is a shortcut.

[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.

[Magicking]

Using latest release 0.3.2 on a Raspbian GNU/Linux 10, the problem is still existing using default configuration without any easy way to fix that besides installing Xorg & al

[2opremio]

As a slight refinement of @juno72's D-Bus config change, I defined the policy for MPRIS for all members of the audio group by using this for /etc/dbus-1/system.d/audio-mpris.conf:

<?xml version="1.0"?><!--*-nxml-*-->
<!DOCTYPE busconfig PUBLIC
 "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
        <policy group="audio">
                <allow own_prefix="org.mpris.MediaPlayer2"/>
        </policy>
</busconfig>

Restricting it further based on user name would probably be better, but this is a shortcut.

In order to allow sending mpris messages to spotifyd from any process in the audio group I extended this to:

<?xml version="1.0"?><!--*-nxml-*-->
<!DOCTYPE busconfig PUBLIC
 "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
        <policy group="audio">
                <allow own_prefix="org.mpris.MediaPlayer2"/>
                <allow send_interface="org.mpris.MediaPlayer2.Player"/>
        </policy>
</busconfig>

[thirdeyetux]

It would be really great to have a config switch for connecting to the system dbus or the session dbus in spotifyd.
For now I also changed the source code and built spotifyd myself. In combination with the dbus policy configuration from @2opremio this works like a charm.

diff --git a/src/dbus_mpris.rs b/src/dbus_mpris.rs
index 34fb5f6..6d5eed1 100644
--- a/src/dbus_mpris.rs
+++ b/src/dbus_mpris.rs
@@ -113,7 +113,7 @@ fn create_spotify_api(token: &RspotifyToken) -> Spotify {
 async fn create_dbus_server(api_token: RspotifyToken, spirc: Arc<Spirc>, device_name: String) {
     // TODO: allow other DBus types through CLI and config entry.
     let (resource, conn) =
-        connection::new_session_sync().expect("Failed to initialize DBus connection");
+        connection::new_system_sync().expect("Failed to initialize DBus connection");
     tokio::spawn(async {
         let err = resource.await;
         panic!("Lost connection to D-Bus: {}", err);

[eladyn]

@thirdeyetux I created a PR for this a while ago (#954), although there hasn't been much maintainer activity on it yet.