Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

All tracks cannot be streamed #99

Open
thatlittlegit opened this issue Feb 25, 2018 · 17 comments
Open

All tracks cannot be streamed #99

thatlittlegit opened this issue Feb 25, 2018 · 17 comments

Comments

@thatlittlegit
Copy link

thatlittlegit commented Feb 25, 2018

I downloaded a copy of the repository and changed the version in __init__.py to 2.0.3 or something, and then installed it via setup.py. However, now when I try to play a song all I get is:

INFO     'Sucker For Pain (Suicide Squad Soundtrack) [Dariioo Trap Remix] - Imagine Dragons' can't be streamed from SoundCloud
WARNING  Track is not playable: soundcloud:song/Sucker For Pain (Suicide Squad Soundtrack) Dariioo Trap Remix - Imagine Dragons.271990006

(using that as an example)

Can anyone help, or figure out what's wrong?

@rahulonmars
Copy link

This is the exactly same thing happening with me.
No matter which track I play, it says, track is not playable.

@janLo
Copy link

janLo commented Mar 16, 2018

This happens because SoundCloud puts client based rate limits in place. Because mopidy-soundcloud uses the same client is for all installations the limit is basically constantly exceeded.

@kingosticks
Copy link
Member

For example:

{"errors":[{"meta":{"rate_limit":{"bucket":"by-client","max_nr_of_requests":15000,"time_window":"PT24H","name":"plays"},"remaining_requests":0,"reset_time":"2018/03/16 17:50:52 +0000"}}]}

@kingosticks
Copy link
Member

Also, the client_id is not actually secret so any number of other people might be out there using it. That's down to SoundCloud's stupid API design.

But actually maybe we can potentially improve things. The rate count is supposedly incremented for every request to /tracks/<id>/stream and it seems we do at least two of those for every call to translate_uri. We do one in order to determine if we are allowed to stream the track and then another to get the URL when we actually come to play it. Seems to me we could do both those things at the same time and reduce this down to a single request. Technically I don't think you are meant to cache that redirect but we could try and see.

Potentially the Gstreamer internals might request it a few more times whilst playing, I'm not sure if it caches redirects or not. But if not, maybe we'll get even more of an improvement from this.

@rahulonmars
Copy link

Is there another way we can solve this ?
Like by registering a new application with soundcloud and giving the app-id in mopidy.

@kingosticks
Copy link
Member

If you look you'll see soundcloud app sign-ups are closed (and have been for some time)

@rahulonmars
Copy link

Ohh..yeah.

@kingosticks There is another strange issue I'm facing. "No Sound". Before you go all rowdy on me, I've tried installing GStreamer 1.0, still nothing.
Any help is appreciated.

@kingosticks
Copy link
Member

Please post a full description (https://docs.mopidy.com/en/latest/troubleshooting/#show-installed-dependencies) of that separate problem at discuss.mopidy.com. Let's keep this on topic.

@thatlittlegit
Copy link
Author

thatlittlegit commented Mar 20, 2018

I don't know much about how SoundCloud or mopidy-soundcloud works behind the scenes, but I do know other desktop clients exist for SC. Perhaps we could draw information and techniques from one of them?

It just seems if they can do it, surely we can.

@janLo
Copy link

janLo commented Mar 20, 2018

@thatlittlegit If you read the comment you will see that there is not much you can do other than register your own client-id (not possible at the moment) or reach out to sc to change their rate-limit-policy from client-id-based to user-based.

kingosticks added a commit to kingosticks/mopidy-soundcloud that referenced this issue Mar 23, 2018
Combine the request for finding if stream is playable with the
request for the actual stream URI. This should help with mopidy#99.
kingosticks added a commit to kingosticks/mopidy-soundcloud that referenced this issue May 22, 2018
Combine the request for finding if stream is playable with the
request for the actual stream URI. This should help with mopidy#99.
@jodal jodal modified the milestone: v3.0 Nov 17, 2019
@Tarpsvo
Copy link

Tarpsvo commented Mar 30, 2021

Hi! Is this issue still a thing?

I'm also receiving the "Track is not playable" error when trying to play tracks from SoundCloud. However, I can search for the tracks just fine. Shouldn't searching also be denied as the API rate limit is reached? Is it the same issue?

Thanks!

@rahulonmars
Copy link

Hi! Is this issue still a thing?

I'm also receiving the "Track is not playable" error when trying to play tracks from SoundCloud. However, I can search for the tracks just fine. Shouldn't searching also be denied as the API rate limit is reached? Is it the same issue?

Thanks!

Not sure man. I stopped using mopidy because of this.

@Tarpsvo
Copy link

Tarpsvo commented Mar 30, 2021

Thanks for the reply! What are you using now then, if I may ask? Sonos? :D

@rahulonmars
Copy link

rahulonmars commented Mar 30, 2021 via email

@kingosticks
Copy link
Member

kingosticks commented Mar 30, 2021

Yes, the Soundcloud API has not changed, new API account sign-ups are still closed, and so this is still a problem. I don't think there is anything we can do, as open source software, about people re-using our client ID. It is a dick move but there are no shortage of those on the internet. If anyone has any ideas or workarounds we could try that would be helpful.

Searching does not effect the quota like hitting the "/tracks//stream" endpoint does.

@rahulonmars
Copy link

rahulonmars commented Mar 30, 2021

I actually bought this url

It was clean, easy and simple.

@Tarpsvo
Copy link

Tarpsvo commented Mar 30, 2021

Yes, the Soundcloud API has not changed, new API account sign-ups are still closed, and so this is still a problem. I don't think there is anything we can do, as open source software, about people re-using our client ID. It is a dick move but there are no shortage of those on the internet. If anyone has any ideas or workarounds we could try that would be helpful.

Searching does not effect the quota like hitting the "/tracks//stream" endpoint does.

Ah crap, that does suck. There's not much one can do about that indeed besides optimising the number of requests, but I see that's already done. I would also definitely cache the responses for an extended duration (a week or more), even if it's just in memory (and maybe re-query the streamable URLs when one of the URLs returns a 404?). If someone has the same playlist on repeat, it would avoid a lot of duplicate requests. The streamable URLs probably don't change. Other than that, not much that can be done.

@rahulonmars Oh, cool! I set up Mopidy on a dedicated machine connected to our speakers in our office so we could collaboratively edit the playlist. So remote control (from our own network) is a must have for us. :) Mopidy works like a charm as long as we stick to Spotify. SoundCloud does depend on the time of the day.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants