Just a quick observation from my own Spotify client development:

If the openspotify library uses threads to manage reading and delivering of (meta) data, it might be interesting to look into how the locking works. Data starvation, as in the connection to the Spotify server becoming slow or stalling, might make a naïve reader thread implementation very slow spending time exchanging locks with the delivery thread while polling for more data that isn't arriving.

I had exactly this problem caused by an, on the surface, innocent change of ordering of lock handling in the code.