What is the current method to support multiple accounts?

[mpollow]

Spotifyd in version 0.4.1 runs like a charm on my Raspberry Pi and Arch Linux. At least as just a single account is using it.

Using it with a Family or Duo account, I ran into the issue that only the first account can use it. The others can join the session, but without the first account it is not possible to connect. I use zeroconf without credentials in the config file. Still there is a credentials.json file created in the .cache/spotifyd/zeroconf directory, containing the username and authentification data of the user that has been signed in.

Searching the old Issues on Github, I now found a solution that works for me, as described by euri10 some years ago:
#114 (comment)

Just setting the RestartSec to a smaller value (as someone also commented in this thread) didn't do the trick for me.

Is the setup with multiple systemd services still the way to go? I could imaging that a somewhat more elegant solution exists that I haven't found yet. For example, not storing credentials at all in the cache folder and just accepting whatever account wants to log in.

[eladyn]

I'm not entirely sure what's happening there, but I'm gonna describe what spotifyd is doing and throw in some guesses. Hopefully this'll help us to figure this out.

Assuming that zeroconf is enabled (like in your case) and cached credentials are available (either from OAuth or from the last zeroconf connection, where OAuth would be prioritized):

• A discovery server is started at application startup and will be continuously accepting new connections.
• When a new connection is initiated via zeroconf, the current session will be terminated and the new user gets control.
• When no session is active and there's no incoming connection from zeroconf, the cached credentials will be used to initiate a new session.

By this description, I would expect any other user to be able to override the currently active session via zeroconf. But since that apparently isn't working for you, my next guess would be that Spotify has made some changes in this regard (similar to their join-the-session feature), which will only offer users to join the currently active user on the device instead of terminating this session.

To test this hypothesis, there's a few things I'd be interested in:

• When spotifyd first starts (as in: no user has selected device yet), does Spotify also only offer the user with the cached session to connect and the others will only be able to join? Or is the device still open to anyone at this point?
• If the first user disallows others to join (using the toggle in the mobile client), are other users able to see the device / claim it as their playback device?
• How do official connect devices handle such cases?

Anyway, if this is what's happening, a short-term workaround might be (assuming you have dbus controls working):
Regularly check, via an external process, if spotifyd has been paused for some time now (e.g. 5 minutes). If that is the case, call org.mpris.MediaPlayer2.Player.Stop. This will disconnect the current session and should hopefully force Spotify to allow new connections.

If you don't have dbus controls, you could still do something similar in a slightly more hacky way: Set onevent to a script, which checks, if the event is Pause or Stopped. If this is the case, the script starts a timer, and when the timer elapses, it manually restarts spotifyd via systemd. Any other event should reset that timer.

That's my current braindump on your issue, hopefully at least some of it applies. ^^ Let me know, what you find!

[mpollow]

Thanks for the insights. Found some time for some more testing using two devices with different accounts.

When spotifyd first starts (as in: no user has selected device yet), does Spotify also only offer the user with the cached session to connect and the others will only be able to join? Or is the device still open to anyone at this point?

On startup of spotifyd the device is visible to all accounts and anyone can connect. It doesn't matter which account information is stored in ~/.cache/zeroconf/credentials.json. Whoever tries to login first succeeds, the credentials file is then updated in the background, just as expected.

If the first user disallows others to join (using the toggle in the mobile client), are other users able to see the device / claim it as their playback device?

If the first connected user disallows others to join, the device remains visible for the other users. Interestingly, at that point it is possible to capture the device for another user. That works even when the first user is still using the device. The music of the first user stops, the music of the second user starts. The credentials file is updated in the .cache/zeroconf folder.

In the mobile app of the first user, the device still seems connected (spotifyd device is shown in green) after the other user has captured the device. After that, it is not possible to connect to the spotifyd device again, even after manually disconnecting. On the mobile app the loudspeaker symbol of the spotifyd device flashes for about 20 sec ("Connecting...") until the connection request apparently times out. Even when the other user has disconnected, the first user cannot reconnect. Restarting the mobile app for the first user also does not help. Restarting spotifyd helps to allow the connection. Have to look into dbus messaging to test if that helps.

I only have two accounts, so I cannot test if a third user could capture the connection from the second user. Possibly the first user cannot reconnect after the connection was stolen from him for some reason. Let me know if I should do some more tests.

[eladyn]

Thank you for trying all that!

In the mobile app of the first user, the device still seems connected (spotifyd device is shown in green) after the other user has captured the device. After that, it is not possible to connect to the spotifyd device again, even after manually disconnecting. On the mobile app the loudspeaker symbol of the spotifyd device flashes for about 20 sec ("Connecting...") until the connection request apparently times out. Even when the other user has disconnected, the first user cannot reconnect. Restarting the mobile app for the first user also does not help. Restarting spotifyd helps to allow the connection. Have to look into dbus messaging to test if that helps.

I just looked at the librespot code here, I think in the current release they forgot to update Spotify about the active state after we called shutdown on the session. So Spotify probably still assumes the device to be active even after the client has shut down. (Edit: This has been fixed in the dev version of librespot however, so you can expect at least that behaviour to go away soon.)

Other than that, the behaviour that you describe mostly fits my expectations. I have one further question, though. In your original report, you said:

I ran into the issue that only the first account can use it. The others can join the session, but without the first account it is not possible to connect.

What exactly did you mean by that? Wouldn't joining the session allow the other users to control the device as well? Or are there some things that only the "primary" user can do?

[mpollow]

Thanks for looking into that!

I ran into the issue that only the first account can use it. The others can join the session, but without the first account it is not possible to connect.

What exactly did you mean by that? Wouldn't joining the session allow the other users to control the device as well? Or are there some things that only the "primary" user can do?

Exactly, the other user can join the session, as long as the primary user is still connected. After the primary user has left / closed the session, the second user cannot take over and has apparently no way to start the playback. Could very well be that the session is still open and thus blocked for the second user.

Great to hear that the bug has already been fixed, hope it is soon released.