spotifyd daemon closes on connection attempt

[jfangiolini]

Today, I tried to connect to spotifyd both from PC and Android phone and it stucks on the "Connecting to ..." message.
Running the service manually with spotifyd --no-daemon --verbose shows that spotifyd exits after connection attempt, this is the tail of the log:

received packet from 192.168.0.96:5353
received packet from 192.168.0.96:5353 with no query
received packet from 192.168.0.96:5353
received packet from 192.168.0.96:5353 with no query
received packet from 192.168.0.96:5353
received packet from 192.168.0.96:5353 with no query
received packet from [fe80::47a6:9d47:759f:7547%3]:5353
received packet from [fe80::47a6:9d47:759f:7547%3]:5353 with no query
received packet from [fe80::47a6:9d47:759f:7547%3]:5353
received packet from [fe80::47a6:9d47:759f:7547%3]:5353 with no query
deregistering event source from poller
registering event source with poller: token=Token(251658247), interests=READABLE | WRITABLE
deregistering event source from poller
registering event source with poller: token=Token(268435463), interests=READABLE | WRITABLE
deregistering event source from poller
registering event source with poller: token=Token(285212679), interests=READABLE | WRITABLE
POST "/" {}
Connecting to AP "ap.spotify.com:443"
registering event source with poller: token=Token(301989894), interests=READABLE | WRITABLE
deregistering event source from poller
flushing framed transport
writing; remaining=345
framed transport flushed
flushing framed transport
framed transport flushed
attempting to decode a frame
frame decoded from buffer
attempting to decode a frame
drop Spirc[0]
Shutting down player thread ...
drop PlayerInternal[0]
PlayerInternal thread finished.
drop Session[0]
flushing framed transport
framed transport flushed
drop Dispatch
deregistering event source from poller
drop MercuryManager
deregistering event source from poller
sending packet to 224.0.0.251:5353
received packet from 192.168.0.96:5353
received packet from 192.168.0.96:5353 with no query
sending packet to [ff02::fb]:5353
deregistering event source from poller
deregistering event source from poller
deregistering event source from poller

Prior to exiting, the verbose log is in a loop between registering and deregistering from the pooler, and the device list in spotify client keeps refreshing with each cycle. Attached is a full log of a couple of these cycles and the service stop: log.txt

Spotifyd was wotking fine a few days ago, I don't know if this is a spotifyd issue or a Spotify API problem, any help is appreciated

[jfangiolini]

I found similar issues reported with multiple accounts connected to spotifyd, a couple days ago a friend connected to spotifyd with his account and I think this is the issue, I haven't tried to connect with my account since then. Is there a way to "flush" previous connected accounts?

EDIT: specifying username and password in config file and manually lauching the service seems to fix the issue, now it works with or without user/pass specified in config file, definitively connecting a second account effs up everything.

[eladyn]

This is probably related to this issue which tracks this problem down to the credentials caching, which you seem to use (cache_directory in your config).

So to work around this, you can either disable the caching entirely or clear the cache directory. Alternatively, as you discovered, you can of course set a fixed username and password to solve your problem.

In general, this issue should be fixed and especially exiting silently is not very good either for tracking down the problem.

[mrusme]

Similar issue here, spotifyd plays a songs that I initiated via the Spotify mobile app and all of the sudden just quits:

flushing framed transport
framed transport flushed
attempting to decode a frame
attempting to decode a frame
frame decoded from buffer
attempting to decode a frame
frame decoded from buffer
attempting to decode a frame
flushing framed transport
framed transport flushed
attempting to decode a frame
frame decoded from buffer
attempting to decode a frame
flushing framed transport
framed transport flushed
attempting to decode a frame
flushing framed transport
framed transport flushed
attempting to decode a frame
frame decoded from buffer
attempting to decode a frame
frame decoded from buffer
attempting to decode a frame
File 892fac9dd93fb6c8123b753f8bb0e43c8b3b4635 complete
flushing framed transport
framed transport flushed
Connection to server closed.
Invalidating session[0]
subscription terminated
drop Spirc[0]
Shutting down player thread ...
drop Dispatch
drop PlayerInternal[0]
PlayerInternal thread finished.
drop Session[0]
drop AudioKeyManager
drop ChannelManager
drop MercuryManager
flushing framed transport
framed transport flushed
deregistering event source from poller
deregistering event source from poller
deregistering event source from poller
deregistering event source from poller
deregistering event source from poller

//edit: Probably more related to #523

[klay2000]

I have the same issue, when someone else connects to Spotifyd after I've been connected it shuts down without throwing any sort of error. I think credentials caching would cause Spotifyd to still crash when another user connects after a restart but after some digging I found this issue which describes exactly this problem. It looks like it was fixed quite awhile ago so to actually stop this from happening without a restart I think we need to update to the latest version of Librespot.

[klay2000]

So I tired running Librespot on the version Spotifyd uses and I can't reproduce the problem so now I'm thinking the problem is we must be doing something like saving credentials and not replacing them when another user connects. Can someone point me to where we're getting credentials if they're not specified when starting Spotifyd? I can find where we load them, but I can't find where we get them if someone connects and I'd love to try and fix this problem.

[eladyn]

@klay2000 Your issue seems indeed different from the one described here and more like #902. I should have fixed it with #1059, but I don't have two accounts at hand right now, so I can't test this. Can you confirm, this problem is still there on the current master?

[klay2000]

It looks like it's still happening on master.

[eladyn]

@klay2000 Hmm, interesting. Like I said, I don't have a second account to test that right now, but I'll try to describe what I'd expect to happen, and maybe you can trace down the bug (and fix it) with that information:

1. If no credentials are provided, we initialize a discovery stream and pass it to the newly created MainLoop.
2. When the MainLoop is run, it waits for the discovery stream to provide new credentials.
3. Upon receiving credentials, everything's set up and initialized properly
4. In the inner loop (state: we are connected to a user), we listen for incoming connections and disconnect from the current session, if there is a new user trying to connect.
5. Afterwards, we continue from (2).

Hope this was somehow understandable!

[klay2000]

Thanks! Turns out it's actually all good, I started debugging and immediately realized I was on my fork of Spotifyd and not the actual repo, I pulled down the actual repo and it works perfectly.

[eladyn]

Should be fixed by now.