mopidy-soundcloud
mopidy-soundcloud copied to clipboard
mopidy
All tracks cannot be streamed
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?
This is the exactly same thing happening with me. No matter which track I play, it says, track is not playable.
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.
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"}}]}
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.
Is there another way we can solve this ? Like by registering a new application with soundcloud and giving the app-id in mopidy.
If you look you'll see soundcloud app sign-ups are closed (and have been for some time)
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.
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.
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.
@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.
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!
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.
Nah. I actually bought this. It was clean, easy and cheap !
https://www.amazon.in/dp/B00YPATOEE/ref=cm_sw_r_cp_apa_fabc_1YASH50B205P72MXDJ26
On Tue, 30 Mar, 2021, 4:14 pm Tarvo R., @.***> wrote:
Thanks for the reply! What are you using now then, if I may ask? Sonos? :D
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mopidy/mopidy-soundcloud/issues/99#issuecomment-810118491, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIGT5CGS5Q3JCYN2KJ23VPLTGGTSRANCNFSM4ESJ2XMQ .
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/
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.