I have constructed a web app to control Mopidy (+Mopidy-Spotify plugin) via the built-in HTTP POST API: I’m using local connections on the server, so not mopidy.js. Everything is working splendidly.
Almost everything, that is – after some time when not playing, or after a restart, the Spotify login times out. Looking at other clients (presumably using mopidy.js) they all have some sort of “connection” indicator, or method to “connect” the service. I haven’t found a way to manage this connection in the API documentation. Is there a way?
The Spotify connection(s) are handled by Mopidy, clients have no control/visibility over backend availaibility and it’s not in our Core API.
By the time your computer has finished starting and you start using it, Mopidy should have had time to initialise and login all the backends but this is not guaranteed. You can run into problems if your computer is not configured to wait for its internet connection to become ready before starting other services. That could be your issue. People have run into this before, especially with Raspberry Pis.
Or your client could just be trying to talk to Mopidy before it’s finished starting. Clients using the websocket library can indeed avoid this problem by using the online/offline websocket events but these relate to the status of Mopidy’s Http server and not the Spotify (or other backed) connection status. Event for online/offline don’t make sense for the HTTP RPC API where there’s normally one connection per request and you have to handle the fact the connection might fail yourself.
I’m not totally sure what your actual problem here is but maybe this background info helps. Mopidy logs would be useful if it’s a startup problem. I can’t think why there’d be any connection issues once Mopidy has started and has been left idle for a while. Logs definitely needed in that case.
OK, so the “connection”/“auth” things used by (e.g.) Mopify and Iris, using some kind of external self-hosted HTTP proxy url, has nothing to do with helping Mopidy with any authorization/reconnection process, but is simply used to login and cover (from the frontend) for the things the backend can’t handle, and all that due to good libs being unavailable for some Spotify functions?
At least then I know where to start checking. Or, where not to check.
Yep, exactly. The Mopidy Core API doesn’t (can’t) map exactly onto all service APIs and there are gaps which Iris fills by doing its own calls directly.
Hmm maybe this has been just me assuming things then, after restarts I haven’t kept track of or so (it’s on a dev server), because of the tracklist not being kept between restarts and the presence of “connect” buttons in other systems and my previous usage of a FIFO (I just switched to TCP). Will investigate further now that I’ve switched and know more.
Again, much thanks, both for this conversation and a very fine product!
