Okay… I have been using mopidy for quite some time. It works just like I want it. I have it running in a docker-container, and the audio gets streamed to a linux-machine using a udpskink.
What I would like to do is to extend the output. My first plan is to output to both the udpsink and an icecast-server. The problem is that I can’t make heads or tails of the output-line in the config file
Right now it looks like this:
output = tee name=t ! queue ! autoaudiosink t. ! queue ! udpsink port=5555 host=192.168.0.3
I’m not sure I can really decipher it, and this is where i need help. To me it looks like a straight “stream” here. Mopidy creates the stream named “t”, queues it into autoaudiosink and then queues it into the udpsink.
Is there a way to like…bifurcate the stream after it hits the autoaudiosink? queue one of the streams to udpsink, and another one to a icecast-pipeline?
That config option is passed straight to gstreamer so you can use their documentation. There’s a summary at Basic tutorial 10: GStreamer tools you might find useful. That pipeline looks correct to me, assuming the iceserver sink element in your distro works (Icecast — Mopidy 3.3.0 documentation)
I’m using libshout version 2.4.1, and like I said in my post, the shoutcast-portion of it works just fine, it’s the tee-thing that doesn’t seem to work. I can only get gstreamer to stream to icecast, not the udp sink.
I must have missed that in your post somewhere. I doubt there’s nothing wrong with the tee element, it works with other elements. There’s plenty wrong with the shout2send element and I’m not surprised it doesn’t work properly. I’d prefer we removed it from docs entirely but there isn’t really a replacement. I think if you try a file sink or another udp sink as a experiment the tee will work fine. I appreciate that probably doesn’t help with what you want to do.
There is gstreamer debug logging available (e.g. run with GST_DEBUG=4 mopidy) but I am not sure what’s going to jump out at you from that. What you have should work. Can you check with mopidy config that the config changes you are making each time are being picked up, sometimes it’s easy to use the wrong file.
EDIT: and to confirm, you are restarting Mopidy each time you make one of these config changes, yes?
Gstreamer seems to be version 1.14.4 in Debian 10 (Buster), which is the recommended version to run mopidy on as per the installation instructions here.
Is there a deb repo for Buster with newer binaries available?
And, yes, I’m restarting mopidy after I do changes to the configuration-file.
To clarify, Buster is not the recommended Debian version, we recommend latest stable. Buster is the minimum version we support.
The tee example we have in the docs was probably from Buster-era, all of this should have been working in Buster but I’m not going to go back and check that. Upgrading gstreamer to a newer version is hard work, I don’t know of an apt repo with a newer version for Buster but maybe it’s out there.
I guess an option is to provide a gstreamer debug log from one of the examples but I think upgrading to Bullseye would be a better option first.
Know why this isn’t working for you and generally I’m curious when things don’t work but old versions (and containers - always creating more problems than they solve) are out of scope for me. Sorry about that.
It’s a good point that we should be clearer that we recommend latest stable Debian. This is primarily to get the latest stable gst version. But as I said, I don’t know why there would be problems with tee in your old version, it’s a base element. Perhaps trying different audio sources is worth a go, sometimes bad/ugly plugins don’t behave well in complex pipelines.
Ok, I understand even less now, but here is a version of the output-line that actually does what I need it to do. Didn’t need to update mopidy, debian, gstreamer or anything
output = tee name=t t. ! queue ! autoaudiosink t. ! queue ! udpsink port=5555 host=192.168.0.3 t. ! queue ! lamemp3enc ! shout2send async=false mount=homestuff ip=127.0.0.1 port=6601 password=hackme