Open blimmo opened 7 years ago
I think this is caused by the currently playing endpoint attempting to retrieve information about the track which doesn't exist for local files. However the local file object usually contains null or nothing for many fields so I would expect the currently playing endpoint to realise this and not try to request that info for the local files.
Hmm the behaviour described below is now gone, after letting the spotify client calculate whatever it was doing for more than an hour. Now I can not see any more unexpected cpu usage.
I like to add that this also adds an extreme cpu load to the spotify app, at least on my end (Kubuntu 17.04). If the spotify client plays a local file which is not available online and the server queries the playing status just once, the spotify client will just burn through a core and not recover. To reproduce:
- Use the spotify client to play a local file, which is not available online.
- Use the Web API console to query the currently playing track (Just once)
- The Spotify client will use 100% cpu (single-threaded). And even after an hour the spotify client will not be finished what ever it is is doing. Maybe that's because of the sheer number of tracks in my local Files, maybe not. Performance of the client will be drastically reduced until the user restarts his client.
I think this somewhat raises the priority of this issue, because any webapp querying the currently playing track of a user might just end up accidentally DOSing them/the spotify client.
Hi folks - local files are not supported by the Spotify Connect Web API. However, we realise that a 400 response isn't the best in this case. We're looking at handling this error better, and I'll update when that happens.
Still no plans for supporting local files in the web API? I really, really wish it would let me play local files.
Issue found on 16th April 2017
Endpoint(s):
https://api.spotify.com/v1/me/player
Scope(s):
user-read-playback-state
Steps to reproduce:
Expected behaviour:
A currently playing context as described at https://developer.spotify.com/web-api/get-information-about-the-users-current-playback/
Actual behaviour:
Error 400 with "invalid id" (consistently)