Returns wrong track ID when the same track exists in duplicate(GET v1/me/player/recently-played)

Reply

Returns wrong track ID when the same track exists in duplicate(GET v1/me/player/recently-played)

fumafuma
Casual Listener

Plan

Premium

 

Country

Japan

 

Issue

The following tracks look exactly the same, but have different IDs.

A: https://open.spotify.com/track/7MuOSVDTgILDaWQmR4iLWo?si=c6b7bae2220c4a8a

B: https://open.spotify.com/track/6sbugnLYosR8vG77QvmKZ5?si=f1ed7a238f56434a

 

If you get the ID of each track from `GET v1/tracks/{id}`, it returns the correct ID

(A: 7MuOSVDTgILDaWQmR4iLWo, B: 6sbugnLYosR8vG77QvmKZ5)

 

However, as shown in the following table, when you get recently played track from `GET v1/me/player/recently-played`, track B returns the ID of track A.

 

 v1/tracks/{id}v1/me/player/recently-played
A7MuOSVDTgILDaWQmR4iLWo7MuOSVDTgILDaWQmR4iLWo
B6sbugnLYosR8vG77QvmKZ57MuOSVDTgILDaWQmR4iLWo

 

I don't know if this is a specification or not, but I'm having trouble collecting data because it's treated as a different track.

2 Replies

nightbreak
Casual Listener

This was reported back in April 2019 on GitHub:

https://github.com/spotify/web-api/issues/1232

 

The currently-playing endpoint can also return the wrong Track URI if you include the market parameter, but seems okay if the market is not specified. I don't see Market mentioned as a parameter for recently-played so that doesn't help us here.

fumafuma
Casual Listener

Thanks for the reply.

 

I didn't know that the endpoint has the same problem.

it looks very strange.

SUGGESTED POSTS