oggmux issues (with shout2send)

[JustArchi]

I took a look across recent issues that could have something to do with it and I found at least several which seem connected:

https://github.com/mopidy/mopidy/issues/1583 https://github.com/mopidy/mopidy/issues/1528

Especially last one is important. Basically I tried my best to make working Icecast 2 stream with shout2send, and I'm 100% sure that oggmux component has a lot of issues in mopidy, which could cause several other ones.

For this test I used Icecast2 with audio output taken straight from the docs:

output = audioresample ! audioconvert ! vorbisenc ! oggmux ! shout2send mount=name ip=127.0.0.1 port=8000 password=hackme

Then I started music, for example with mpc:

mpc -q clear && mpc -q add Files && mpc -q play

Initially everything works OK and nothing suggests problem - you can connect to icecast2 stream with something like VLC and everything seems to be working in order. Problem starts when you switch song or current one simply ends - no metadata is being updated.

I thought OK, this might be simply icecast issue or some misc lack of metadata being sent to Icecast, but no, things are becoming even more strange if you check mpc:

root@debian:/var/lib/mopidy/media# date
Wed, 7 Jun 2017, 06:19:07 CEST

root@debian:/var/lib/mopidy/media# mpc next
Azure&Sands - My first lover
[playing] #85/243   0:00/4:54 (0%)
volume:100%   repeat: off   random: on    single: off   consume: off

root@debian:/var/lib/mopidy/media# mpc status
Azure&Sands - SCENE1 森の中の不思議な壷 - 人食いは嘘つきの始まり
[playing] #227/243   1:57/2:56 (66%)
volume:100%   repeat: off   random: on    single: off   consume: off

root@debian:/var/lib/mopidy/media# date
Wed, 7 Jun 2017, 06:19:12 CEST

Suddenly we have song on 66% progress in just 3 seconds that lasted between my call to next and status. This is DEFINITELY not right.

Then I tried to go to previous song with mpc prev, no luck, same song is being played over and over again.

In addition to that, stream is VERY unstable, my VLC can disconnect randomly from shout2send stream just like that with no reason, I think it might be connected with https://github.com/mopidy/mopidy/issues/1306

Question is, if all of that is work-in-progress, then why simply switching to MP3 stream solves all the issues?

output = lamemp3enc ! shout2send mount=name ip=127.0.0.1 port=8000 password=hackme

I literally couldn't believe that suddenly this fixed all problems - MPC started behaving normally, my VLC no longer was dropping connection, and metadata was updated instantly on song change. It solved all my issues I was having, so definitely something has to be with above output line.

I did some tests including getting rid of audio converting/resampling, changing vorbisenc to opusenc, even using flacenc and all sort of things I could test to solve this issue - no luck, as long as oggmux is there, I'm experiencing all sort of anomalies from MPC, through VLC and ending at no metadata updates.

Could somebody please take a look into that issue? I love how excellent mopidy is, I wanted to use it for streaming opus into my icecast2 station and the moment I saw entire metadata working and even cover art being displayed I literally couldn't believe that it finally happened after I tested dozen of different clients and streaming methods. Mopidy has everything I need, I must just get that damn oggmuxer to cooperate, since I must use it as container for my opus stream.

Thank you in advance, I really hope we can deal with this, this is a deal-breaker for me. If you could kindly dedicate some of your time for my issue, I'd truly appreciate it. I felt in love with mopidy and I don't want to change it 💓 .

Mopidy 2.1.0

[JustArchi]

Side note, I reproduced it with all sort of encoders, including vorbisenc, opusenc and flacenc on Debian 9, 8 and Ubuntu 17.04 + 15.04. I can't believe nobody stumbled upon this issue previously, even playing 2 tracks is impossible, since metadata is out of sync and causing stream disconnection soon after.

I couldn't find anything interesting in debug log. No indicator of any issue. Also no issue with lamemp3enc or webmmux, so it seems that specific combination of ogg-like encoders and oggmux triggers that.

[nim65s]

Same issues here, thanks for sharing the workaround with lame :)

PS: this also removes the need for a silence file as a fallback for the icecast mount

[kingosticks]

I recently had an in-depth look at this stuff and there is indeed something strange going on in shout2send when coupled with certain demuxers. This strange behaviour depends significantly on what version of GStreamer you are using. I don't think anything has changed regarding the known issues and my quick test just now with your vorbisenc/oggmux pipe on GStreamer v1.14.4 would agree.

[Cobertos]

Same issue, I'll have to try mp3 encoding in the morning

EDIT: Yup, fixed a TON of issues by changing from the ogg pipeline to an mp3 encoded pipline