Use case:
- stream a radio station using tunin plugin
- select another station
Observed behaviour:
- the current stream stops
- Sometimes (mostly on the first change after start playing) the current sender is played again
- even though, the new sender is shown
Environment:
- PI Zero (single core @ 700-1000Mhz)
- Boot strapped minimal rasphian
- software:
Python: CPython 2.7.15 from /usr/lib/python2.7
Mopidy: 2.1.0 from /usr/lib/python2.7/dist-packages
Mopidy-MPRIS: 1.4.0 from /usr/lib/python2.7/dist-packages
Mopidy-Mobile: 1.8.3 from /usr/local/lib/python2.7/dist-packages
setuptools: 39.2.0 from /usr/lib/python2.7/dist-packages
Mopidy>=0.19: 2.1.0 from /usr/lib/python2.7/dist-packages
Mopidy-TuneIn: 0.4.1 from /usr/lib/python2.7/dist-packages
GStreamer: 1.14.2.0 from /usr/lib/python2.7/dist-packages/gi
Analysis:
- for changing the sender, mopidy is putting the playbin from state PLAYING into READY (prepare_change()) first
- in the use case described above, the gstreamer pipeline emits a buffering signal with 0%
- this signal leads to mopidy changing back the playbin state into PAUSED again
- this confuses the state machine and mopidy-tunin trying to unwrap the next song and setting the url in the background
- depending on how fast tunin is, mopidy starts playing again before the new url is set leading to the old one played
(commented logs attached)
Proposed Fix (that works in my use cases):
- change in function onbufferingevent() in audio/actor.py line
"if percent < 10 and not self.audio.buffering :"
to
"if percent < 10 and not self.audio.buffering and self.audio.target_state == Gst.State.PLAYING:"
The fix works for my use cases but I'm not sure about side effects since I'm not really sure about potential other states in which the playbin shall be paused.
In any way, I got a hint from the maintainer of rygel that changing states based on the onbuffering signal is not a good idea at all. See here: https://bugzilla.gnome.org/showbug.cgi?id=720836
*** attachment following in a minute ***