mopidy
Slowdown of initial request to websocket
When mopidy-spotify is enabled the first HTTP request to /mopidy/ws takes around 30 seconds (sometimes also a bit less than 30 seconds - e.g. 28786 ms) on Raspberry Pi (original/first) Model B. Most likely this slowdown is less noticeable on more powerful hardware.
The CPU usage of mopidy process is around 95% during the slow request.
There is nothing logged in mopidy.log during the slowdown (except the request itself at the end of slowdown).
Slowdown also happens when initial request to /mopidy/ws is a simple GET instead of proper websocket connection.
When mopidy-spotify is disabled (by setting enabled = false under [spotify] in mopidy.conf) the first request to /mopidy/ws takes around 1 - 1.5 seconds.
Subsequent requests to /mopidy/ws take around 10 ms (0.01 second) on server side in both cases.
Versions (pip list | grep -i mopidy):
Mopidy (2.1.0)
Mopidy-AlarmClock (0.1.6)
Mopidy-Dirble (1.3.0)
Mopidy-Mobile (1.8.2)
Mopidy-Moped (0.7.1)
Mopidy-MusicBox-Webclient (2.4.0)
Mopidy-PlaybackDefaults (0.1.1)
Mopidy-Simple-Webclient (0.1.1)
Mopidy-SoundCloud (2.0.2)
Mopidy-Spotify (3.1.0)
Mopidy-Spotify-Tunigo (1.0.0)
Mopidy-TuneIn (0.4.1)
Mopidy-WebSettings (0.1.4.2)
Mopidy-Youtube (2.0.2)
OS - Raspbian Jessie.
One quick experiment would be to comment out / remove all the deprecated properties such as PlaylistsController.playlists and see if that makes any difference.
I doubt this is mopidy-spotify issue. We have known problem with how mopidy itself and pykka interact where creating the initial actor accesses all properties on the core APIs and/or backends. Which triggers playlist lookups of all your playlists, so likely that is to blame.
If you try running with a return [] instead of the code in https://github.com/mopidy/mopidy/blob/develop/mopidy/core/playlists.py#L107 it should be fast, assuming this is what I think it is.
Don't remember what bug in mopidy covers this, but we plan to remove this in the next major release to rectify the API.
The return [] workaround as @adamcik suggested resolved the startup time issue.
Is it planned to implement some kind of fix/workaround for this bug? Or it will be fixed in Mopidy 3.x by removal of the get_playlists() API?
They are ultimately the same work-around. It will be fixed as part of Mopidy 3.x when we are able to remove deprecated Core APIs, for this issue in particular, removal of PlaylistsController.playlists (more info) is the key.