Rate limit is per-application, not per Access Token

[Drizzt321]

On going issue, rate limit is per-application key, not per user access token

Endpoint(s):

All playback endpoints

Scope(s):

I'm using Mopidy as a server-based playback of audio to feed into Snapcast for multi-room audio setup. Works great! Except the SoundCloud Extension has the rate limit shared across everybody using the extension. Not each individual person's Access Token.

Steps to reproduce:

Given that the rate limit is across all users, it's somewhat random when the rate limit hits, but the more users there are, the more frequently it gets hit. And currently I can't get my own 'application' in order to get my own individual rate limit

Expected behaviour:

Be able to consistently use SoundCloud (yes, I do pay for it) via a 3rd party use of the API in order to integrate well into my multi-room audio setup. In other words, rate limit per-user, not per-application.

Actual behaviour:

Randomly getting rate limited, not knowing when it would occur.

[rahul-sc]

Hey @Drizzt321

This is not a bug and by design.
https://developers.soundcloud.com/docs/api/rate-limits#play-requests

A few questions to consider this as a feature request

• Why exactly do you use Mopidy to stream music from SoundCloud API? Is this because SnapCast has a default integration with Mopidy and what you're looking to use is actually Snapcast? Interested in learning more about this
• New application creation is only reserved for application developers - are you building your own app on top of Mopidy/Snapcast?
• If this shared client_id is from Mopidy, you can certain request them to reach out to us to explore a deeper integration with us. Happy to dig deeper

[Drizzt321]

@rahul-sc

Why is the rate-limiting per client_id? That seems like a low limit for applications, especially if they get to be popular. Your link also has no information as to how applications can request high limits.

And new application creation...well, you haven't opened it up in years from what I understand, which is inane and probably prevents many new applications from experimenting and possibly competing with your own desktop/browser/mobile applications.

So both are F/OSS in the audio area, but they have a bit of different focus. Both of them are linked above, which you're welcome to look through, including the source code.

Snapcast is a multi-room audio setup, and can have it's audio source from different spots. It's job is about distributing sound sources out to the clients, and can apply a per-client latency setting to get the audio to be synced up. It's slightly like jackd/pulse, but the outputs are different machines, generally in different rooms.

Mopidy is an MPD-like audio player. It's basic design is to be an extensible audio player, controllable from any MPD client, although having more features. Can play from local files, or various other audio sources. Such as using Shairport-sync to act as an AirPlay endpoint. Has numerous extensions for net-radio stations, Spotify, and yes, SoundCloud.

Mopidy let's me play audio from the server (my NAS), and then send it out to whichever speakers I want, mix-and-match. Controllable from my phone, but not using my phone, so it doesn't end up draining the battery.

For the Mopidy client_id, how would they go about requesting an increase in the rate limit? I'd love to be able to get them the info, or go ahead and reach out on their Github, https://github.com/mopidy/mopidy-soundcloud

[rahul-sc]

Why is the rate-limiting per client_id? That seems like a low limit for applications, especially if they get to be popular.

Licensing terms from rightsholders

Your link also has no information as to how applications can request high limits.

This is intentional and also constrained by licensing terms here. Although we're revising / exploring to consider a per-user limit than per-app for some use cases. I recommend watching this thread for update.

And new application creation...well, you haven't opened it up in years from what I understand, which is inane and probably prevents many new applications from experimenting and possibly competing with your own desktop/browser/mobile applications.

We're working towards reopening - hopefully we're able to do this soon.

Thanks for the explanation of Snapcast & Mopidy. Really interesting products both of them.

[Drizzt321]

@rahul-sc
Hm, that's interesting to hear about the licensing. Not sure why they put that in, after all you still track the plays and everything based off of the API requests and such...but yeah. I guess I get it. Hate it, but get it.

For the Mopidy extension, reach right out to them. Or should I have them reach out to you here about figuring something out for higher rate limit?

[Drizzt321]

@rahul-sc So, should I have the Mopidy folks reach out to you here, on this ticket? Or how else can they go about contacting SoundCloud to possibly get an increase in rate limit or more functionality?

[kingosticks]

If this shared client_id is from Mopidy, you can certain request them to reach out to us to explore a deeper integration with us. Happy to dig deeper

We at Mopidy would love to get this fixed, it has been a mess for years despite our best efforts. If you are serious @rahul-sc then please tell us what to do. It's great to see some there are still developers at Soundcloud!

EDIT: Can we solve this by getting access to the v2 API?

[Drizzt321]

@rahul-sc Any update on this? Would be AMAZING to get this solved for Mopidy, so I can let my home server do the work and not run down my cell phone battery having to stream from the internet, and then push up via AirPlay.

[Drizzt321]

@rahul-sc So, I see there's been no movement on this, at least here. Anyone at SoundCloud want to try and kick this into gear to solve this for F/OSS clients like Mopidy and the like?

[kingosticks]

@rahul-sc we (Mopidy) would love to get this sorted. Can we talk?

[MariaVWSoundCloud]

Hi there, you can get in touch with us by opening a support request. I will let the team know to route the ticket to me and we can certainly have a call to see how we can work together better! Best regards, Maria

[kingosticks]

Hi @MariaVWSoundCloud I submitted a support request last week after reading this topic, I have not heard anything back. Could you also look at mine (ticket number 2558749)?

[MariaVWSoundCloud]

@kingosticks Today we (SoundCloud) talked to @Drizzt321 and we would like to discuss this further with you to see what we can do around the rate limit. Can I kindly ask you to get in touch with our support - they will forward you to me/us and we can talk.