Currently we get one seek data event per output in the tee. This can be easily verified by commenting out the dummy fakesink in the tee, or adding extra ones. The end result of this is that mopidy-spotify seeking isn't smooth, as we start playing from the seeked position and then do it again shortly afterwards.
Proper fix for this, assuming multiple outputs is still a goal is to have mopidy de-dupe this, or to do it ourselves via the new segment events getting to the tee.
The text was updated successfully, but these errors were encountered:
http://cgit.freedesktop.org/gstreamer/gstreamer/tree/docs/design/part-seeking.txt hints at the solution. I've just tested changing our code to send the seek event to the queue we have in front of the output bin. Sending it to the playbin, audio-sink bin or the outputs bin won't work as the default seek handling of a bin is to forward to all sinks. So using the queue as the spot to inject the event is the way to go.
Though this idea might not work as it only seems to play a few seconds of the next song and then goes quiet for and extend time before coming back again. :/
Currently we get one seek data event per output in the tee. This can be easily verified by commenting out the dummy fakesink in the tee, or adding extra ones. The end result of this is that mopidy-spotify seeking isn't smooth, as we start playing from the seeked position and then do it again shortly afterwards.
Proper fix for this, assuming multiple outputs is still a goal is to have mopidy de-dupe this, or to do it ourselves via the new segment events getting to the tee.
The text was updated successfully, but these errors were encountered: