I am attempting to make a request to the SoundCloud API. Then when I get the response I set the stream_url as the source of an < audio > element.
But not always... When you search for 'Bonobo' for example, you can play the first few tracks without any issue. But when you try to play 'London Grammar - Hey Now (Bonobo remix)' - the 7th result - it won't play. It throws no errors whatsoever.
I've been tinkering around with Chrome's webdev-tools and under the network tab I see the requests being made. I found that tracks that DO play have a short Request Url, like this:
And the ones that don't look like this:
Now at first glance I figured it was an encoding issue, but wrapping a quick encodeURI() around the ajax url did not work.
Furthermore I do not understand where these urls come from. In my code I am directing my ajax request towards, for example:
Thus, the request url in the GET request (as found under 'network' in Chrome's webdev tools) makes no sense to me. Is SoundCloud redirecting get requests to a CDN-host? One more thing I've noticed is that each time TWO requests are fired instead of one. The first one is always canceled and contains a 'Provisional headers are shown' warning. I believe this is because I am setting crossOrigin = "anonymous", otherwise certain browsers would not load the content.
What I guess may cause the problem is that when the url is set as the src attribute of the element an evenListener is fired in the dancer.js library, which handles the Audio Api and the playback (https://github.com/jsantell/dancer.js/). It may be that encodeURI() is required somewhere in the library.
I decided to ask the question anyhow because I don't understand how the Request Urls's above are formed and why two, instead of one, requests are being fired and why the first is always cancelled.
Any hints which my solve the playback issue are more than welcome too...
When you run the request for
you get a HTTP 302 Found response from the server, which is a URL redirect (http://en.wikipedia.org/wiki/HTTP_302). This will cause your browser to load from the new URL that the server returns, and thus the two requests you see. The server basically says "yeah, I know where to find that file, ask that guy over there".
The reason why one works and the other not, I'd think, is that https://ec-media.sndcdn.com has the Access-Control headers set while https://cf-media.sndcdn.com doesn't. This is an issue with the server configuration and unfortunately nothing you can control from the client side. Dunno if it's a deliberate move by soundcloud or if it's something you could ask them about.
©2020 All rights reserved.