threading.Event's wait method returns None on python pre 2.7, which means all
searches would fail. This also corrects that fact that we weren't clearing the
connected threading event on disconnects. I did not add any tests for this at
this time as I just want to get the fix out.
This makes track lookup behave consistently with lookup of artists, albums and
playlists. I consider this "safe", since track lookup is only used for lookup
of single tracks by URI. If you're e.g. loading a playlist full of unloaded
tracks, you should still use SpotifyTrack to avoid blocking on track loading.
This adds support for loading tag caches where the "file:" field has urlencoded
paths. For old tag caches without the urlencoding, this is a noop. Thus, old
tag caches continues to work.
Pyspotify now creates the session in
`pyspotify.SpotifySessionManager.__init__` (rather than in `.connect`) -
see [here][1]. Therefore it seems best not to set `self.session = None`
in `mopidy.SpotifySessionManager.__init__` or `self.session = session`
in `logged_in`.
[1]: 483f757430 (L1R39)
This adds a module-level cache of artist, album, and track models, whose
content is almost entirely static. This cache is used when we convert from
pyspotify to Mopidy objects.
Previously, an album with 15 tracks would create 15 track objects, 15 artists
objects on the tracks, 15 album objects on the tracks, and 15 artist objects on
the 15 album objects, in total 60 objects. With this change, we only create 15
track objects, 1 album object, and 1 artist object, in total 17 objects.
Measurements with 90 playlists containing about 6500 tracks in total shows that
this reduces the number of Artist objects from 13600 to 3800, and the number of
Album objects from 6500 to 4500 objects.
An unscientific measurement of memory usage using ps(1) indicated a reduction
in RSS from 71MB to 65MB, measured right after the Spotify playlists was loaded
the first time.
