Temporary workaround for #300

Likely cause of this issue is libspotify getting the intial seek to early. We
have not yet had time to dig beyond this point and develop has been broken for
to long due to this. As such this work aroundly simply ignores the first seek
to position zero outright, this avoiding what is likely a race condition in
libspotify.

Next step will be to create a minimal libspotify/pyspotify test case for this
to verify that assumption and hopefully figure out a correct fix. We also need
to look into if the intial seek can be avoided in gstreamer.

mopidy/backends/spotify/playback.py

@@ -27,6 +27,10 @@ class SpotifyPlaybackProvider(base.BasePlaybackProvider):
         'width=(int)16, depth=(int)16, signed=(boolean)true, '
         'rate=(int)44100')
 
+    def __init__(self, *args, **kwargs):
+        super(SpotifyPlaybackProvider, self).__init__(*args, **kwargs)
+        self._first_seek = False
+
     def play(self, track):
         if track.uri is None:
             return False
@@ -35,6 +39,8 @@ class SpotifyPlaybackProvider(base.BasePlaybackProvider):
         seek_data_callback_bound = functools.partial(
             seek_data_callback, spotify_backend)
 
+        self._first_seek = True
+
         try:
             self.backend.spotify.session.load(
                 Link.from_string(track.uri).as_track())
@@ -59,5 +65,11 @@ class SpotifyPlaybackProvider(base.BasePlaybackProvider):
 
     def on_seek_data(self, time_position):
         logger.debug('playback.on_seek_data(%d) called', time_position)
+
+        if time_position == 0 and self._first_seek:
+            self._first_seek = False
+            logger.debug('Skipping seek due to issue #300')
+            return
+
         self.backend.spotify.buffer_timestamp = time_position * gst.MSECOND
         self.backend.spotify.session.seek(time_position)