[Question] More than one user

[aanno]

We've got a (paid) spotify family account and I have set up spotifyd with my user. However with this, my son could not 'respot' to spotifyd (but he could see the device in his official spotify android app). Is this the expected behaviour? Is there a way around?

BTW, there a 'dump' devices like speakers that spotify could 'respot' to that are not registered/associated with a spotify account. I wonder if there is way to run spotifyd in a similiar mode?

[eladyn]

This should AFAIK be possible by just omitting the username, password, username_cmd and password_cmd options. It at least works for me on 0.3.2.

[aanno]

Yes, I tried to leave out the spotify account in the configuration, as the people at librespot said this is possible and librespot would work in 'discovery mode' then.

However:

$ systemctl --user status spotifyd
● spotifyd.service - A spotify playing daemon
     Loaded: loaded (/etc/xdg/systemd/user/spotifyd.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2021-05-17 08:51:45 CEST; 49s ago
       Docs: https://github.com/Spotifyd/spotifyd
   Main PID: 32070 (spotifyd)
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/spotifyd.service
             └─32070 /usr/bin/spotifyd --no-daemon

Mai 17 08:51:45 unke spotifyd[32070]: Loading config from "/etc/spotifyd.conf"
Mai 17 08:51:45 unke spotifyd[32070]: No username specified. Checking username_cmd
Mai 17 08:51:45 unke spotifyd[32070]: No username_cmd specified
Mai 17 08:51:45 unke spotifyd[32070]: No password specified. Checking password_cmd
Mai 17 08:51:45 unke spotifyd[32070]: No password_cmd specified
Mai 17 08:51:45 unke spotifyd[32070]: No proxy specified
Mai 17 08:51:45 unke spotifyd[32070]: Using software volume controller.
Mai 17 08:51:45 unke spotifyd[32070]: Connecting to AP "gew1-accesspoint-e-skbp.ap.spotify.com:443"
Mai 17 08:51:45 unke spotifyd[32070]: Authenticated as "<my_spotify_account_name>" !
Mai 17 08:51:45 unke spotifyd[32070]: Country: "DE"

As you see, spotifyd grabs my_spotify_account_name from some mysterious somewhere. The total result is still the same: I'm able to 'respot' to spotifyd but my son can't do that...

[eladyn]

Ok, I indeed have issues getting the exact behavior, you are trying to achieve.

Spotifyd should print "Authenticated as ..." as soon as you select it from from one of your accounts on the network in the devices list. So this message is probably normal as long as it does not pop up immediately after you start Spotifyd.

However, as soon as I'm trying to select spotifyd from an account while or after another account was playing something on it, it just exits. This might be related to #181.

So, while not a perfect solution you can do something similar to what this comment suggests:

• add a RestartSec= directive to spotifyd
• add Restart=always, since the unit just exits with 0 and not with any error, in the above case

If you now try to "respot" from another account, spotifyd should exit and after your specified time, it should restart in a clean state, where you can click on the device again from any account and it should work. This requires you or your family members to potentially click on the device several times in a row, but it should eventually work 😀.

Maybe this can get you further with resolving your issue...

[aanno]

This is my /etc/systemd/user/spotifyd.service definition:

[Unit]
Description=A spotify playing daemon
Documentation=https://github.com/Spotifyd/spotifyd
Wants=sound.target
After=sound.target
Wants=network-online.target
After=network-online.target

[Service]
ExecStart=/usr/bin/spotifyd --no-daemon
Restart=always
RestartSec=12

[Install]
WantedBy=default.target

It seems that the Restart trick does not solve my problem. I'm unsure if this is because spotifyd does not exit if another account tries to connect...

[eladyn]

Hmm. Your service definition looks nearly identical to mine.

Can you check the spotifyd logs with journalctl -f -u spotifyd.service (I'm not sure if you need --user as well). In my case it logs something like this:

May 22 17:55:44 device systemd[1]: spotifyd.service: Succeeded.
May 22 17:55:57 device systemd[1]: spotifyd.service: Service RestartSec=12s expired, scheduling restart.
May 22 17:55:57 device systemd[1]: spotifyd.service: Scheduled restart job, restart counter is at 2.

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

[mas-4]

I did some debugging with precisely this issue last night and got it to work:

This should AFAIK be possible by just omitting the username, password, username_cmd and password_cmd options. It at least works for me on 0.3.2.

This does indeed seem to be the solution, however it is insufficient: you also have to not set a cache_directory. If cache_directory is set, the credentials of the first user to connect to the device are cached and then after disconnecting no other user can connect. By disabling the cache anyone can connect.

It would perhaps be desirable if we could disable specifically credential caching.

[aanno]

Dear @mas-4,

it sounds like you've found my problem. Caching is enabled in my config. If username, password, username_cmd and password_cmd are not set, caching them looks like a bug to me.

Thank you very much!

[aanno]

Is there a way to reopen this ticket?

[mas-4]

Another observation I made last night while using it and switching users:

After one user disconnects, when a second user attempts to connect, the first attempt is a wash. It times out as though the caching was still enabled or the credentials were set. But every successive attempt is instantly successful. This behavior is strange to me, since there's no cache. Perhaps its cached in memory and then the failure restarts the program and the in-memory cache is thus erased?

It seems to be undesirable behavior but its easy to work around it.

I can't dig into the code because I don't know rust, but it seems like instead of using a single struct/variable to hold the credentials it might be better to have a set or hash map and append as users connect/disconnect.

[eladyn]

I just opened #1019, which might fix the problem. It would be great if one of you two could try it, as I'm currently not able to. The general problem is that most of the things (e.g. caching the credentials) is done by librespot and it is probably not worth digging further into this, before #977 is accepted (or even a PR that upgrades to 0.3 which is already available).

[aanno]

I just recapped this and I'm still not sure what to think about the restart/kill thing (#181). I haven't tried spotifyd without username/password and without cache. But if there are circumstances that will force spotifyd to exit/crash, it is probably unrelated to the issue that I've reported here.