Many CJK internet radio stations use non-unicode character set for icy title. Non-unicode characters break MPD clients.

I find it desirable to extend m3u further as follows.

```

EXTM3U

EXTINF:-1 charset=shift-jis,FM Apple Wave

http://sdfsdfsdf.com/sdfsdf

EXTINF:-1 charset=big5,FM Cat

http://fmcat.com/

EXTINF:-1 charset=cp949,FM SDFG

http://sdfg.com/radio ... ```

EPG programs use similar syntax for extra information.

• https://siptv.eu/howto/playlist.html
• https://forum.kodi.tv/showthread.php?tid=317399

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 ***

Every time mopidy starts a new song it goes forward, skip to the begin, go forward without any playback. Setting the track time seems to fix it but it is not fun to have to reopen the music tab every time a song finishes.

Newest mopidy on raspbian

Could we get a Flatpak build? It's easier to back up, can be run on any distro and distro version etc

My setup: * Raspberry Pi 1B running latest Raspbian * Analog audio out to simple desktop speakers * Latest mopidy (see config and deps below) mopidy_config.txt mopidy_deps.txt * Using mopidy-file to browse to a network share and load songs in a queue * Control through Musicbox-Webclient

Songs will randomly play at the wrong speed, usually slow. So far I've noticed fast playback with .m4a (which I may have fixed with a different decoder) but more frequently slow play back with .mp3. I'll update here if other types show the same problem now that I'm aware.

It happens somewhat randomly and it frequently fixes itself if I reset the song. It can happen at any time: the first time I use mopidy for the day, or in the middle of a queue.

This seems very similar to the issue mentioned here: https://discourse.mopidy.com/t/audio-playback-at-wrong-speed/1987

Thanks!