Realtime player state updates

[lrholmes]

I'm working on a webapp that incorporates a custom player using the new /player endpoints.

I'm wondering what your recommendations are for keeping track of the user's playback?

At the moment I've implemented a solution that works pretty well when the user stays and controls from my player, but will desynchronise if the user pauses or scrubs from the Spotify player, so I'm going to start polling the GET /player endpoint.

With regards to rate limits and general good practice, how often should I make a request to this endpoint? Every second would be ideal but with many users could that cause rate limit issues?

[marcinciarka]

Websockets would be good.

[tobyonono]

I'm having a similar issue as well and I don't wanna make tonnes of api requests!

[lrholmes]

@tobyonono my solution for the time being is to update the player locally every second, and every fifth second poll GET /player instead and update my player to match the state of the response. This means that there's a maximum of about four seconds for the player to be out-of sync, but most times it'll update quicker than that. I think making a request every 5 seconds will be totally acceptable in terms of rate limits.

[natael]

The Spotify WebHelper remote/status.json-Endpoint (which is used to show the Player State on open.spotify.com) keeps the Request open until an event occurs (play/pause) or gets closed after a timeout (so you could assume the Player is still playing normally and reopen the Request again).

Would be nice to have this for the WebAPI as well, or are the opened connections worse in this case?

[danjohnson95]

@natael Yeah I agree - something similar to Twitter's Streaming API would be perfect.

[marcinciarka]

Any updates on this?

[igormp]

Any news? Months have gone by without any official word. Anyway to keep track of the current playing song (along with changes to it, like a trigger) through the API would be awesome, be it through websockets, long polling or webhooks.

[hughrawlinson]

if this message conflicts with anything from spotifys side, its fine to delete this post. just wanted to help ^^

We had to delete the comment I quoted - we'll comment further next week.

[astorks]

An official comment on this would be nice. We have an application with over 9,000 active users and counting so we've had to delay pulling from the endpoints to every 30+ seconds per user due to being rate limited (we're making 250k+ requests per day). Any more users and we're going to have to delay pulling from the endpoints even further and we're already having users complain about the delays.

[andrewkirc]

I'm also building an app that polls this API endpoint. Webhooks would be great!

[seahorsepip]

Starting to get a rather high request count for this endpoint (almost 350k/day), I'm already implementing code to lower the poll rates in "ambient (non active)" mode but at this rate I'll run into rate limits soon :/

[lrholmes]

Hi all, today I spent some time working on my own implementation of WebSockets with the Connect API. I've not been able to test it a huge amount, but I think it works quite well and might satisfy some of you while waiting on official support, so I made it into an npm package (and there's also a test server set up for anyone to play with): https://github.com/lrholmes/spotify-connect-ws

It doesn't help the rate limit issue, but reduces the amount of polling and diffing that your client will have to do to monitor changes in the playback. Instead, you just need to connect, listen for events, and the server will trigger them as required.

Hopefully it helps someone!

[hughrawlinson]

Hi! I'm super sorry for not following up on my comment quickly enough. We're aware of the need to track song playback in real time, and we're looking for a good way to provide it. We don't have any announcements to make right now.

@seahorsepip for your "ambient" mode, it might be good to look at the Get Recently Played endpoint so that you don't miss anything. The most often this needs to be requested to get all the data is every 25 minutes.

[lenielsen]

Apparently, lastfm does not have any issues with the api rate limit. They request every second. http://a.pomf.cat/txcnlf.png

[seahorsepip]

@gLarsVegas Your link throws a security alert with ESET antivirus :P

As for api rate limit, didn't have any issues here either yet while requesting every 3 seconds with 5000+ monthly users.

[astorks]

Here's a bit of an update from my end. My application is currently at around 50,000 monthly users and over 100,000 total users. We are running into major rate limiting (almost to the point of being un-usable, 3+ minutes between updates) so I decided to look into how Discord implemented this. It looks like Discord has a web socket API endpoint that is locked so only their client Id has access. I'm not sure if this is going to be available to the public any time soon but an update would be nice as we have over 100,000 users relying on this app and we have no support from spotify.

[seahorsepip]

@astorks

I would consider using a websocket implementation like posted earlier above at that point and use multiple registered application keys. Not sure if that's against the Spotify guidelines though, they probably don't approve it obviously.

[astorks]

@seahorsepip

We are using a websocket implementation (we actually had to due to the fact that our application is so large it would just kill any web server if we where constantly polling). As for multiple application keys that's a possibility as long as it isn't against the Spotify developer agreement but even then I believe part of the rate limiting is based on IP addresses so we would still get rate limited. I just find it annoying that Spotify is claiming they are working on a solution but they already have one it's just locked to Discord's client id. It would be nice if we could get an actual update on what is happening.

[lrholmes]

@astorks It may not be applicable for your app, but have you implemented the new Web Playback SDK? I don't think that has the same rate limitations as the Connect API (you'll still need to use it, but you might be able to get away with less frequent polling).

Aside from that, considering your number of users you might want to try asking for an increase on your limits, I believe I read somewhere that they will do it in special cases (and probably have done so for Discord).

[jscholes]

@astorks Could this be the same websocket-based system used by Last.fm radio these days when playing via Spotify? I obviously wouldn't ask you to document/describe it here further than what you've already said, but I don't have access to Discord so if you get a chance, it might help you to look into Last.fm's implementation too.

[seahorsepip]

@lrholmes I've looked into the web playback SDK but it offers playback in a web app like the Android SDK offers playback on an Android device, it does not offer a way to get the playback state from other devices as far I've seen. So it's not a solution for the use case where you want to control and show playback state on another device.

Discord probably has a commercial agreement with Spotify which gives them access to non public APIs.

[astorks]

@lrholmes I have looked into the Web Playback SDK and unfortunately it wont work with our current setup as it would require the user to constantly cast their playback to a web app. I'm not even sure where to start with requesting a rate limit increase but I will look into this.

@jscholes It could be the same api, I'm not really sure. I know Spotify used to push updates to Last.fm directly from the client. I'll take a look into how Last.fm works but I'm not sure how much I can publicly document as it's not a public API.

@seahorsepip Yeah Discord and Spotify have an agreement which is great for Discord users but annoying for us smaller developers trying to build our own apps.

[artechventure]

Wish to have update for this feature! Would be very useful

[ydrolet]

I endorse this idea that Spotify gives public access to an event-driven API that uses WebSocket for example.

[jayheavner]

My vote for websockets

[vinii8817]

My vote for websockets [2] I'm having a similar issue. No more pooling, Not in 2018 ;)

[shivpatel]

WebSockets would be great. I'll burn through the rate limit if I was polling the v1/me/player/currently-playing route.

I'd also highly encourage looking into support for HTML5 SSE (Server-Sent Events).

[tjhrulz]

Given that the local API has been removed this really needs to be added so we don't have to worry about over polling and end up rate limited (Especially since rate limits are per app not per user)

[bugproof]

So if I understand correctly discord uses some completely different, private method to track currently played song?

It sounds bad if I have to call the API every second to get current position of the played song.

[WeeJeWel]

@arirawr Is there any news or ETA on this functionality?

[frenchbread]

+1

[half2me]

+1 I guess...

[lachieh]

Just add a reaction to the main post or subscribe to the issue. Don't add +1 comments.

[lomholdt]

I hope this is going to be a thing in 2019! 🎉 Fingers crossed 🤞

[Coding-Kiwi]

I dont get it, wouldn't it be more resource saving for spotify's servers to provide websockets instead of handling tons of /GET requests every second? If the thing is already implemented, why not for everyone

or webhooks/callbacks?

[arirawr]

Hey folks - Thank you for your continued interest in this feature! We're very aware that this is a highly-requested feature.

I don't have any updates to share with you right now but I'll be sure to update here as soon as we have something to share.

[TG4LAaron]

Any news? @arirawr

[johnRivs]

Any reason this issue is still open? We know their stance already. They know we want it, we know they make more money providing private access to the realtime API to select partners, we know they'll tell us it's available for us too they day the decide it.

If they ever respond with anything relevant, the issue could be reopened.

[mariusclaret]

Any news? @arirawr

I think she recently left Spotify. Would be interesting to know who's now in charge for this issue.

[aidenwallis]

Because it's becoming an increasing issue for a lot of people, having thousands of users all polling is causing absolute havoc, even with decreasing polling rates significantly, I don't really know how Spotify expect to have a sustainable ecosystem if they don't do the least and disclose the ratelimits in their headers so we can judge our backoff accordingly, rather than letting us go nuts till we hit it then telling us to wait.

A good example of that rate-limiting header thing I said is Twitch, you'll get extra headers telling you your total bucket amount, the amount you have remaining and the recommended request rate/s you should send.

I'm hitting rate-limits that are blocking users from even authenticating into the app, and the polls are getting ratelimited like crazy too, would be nice to see if they even added support so we could get current playing on the web playback SDK, or just allowed us to use the websocket API.

In my case, I'm sending around 6 million API requests per day for all my users on the system, not really sustainable for much longer.

It would be nice to hear back from a representative of Spotify on this thread to at least know there has been any movement on this at all, so that we're not just talking to a brick wall.

[arirawr]

Hi again folks,

Unfortunately I don't have any news to share on this issue.

We are very aware of the potential use cases that real-time events would enable, and are eager to get you a solution as soon as possible. While this is a high priority for us, there are still technical issues blocking a wider release of this functionality. When it's ready, you'll hear more from us on this thread.

Regarding rate limits, I've passed this feedback to the team.

[aidenwallis]

Good to hear it’s being worked on. In the meantime is there no way we can apply for higher rate limits to cover us for a technical limitation you guys have?

It’s hard for us to maintain our applications as passionate third party developers who want to integrate with you guys if we can’t even have something as simple as a rate-limit request form - everything is worded in a way on the documentation that were left pretty clueless about all of this. Would be nice to at least inquire about getting a rate-limit increase, which still puts more burden than holding an open socket connection would do for each user on you, but that’s my only option right now before I’m forced to close doors, which I’d rather avoid and upset thousands of users.

[aidenwallis]

Bringing this up again. Yet again you seriously need to provide developers either A: An ACTUAL way to get rate limit increases (I've needed one for over 6 months.. I mean come on...), or B, a better API so that we don';t need to poll, either way, this thread has been going on for 2 years with literally nothing. It's disheartening when developers give a toss about your app to see a company not bother to at least give us something as basic as an official email, google form, ANYTHING to keep our services alive. We are investing in you, both our time and money in services, but if you actually want to keep a sustainable third-party ecosystem something needs to be done.

I'll probably end up shutting down in a few weeks, users 90% of the time can't even connect to the app at this point because the rate-limiting is that bad.

So, from development team to another fellow development team, we deserve to at least be given something after waiting for two years, a google form, something that shows you guys care about your third-party developers in the slightest. Thank you.

[BarRaider]

+1 @aidenwallis Personally, I am following this thread but have given up a long time ago. Spotify doesn't seem to care that they're providing a poor experience for their Premium users who use 3P solutions. I have recommended to my user base to move off Spotify and use another service (which I will not name), which did provide a solution and put their customers first

[aidenwallis]

Indeed. Don't show off your third-party ecosystem if you don't want to support it. Like it's not even trivial to just give us increased rate-limits when we have large apps. It's just rude. Literally, someone at Spotify. Give us an email, google form, or something as to where we can send our apps in for an increased rate-limit and you've at least solved this issue for the time being for an awful lot of devs. If your system makes it hard to do it, not on us, but we deserve a solution now. It's been 2 years.

[WeeJeWel]

I'd actually vouch for rate limits per user per client. Makes every app scalable and is probably not harder to implement than the current limits.

[micthiesen]

I’m considering shutting down my app. My OAuth authentication requests are being throttled...

[aidenwallis]

That's literally all I need. That, or per IP since polling is done on the client side anyways! Literally problem solved. Either lock it to a token or IP, or Twitter scale based on authorized users.

Look Spotify, read these comments. These are developers who care crying out asking for you to play your part in this system.

[aidenwallis]

@micthiesen Mine do constantly, like, 90% of the time. I send 6-8 million requests per day on the default limits and have a decent number of users. So it's pretty ridiculous at this point.

[WeeJeWel]

Let's stay nice. We're talking to real humans here who cannot decide everything from themselves. Only thing we can do is propose easy solutions that don't impact their operations in a big way.