get tracks endpoint supports only single id now we can not pass multiple ids

[tinyscratch]

Title: Cannot retrieve all tracks using ids to get multiple track at same time

Issue found on : September 27th, 2020

Endpoint(s):

• GET /tracks/{track_id}

### Expected behaviour:
A list of tracks should return but it return only one track as the input parameter is integer We can pass only one ID, not two 

### Actual behaviour:
single track detail return (consistently)

[adithayyil]

Seems to be the input is should be single track_id so you will always return a single track.

If you want tracks from a specific user, then use GET /users/{user_id}/tracks

[tinyscratch]

No, but I want song details by passing specific IDs, like earlier. so that I can get specific song details in a single call.

[tinyscratch]

Earlier, it supported multiple song IDs. Please help me with this. I don't GET /users/{user_id}/tracks like this because it gives multiple IDs of users that are in the playlist. i don't want this.

[MariaVWSoundCloud]

The GET /tracks/{track_id} is supposed to only return the track that you requested with the id, the seen behaviour is correct.
The GET /users/{user_id}/tracks will return you all tracks of a user, nothing to do with playlists.

[tinyscratch]

@MariaVWSoundCloud but i don't want tracks of users; i want specific tracks without respect to user tracks

[adithayyil]

No, but I want song details by passing specific IDs, like earlier. so that I can get specific song details in a single call.

You can't do that with a single call. Just make multiple of those calls with the set of IDs.

[tinyscratch]

@adithayyil This will increase my number of API calls and delay my response as well. and there is a limit of 15k requests, so few users themselves do that many requests in a day. The old API response and request parameters were really useful.

[obrhoff]

The rate limit only affects playback requests.

[tinyscratch]

@obrhoff Thanks for the clarification, but what about the main issue, i.e. delay? suppose i want to fetch 15-20 IDs In that case, it will get details one by one, which definitely take more time and user will get frustrated

[mgoodfellow]

A discussion on rate limits: #225 (comment)

For your specific issue, you aren't looking at the right API endpoint. As with most RESTful API designs, /entities/{id} will return a singular entity, and /entities will return a collection of entities.

Therefore, you should be looking at the /tracks endpoint if you want to get a collection of tracks. Rather conveniently this is documented for us in the API Explorer: https://developers.soundcloud.com/docs/api/explorer/open-api#/search/get_tracks

So to take this one step further, your request will look like this:

/tracks?ids=1,2,3,4,5

To head off your next question before you ask it, I believe the limit is 50 IDs in one request, but feel free to find out for yourself!

[tinyscratch]

@mgoodfellow I already explored all the possible ways, so I raised a request.
/tracks?ids=1,2,3,4,5 If you are saying use this to get tracks, then it is not possible to pass IDs with 1, 2,3 commas separated, This was supported by the old API, but it is not currently supported. It needs a single-id integer type.

2. If you are saying to use the search/tracks endpoint, then the ID parameter is there to filter the value not to get tracks, and also the q parameter is required, i.e., the search text we have to pass. and if we keep empty q=empty, then it will return empty collection

[mgoodfellow]

/tracks?ids=1,2,3,4,5 If you are saying use this to get tracks, then it is not possible to pass IDs with 1, 2,3 commas separated, This was supported by the old API, but it is not currently supported. It needs a single-id integer type.

This is the search tracks endpoint.

If you are saying to use the search/tracks endpoint, then the ID parameter is there to filter the value not to get tracks, and also the q parameter is required, i.e., the search text we have to pass. and if we keep empty q=empty, then it will return empty collection

There is no search/tracks endpoint, its just /tracks

q is not required, you can simply pass:

https://api.soundcloud.com/tracks?linked_partitioning=true

And receive a valid result:

{
    "collection": [
        {
            "kind": "track",
            "id": 225514212,
            "created_at": "2015/09/25 12:09:05 +0000",
            "duration": 7576663,
            "commentable": true,
            "comment_count": 6947,
            "sharing": "public",

Without linked partitioning, you will just receive an array back.

In theory, providing no additional search params, means that you would be filtering the entire unrestricted data set for specific IDs, which is what you want.

However, when all this is said and done, you are correct, there does seem to be a breakage. Other parameters work, such as genre, tags, and q, and they can all be mixed and matched. The IDs param used to be able to fetch any IDs you passed in because it was filtering the entire data set (you weren't providing any other query params), but this functionality no longer works.

I wonder if it is related to: #249 ?

I haven't used this /tracks?ids=1,2,3,4 form in a while.

[tinyscratch]

https://api.soundcloud.com/tracks?linked_partitioning=true this will return tracks which we don't want, As seen in the screenshot, i want two specific tracks How do I get that? if i add ids it is returning []

[mgoodfellow]

No, I'm agreeing with you. It appears there is a breakage on this endpoint, and I linked the other issue raised regarding odd behaviour on this endpoint and I wonder if it is all related?

Most combinations of params work, but if you provide ids then you get back []. Very strange.

Sadly this doesn't give you many options to work with, other than parallelising your requests when you want a set of tracks to reduce the delay to the user as you mentioned before.

[mgoodfellow]

Hi,

Ok ready to go down the rabbit hole?

https://api.soundcloud.com/tracks?ids=193242539,69987839,77720379,66913715,340587989,51187152,60458366,65551594,54377037,32422529

There are 10 IDs in this list, (they are all my tracks), and it returns.... 9 tracks!

The last ID is missing (32422529).

Any less than 10 IDs in the request will return an empty array.

Ok, so let's add an 11th ID, 36623550:

https://api.soundcloud.com/tracks?ids=193242539,69987839,77720379,66913715,340587989,51187152,60458366,65551594,54377037,32422529,36623550

Now we have got back 10 tracks, but the same ID as before, 32422529, is still missing now in this request. I cannot tell you why this track is always missing from the collection, but it is.

So what I have got for you so far:

• Any less than 10 IDs in the request will return 0 results (empty array).
• Over 10 IDs will give you results, but for some reason which I cannot work out yet, some tracks are missing. It is deterministic, so the same track is missing each time, it isn't about ordering or positioning of the tracks in the params array.

Still, food for thought!

Hope this helps in some manner.

[tinyscratch]

@mgoodfellow This will return the same tracks every time, no matter what IDs you are passing. i am waiting for @MariaVWSoundCloud SoundCloud team has any correct way to do this.

As per new api update, the GET /tracks/{track_id} is supposed to only return the track that you requested with the single id

The GET /users/{user_id}/tracks will return all tracks of a user.

but there is no API that returns specific tracks using multiple IDs. So wait until the team doesn't give confirmation on this.

[mgoodfellow]

@tinyscratch It is returning IDs from the request:

[
    {
        "kind": "track",
        "id": 65551594,
        "created_at": "2012/10/31 19:37:10 +0000",
        "duration": 313995,
        "commentable": true,

65551594 is one of the tracks provided.

I just matched them all up and they are as expected, except that one track is missing.

So I requested 10 IDs, and received 9. All 9 of the tracks I did receive back were in the ID list I provided

[mgoodfellow]

But the most interesting and bizarre thing is that requesting < 10 IDs will always return an empty array. It definitely seems like there is a bug somewhere when the request is being handled.

This format, /tracks?id=1,2,3,4,5 has always been the correct way to search a set of tracks by ID and get back the relevant tracks. We have used it for a while. At some point it seems there has been a breakage, so it would be great to have it fixed.

[tinyscratch]

@mgoodfellow You are not sending a request correctly; it should be like this: /tracks/1 type int. This is as per the new requirement of the API, and if you will send /tracks?id=1,2,3,4,5 you will not get correct result

[mgoodfellow]

I'm happy to leave this thread and let you get on then - I've provided a whole raft of interesting proofs around strange behaviour on the search endpoint where it is almost behaving as expected. It is also the correct way, as documented, to receive/read a collection of tracks. This is the normal approach with APIs. Sadly it seems there is an issue with the ids filter specifically, where it is not behaving as documented.

I'm not talking about /tracks/{id} endpoint, as I asserted in my original response to you.

Did you run the requests I provided? No? Never mind then, I found it interesting to dig in and discover this strange behaviour around the ids filter. Thank you for the discussion nonetheless.

Don't really appreciate being told I'm not sending requests correctly, I do not find that constructive. I'm sorry that all this research I have laid out for you clearly as I can is apparently of zero value to you. I'm not sure why you keep talking about the "new" requirements of the API. I've been using it for years and the specification has not changed.

Have a great day.

[tinyscratch]

@mgoodfellow Thank you for your efforts in exploring and providing detailed information about the issue that I have raised.
I appreciate your diligence in investigating and sharing your findings.
I apologize if there was any miscommunication or misunderstanding during our conversation.

I am using this: https://api.soundcloud.com/tracks?ids=193242539,69987839,77720379 in the same way that you mention, and it was working for me. I have been using this for a long time, but there is an update to this API, so it is not working. That is what I am trying to say, or I might be wrong.

[tinyscratch]

The GET /tracks/{track_id} is supposed to only return the track that you requested with the id, the seen behaviour is correct. The GET /users/{user_id}/tracks will return you all tracks of a user, nothing to do with playlists.
@MariaVWSoundCloud

Just tell me, Ex: how to get this four-tracks [193242539,69987839,77720379] In a single call, I cannot do this in a loop because if the IDs are more, then it will take time.