Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

oggmux issues (with shout2send) #1623

Open
JustArchi opened this issue Jun 7, 2017 · 4 comments
Open

oggmux issues (with shout2send) #1623

JustArchi opened this issue Jun 7, 2017 · 4 comments
Labels
A-audio Area: Audio layer C-bug Category: This is a bug

Comments

@JustArchi
Copy link

JustArchi commented Jun 7, 2017

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

#1583
#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 #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
Copy link
Author

JustArchi commented Jun 13, 2017

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
Copy link

nim65s commented Dec 21, 2017

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

nim65s pushed a commit to nim65s/nimopidy that referenced this issue Jan 2, 2018
@jodal jodal added C-bug Category: This is a bug A-audio Area: Audio layer labels Mar 31, 2018
@kingosticks
Copy link
Member

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
Copy link

Cobertos commented Apr 19, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-audio Area: Audio layer C-bug Category: This is a bug
Projects
None yet
Development

No branches or pull requests

5 participants