MPRIS takes a very long time to respond back to, or is not done internally

[apprehensions]

Description D-Bus MPRIS of spotifyd, when requested information by clients, will take a very long time to respond back to.

from the looks of it, spotifyd is CONSTANTLY sending spotify API calls. which i find weird as they can be done internally..

for example, i have a little dockapp called wmusic that retrieves this data. when used along with the official Spotify client it works flawlessly. however, when used with spotifyd, it becomes extremely slow. this is also apparent when attempting to fetch metadata with playerctl; which takes 5 seconds, when using the official Spotify client, it takes 100ms.

Why is spotifyd constantly sending requests to the Spotify API instead of just retrieving the current playing song name internally via some arbitrary struct?

Compilation flags

• [X] dbus_mpris
• [ ] dbus_keyring
• [x] alsa_backend
• [ ] portaudio_backend
• [ ] pulseaudio_backend
• [ ] rodio_backend

Versions (please complete the following information):

• Spotifyd: spotifyd 0.3.4

[eladyn]

Thank you for the report. I assume this is a duplicate of https://github.com/spotifyd/spotifyd/issues/891?

To answer your question, though: In the used version of librespot, unfortunately, nearly none of the metadata that is in theory available to librespot is passed down to spotifyd or accessible in any reasonable way. So we don't really have a different option than sending out those API requests. As such, we have to send some requests, but (depending on the MPRIS clients) most of them are indeed still unnecessary. Some examples:

• After the playback switched to a new track, spotifyd makes an API call to get the metadata of the current song to send out the PropertiesChanged event. But on every subsequent request of the metadata (using Properties.Get), spotifyd requests the information freshly from the server, which is – of course – a massive waste of resources. (What we should do is cache this information locally and answer with that.)
• Methods like Properties.GetAll which are e.g. used by playerctl are handled by the D-Bus framework and call the .Get function of every single property, which in turn results in many API requests (and most of them are redundant at the same time.)
• spotifyd kind of knows in which state it is, at least it could store that information. Currently, it has to ask the Spotify Web API, if it's playing something. :)

While I'm aware of all these issues and sort of know how to fix them, I haven't got around to doing it. I'm also currently not sure, if it might be worth doing that with an upcoming major port to librespot 0.5.0 as soon as it's released. There is going to be quite some great stuff coming with this release that will solve almost all our problems and might almost entirely replace the Web API. So I'm not sure if it's better to rewrite the D-Bus module now, considering that we might have to rewrite it completely anyway for the librespot upgrade.

All that is completely hypothetical, though, since I won't have the time in the next month or so to tackle any bigger tasks. If someone else would like to step forward and take care of it, that would of course be great as well!