Fetching metadata through mpris sometimes returns an empty array. #503
Comments
ghost
changed the title
|
The spotify api is fetched to retrieve data related to the currently playing song. All running daemon instances share a client id, meaning that all current users probably reach the rate limit. There might be an alternative way to get the metadata through librespot, but as far as I know, there isn't one right now. A fix would be to introduce a config or env variable that users could use to set their own client_id for now. |
mainrs
added
the
bug
|
I don't think it has to do with the other bug, but I've also seen this. Didn't think there was a global client ID. In this case, the problem would be worse the more people are using spotifyd. I think, a configuration option is needed for this. |
|
After some thinking on this, just polling the API for every MPRIS request might not be a good solution at all as it won't scale very well even with multiple client IDs. |
|
I think that API is relatively new as at the time of writing that part of code librespot wasn't able to provide metadata (at least that's what I remember). |
|
Do you think this could be used? If spotifyd becomes more popular, rate limits polling the API will become more and more a problem. |
|
The rate limiting also occurs when trying to play a song with 'playerctl open "URI"'. The track is never played, journalctl shows the 'Couldn't fetch metadata from spotify: Err(RateLimited(Some(n)))' error. |
|
I'm using spotifyd with playerctl and somehow if the metadata couldn't be fetched, playerctl changes its status to stopped which is quite confusing. |
|
I think this has been fixed by #528. If anyone still encounters empty metadata when using their own client id, let me know! The fix is only on the master branch, so you guys would have to compile it yourself. |
|
Is a new release planned in the next time? |
|
I couldn't test it long enough and hoped that some people would give it a try with their own client id before I push a new release. I didn't encounter any rate limits up until now though (after around 4 hours of play time in total). |
|
I had this running with my own client id for almost 8 hours today. I didn't encounter any rate limits, however there still seem to be some issues. For the most part metadata was working fine but intermittently I got some errors: Over the course of the time I had spotifyd running I had this show up twice. |
|
I can confirm I don't get any rate limit errors anymore with latest master and own client id. |
|
Another thing I noticed is that after restarting spotifyd, querying the mpris player metatdata times out after 25s (tried with Should I create a dedicated issue for this ? |
|
I think the data should be cached while the same track is playing as currently the MPRIS metadata interface is buggy due to ratelimit from Spotify. |
|
@theel0ja I agree on this. Unfortunately I have no experience in Rust and can't help with this. |
|
I'm experiencing the same issue. I can only fetch MPRIS metadata using My |
|
Another log sample: expand |
|
As you see I linked this issue from another place, but I have something that might be interesting to check. In my case the numbers are not random, to me they look like a request rate limit that is triggered and you have to wait N seconds to be able to query: |
|
Is there any progress on this issue? I'm having the same log output as @oscarcp |
|
I'm 100% sure the rate limit error is gone if you use your own client ids, if that is what you are referring to @mtshrmn |
|
I'm using my own client id though |
|
Just to be sure, the way I should set the client id is by setting the CLIENT_ID variable, right? |
|
No, I'll close this now. I am pretty sure that this has been solved. People just need to use their own IDs. If not, please create a new issue. |
mainrs
added
the
advice
|
@sirwindfield how do I configure the secret (I don't see a |
|
@evrardjp i dont think you need the secret |
|
Hey, I have this rate limiting problem too. Sometimes Is there any workaround? I tried waiting 2 seconds between each call but it doesn't seem to work. Here's mo polybar script: zscroll -l 35 \
--delay 0.15 \
--update-check true "playerctl -p spotifyd metadata --format '{{ title }} - {{ artist }}'" &
sleep 3
waitThanks in advance! |
EDIT:
If you encounter rate limit errors, please use your own Spotify client ID by setting an environment variable named
SPOTIFYD_CLIENT_ID. You can create a client ID here.~ Sven (SirWindfield)
Hi, first of all thanks for the great work.
My status bar refreshes every 5 seconds and I'm showing the currently playing music on it. So that means in every 5 seconds I'm fetching metadata data from spotifyd with this command:
dbus-send --print-reply --type=method_call
--dest=org.mpris.MediaPlayer2.spotifyd
/org/mpris/MediaPlayer2
org.freedesktop.DBus.Properties.GetAll
string:org.mpris.MediaPlayer2.Player
But sometimes that returns either an empty array or partial data like just the title or just the artist. Example return value:
.
.
dict entry(
string "Metadata"
variant array [
]
)
.
.
When I run spotifyd with --no-daemon option, it prints this for every failed fetching attempt:
Couldn't fetch metadata from spotify: Err(RateLimited(Some(8)))
And seems like the number inside Some() decreases every second and when it is 0, I can fetch the data. As I'm guessing from its name it is some kind of a limitation. Why is this happening? Is this something that set intentionally? I don't get this kind of error with the official spotify client.
If is there a way to set this limitation to 5 seconds so that it can sync to my bar, I would really appreciate it.
I'm on kernel version 5.5.2 and using the lastest pre-compiled binary.
The text was updated successfully, but these errors were encountered: