Hi everyone, I’m using mopidy with icecast2 in xubuntu 18.04. When I configure mopidy with output = autoaudiosink it is all right and mopidy plays using PC speakers. But when I configure mopidy to output via icecast2, using the output configuration suggested into documentation, mopidy freezes the playing as a paused action with no pause event required. I try to use the same output configuration directly with gst-launch command and all it’s ok, the song is playing. Any idea about it? Thank you in advance

Could we try replacing wavenc in the snapcast example with lamemp3enc or vorbisenc. I appreciate snapcast won’t like that but will it still work sufficiently to check those two elements? I can try an install on Virtualbox but I did a full re-install when I upgraded my system so I am not sure it can be much more vanilla other than not using the develop version of Mopidy (no interesting changes there that I can see).

Interestingly, when I try this pipeline: output = audioresample ! audioconvert ! lamemp3enc ! filesink location=/tmp/snapfifo I experience the same issue that I experience with shout2send: playing status but stuck on 0:00. When I send mpc seek 1 snapcast obviously doesn’t work (it’s not compatible with mp3) but at least the mopidy playback starts, just like in the shout2send scenario. Could the issue be indeed related to changes in the GStreamer lame/ogg encoders? Debug logs of the scenario above on Arch –EDIT– Just to validate that the issue is not with tee, I have tested this pipeline too: output = tee name=t ! queue ! audioresample ! autoaudiosink t. ! queue ! audioconvert ! audio/x-raw,rate=48000,channels=2,format=S16LE ! wavenc ! filesink location=/tmp/snapfifo and this also works as expected.

I’ve been digging into the GST_DEBUG logs some more and I’m just thinking out loud here. Might be a wild goose chase… I am still not sure if this is a shout2send or encoder issue. But I do think the pipeline is way too complicated and we need a simpler testcase. It seems like in both cases everything except the sinks reaches PAUSED state as expected. Sinks can’t transition to PAUSED until the upstream pipeline has filled up and there’s a buffer queued ready and waiting on the input pad - AKA prerolling. When they get that buffer, they go PAUSED, the bin follows along with everything else. At which point everything can then quickly go PLAYING. In the working Ubuntu case, autoaudiosink0 goes PAUSED, which seems to be enough to make everything else go PAUSED despite the fact shout2send0 didn’t post it’s notification (last state-change it posted was only to READY). It seems it did actually go PAUSED, it just didn’t tell anyone - I don’t know if this is a bug or not. Once the pipeline is all PAUSED everything can then go PLAYING (and this time shout2send0 even notifies us properly). In the non-working Arch case, autoaudiosink0 goes PAUSED but then the bin doesn’t follow it this time. We get stuck instead. Maybe we are waiting for shout2send0 to send it’s notification? I guess that flushing (like what happens when you seek) would be equivalent to giving it a poke. Shout2send’s pre-rolling behaviour changed in 1.14 but I don’t know if it’s significant.

The simplest pipeline I have managed to put together to replicate the issue is the one only with one encoder and output to shout2send: output = audioresample ! lamemp3enc ! shout2send mount=/mopidy.mp3 ip=127.0.0.1 port=8000 password=hackme I have added some local changes to audio.actor.on_message so that it always traces the received state changes even when they’re not targeted to self._element and I have reconstructed the following sequence of status changes on Arch. This is instead the sequence of state transitions I see on Ubuntu 16.04, with the same pipeline working. I indeed see that the GstPlayBin goes from NULL to READY on Arch but it doesn’t move from there (even though the other elements in the pipeline go further) until I do a seek. Debug logs on Ubuntu 18.10 with the same pipeline and also affected by the issue.

So I’ve eventually found a workaround for my use case for now that works on all the systems that I’ve tested so far. I have eventually fallen back to snapcast with a wavenc pipeline instead of icecast2: output = tee name=t ! queue ! audioresample ! autoaudiosink t. ! queue ! audioconvert ! audio/x-raw,rate=48000,channels=2,format=S16LE ! wavenc ! filesink location=/tmp/snapfifo That pipeline together with snapserver listening on the fifo for now allows me to walk around the issues with icecast2. Note however that if I try to set up any other encoder than wavenc (either flacenc or vorbisenc) in that pipeline I fall back into the same issue, while wave pcm works both on Arch and Ubuntu 18.10. I really start to believe that the event chain got broken somewhere from GStreamer 1.14 but I can’t say where unless I dig into the GStreamer side too. Let me know in the meantime if I can provide you with logs for any other scenario. Btw did you manage to reproduce the issue on your system? Which pipeline are you using?

So, my working Ubuntu system uses avdec (from gstreamer1.0-libav) for decoding the mp3 whereas the broken Ubuntu system uses mpg123. I can fix the broken system by installing gstreamer1.0-libav; and break the working system by removing it. mpg123 logs a couple of the following messages which might be relevant: cannot decode yet, need more data → no output buffer to push Perhaps the manual seek operation puts enough data through the decoder that it can get going. Or maybe the seek has some other affect. So then I tried to reproduce it with gst-launch: gst-launch-1.0 playbin uri=file:///home/nick/Music/Architects/Daybreaker/The_Bitter_End.mp3 audio-sink="tee name=t ! queue ! fakesink sync=true t. ! queue ! lamemp3enc ! shout2send mount=mopidy ip=127.0.0.1 port=8000 password=hackme" Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Redistribute latency... ^Chandling interrupt. Interrupt: Stopping pipeline ... ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ... So that didn’t work out. But removing the fakesink does and it plays just fine: gst-launch-1.0 playbin uri=file:///home/nick/Music/Architects/Daybreaker/The_Bitter_End.mp3 audio-sink="tee name=t ! queue ! lamemp3enc ! shout2send mount=mopidy ip=127.0.0.1 port=8000 password=hackme" Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Redistribute latency... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock ^Chandling interrupt. Interrupt: Stopping pipeline ... Execution ended after 0:00:21.681471553 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... So I hacked the fakesink out of Mopidy’s pipeline and that worked too. I don’t think we actually need the fakesink since we don’t (currently) support dynamic outputs. So that might be a reasonable work-around. But we still need to understand why that is. @adamcik, are you around? EDIT: And for completeness: fakesink works fine along with autoaudiosink: ... audio-sink="tee name=t ! queue ! fakesink sync=true t. ! queue ! autoaudiosink" And fakesink also works fine with shout2send when gstreamer1.0-libav (avdec instead of mpg123) is installed: ... audio-sink="tee name=t ! queue ! fakesink sync=true t. ! queue ! lamemp3enc ! shout2send mount=mopidy ip=127.0.0.1 port=8000 password=hackme"

@kingosticks I can confirm that installing gst-libav on Arch or gstreamer1.0-libav on Ubuntu fixes the problem, thanks! Not only for mp3, I’ve tested it with ogg and flac as well and the problem is solved. So is the issue with the presence of the fakesink that breaks the pipeline when encoding is involved, or with internal vs. external encoder that makes the pipeline out of sync? I’m not sure yet whether this could be a regression on GStreamer or it’s just the mopidy fakesink that broke the encoding on the latest version. p.s. Interestingly, the only physical system I’ve tested where the encoding was always working was a Raspbian that already had gstreamer1.0-libav installed.

I’m still learning about Gstreamer but nothing I’ve seen would suggest there is anything wrong with the fakesink in our pipeline. To me it seems like a regression. My next step is to take the examples to the Gstreamer devs.

I have done a couple of tests with the simplest shout2cast pipeline I could come up with: output = audioresample ! audioconvert ! lamemp3enc ! shout2send mount=mopidy ip=127.0.0.1 port=8000 password=hackme Oddly, this pipeline works on all of my devices if I play local files, it breaks if I try to play a Spotify track. Some debug logs. In this debug logs I have tried a couple of sequences: Playing a local file -> works Playing a Spotify track the first time through mpc add spotify:track: works in this particular case (not always though) The following add+play experiments all fail when it comes to Spotify tracks. You can notice lots of messages like this when playback is triggered: DEBUG 2019-01-14 16:06:35,332 [2278:Dummy-15] spotify.session Audio buffer stats requested, but no listener

Mopidy is not playing with icecast2

Misc

kingosticks January 8, 2019, 12:41am 43

Yep I reproduced it with Ubuntu 18.10 running in Virtualbox. I am still looking into the logs.

Topic		Replies	Views
Help! Icecast2 no playback Misc	6	1443	May 21, 2020
Iris Icecast playback stuck in a loop (MOVED) Misc	18	1801	May 22, 2020
GStreamer Troubleshooting? Misc	7	2945	August 7, 2020
Can produce sound via gst via command line, but not through mopidy Misc	0	956	October 27, 2015
Mopidy not playing anything since last apt-get upgrade Misc	10	4723	December 21, 2015

Mopidy is not playing with icecast2

Related topics