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

Soundcloud URLs that end with a slash cannot be parsed correctly #412

Closed
Scrxtchy opened this issue Oct 15, 2020 · 3 comments · Fixed by #414
Closed

Soundcloud URLs that end with a slash cannot be parsed correctly #412

Scrxtchy opened this issue Oct 15, 2020 · 3 comments · Fixed by #414

Comments

@Scrxtchy
Copy link
Contributor

While testing other issues, I noticed this weird one. I'm under the assumption that soundcloud don't support these completely.
While I can easily substring out the URL from the address when resolving the EmbedPlayer retrieval, that only fixes the error regarding being unable to resolve the ID of the song. Comments will still load, but the stream is marked as unavailable.

I've spent a little amount of time looking into this as it would affect more extraction cleanliness in #410, but I'm having a really troublesome time with breakpoints within Android Studio that this has become quite a nuisance

Reference URLs for testing:
https://soundcloud.com/android52/future-type
https://soundcloud.com/android52/future-type/

@Scrxtchy
Copy link
Contributor Author

An explanation behind this kind of behaviour is that the embedplayer returns different data based on the existence of the tailing slash
image
Functionally they both work, but this would, under an assumption be due to one relying more on javascript

@Scrxtchy
Copy link
Contributor Author

I believe the problem does also lie in here, as the API actually does not like slashes on the end either

public static JsonObject resolveFor(Downloader downloader, String url) throws IOException, ExtractionException {
String apiUrl = "https://api-v2.soundcloud.com/resolve"
+ "?url=" + URLEncoder.encode(url, "UTF-8")
+ "&client_id=" + clientId();

removing the %2F from the encoded url gave a favourable api result, otherwise they just return a empty json object

@Scrxtchy
Copy link
Contributor Author

This also tied into this line, since when I alter the url, we are still fetching the page based on the original url in

Scrxtchy added a commit to Scrxtchy/NewPipeExtractor that referenced this issue Oct 16, 2020
@TobiGr TobiGr linked a pull request Oct 16, 2020 that will close this issue
3 tasks
Scrxtchy added a commit to Scrxtchy/NewPipeExtractor that referenced this issue Oct 16, 2020
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

Successfully merging a pull request may close this issue.

1 participant