Mopidy is not playing with icecast2

General
1

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

2

If you provide your mopidy deps, mopidy config and a debug log that would likely help someone trying to answer this.

3

Ok, see below.

$ mopidy deps
Executable: /usr/bin/mopidy
Platform: Linux-4.15.0-20-generic-i686-with-Ubuntu-18.04-bionic
Python: CPython 2.7.15rc1 from /usr/lib/python2.7
Mopidy: 2.1.0 from /usr/lib/python2.7/dist-packages
Mopidy-Simple-Webclient: 0.1.1 from /usr/local/lib/python2.7/dist-packages
Mopidy>=0.19.4: 2.1.0 from /usr/lib/python2.7/dist-packages
setuptools: 39.0.1 from /usr/lib/python2.7/dist-packages
GStreamer: 1.14.0.0 from /usr/lib/python2.7/dist-packages/gi
Detailed information:
Python wrapper: python-gi 3.26.1
Relevant elements:
Found:
uridecodebin
souphttpsrc
appsrc
alsasink
osssink
oss4sink
pulsesink
flump3dec
id3demux
id3v2mux
lamemp3enc
mpegaudioparse
mpg123audiodec
vorbisdec
vorbisenc
vorbisparse
oggdemux
oggmux
oggparse
flacdec
flacparse
shout2send
Not found:
mad

$ mopidy config
[core]
cache_dir = $XDG_CACHE_DIR/mopidy
config_dir = $XDG_CONFIG_DIR/mopidy
data_dir = $XDG_DATA_DIR/mopidy
max_tracklist_length = 10000
restore_state = false

[logging]
color = true
console_format = %(levelname)-8s %(message)s
debug_format = %(levelname)-8s %(asctime)s [%(process)d:%(threadName)s] %(name)s\n %(message)s
debug_file = /tmp/mopidy.log
config_file =

[audio]
mixer = software
mixer_volume = 100
output = lamemp3enc ! shout2send mount=mopidy ip=192.168.0.2 port=8000 password=hackme
buffer_time =

[proxy]
scheme =
hostname =
port =
username =
password =

[simple-webclient]
enabled = true

[mpd]
enabled = true
hostname = 0.0.0.0
port = 6600
password =
max_connections = 20
connection_timeout = 60
zeroconf = Mopidy MPD server on $hostname
command_blacklist =
listall
listallinfo
default_playlist_scheme = m3u

[http]
enabled = true
hostname = 0.0.0.0
port = 6680
static_dir =
zeroconf = Mopidy HTTP server on $hostname

[stream]
enabled = true
protocols =
http
https
mms
rtmp
rtmps
rtsp
metadata_blacklist =
timeout = 5000

[m3u]
enabled = true
base_dir = /media/elleNAS/music/Test/playlists
default_encoding = UTF-8
default_extension = .m3u
playlists_dir = /media/elleNAS/music/Test/playlists

[softwaremixer]
enabled = true

[file]
enabled = true
media_dirs =
/media/elleNAS/music/Test|music
excluded_file_extensions =
.jpg
.jpeg
show_dotfiles = false
follow_symlinks = false
metadata_timeout = 2000

[local]
enabled = true
library = json
media_dir = /media/elleNAS/music/Test
scan_timeout = 2000
scan_flush_threshold = 100
scan_follow_symlinks = false
excluded_file_extensions =
.directory
.html
.jpeg
.jpg
.log
.nfo
.png
.txt

These are mopidy log and gstreamer log:

INFO Starting Mopidy 2.1.0
INFO Loading config from builtin defaults
INFO Loading config from /home/lazzaro/.config/mopidy/mopidy.conf
INFO Loading config from command line options
INFO Enabled extensions: mpd, http, stream, m3u, simple-webclient, softwaremixer, file, local
INFO Disabled extensions: none
INFO Starting Mopidy mixer: SoftwareMixer
INFO Mixer volume set to 100
INFO Starting Mopidy audio
INFO Starting Mopidy backends: StreamBackend, M3UBackend, FileBackend, LocalBackend
INFO Loaded 1 local tracks using json
INFO Audio output set to “lamemp3enc ! shout2send mount=mopidy ip=192.168.0.2 port=8000 password=hackme”
INFO Starting Mopidy core
INFO Starting Mopidy frontends: MpdFrontend, HttpFrontend
INFO MPD server running at [::ffff:0.0.0.0]:6600
INFO Starting GLib mainloop
INFO HTTP server running at [::ffff:0.0.0.0]:6680
INFO New MPD connection from [::ffff:127.0.0.1]:57630

0:00:13.113777064 3374 0x14f5140 WARN
basesrc gstbasesrc.c:3583:gst_base_src_start_complete: pad not activated yet
0:00:13.120721754 3374 0x14f5140 WARN
basesrc gstbasesrc.c:3583:gst_base_src_start_complete: pad not activated yet
0:00:13.235278420 3374 0x1009a60 WARN audio-resampler audio-resampler.c:274:convert_taps_gint16_c: can’t find exact taps

4

Please provide full logs. For Mopidy it needs to be a a debug log - https://docs.mopidy.com/en/latest/troubleshooting/#debug-logging

5

Ok.
The Mopidy debug log is here
The Gstreamer log is here

6

Just an update:
I’m using ncmpc as client and I noted that the selected song remains in “playing” status, with play time fixed to zero, and no sound via icecast2 server. But, in this situation always using ncmpc, if I hit “f” key (that is seek forward in playing song) then the play time starts and also the sound is available via icecast2. A bit strange …
Can anyone help me to understand what is the problem?
Thank you in advance

7

Same problem. Maybe write as issue on the github?

8

Any solution to this? I seem to have the same issue.

I have multiple MPD instances that shouts to the same local Icecast server, and I can stream from the perfectly. But I cant get Mopidy to work with my Icecast2 server :frowning: I get 404 when I try to setup mount.

It does not mount to Icecast as far as I can tell.

9

@germain, does that really sound like the same problem as described in the original post? Yours sounds more fundamental. Note that you can test a generic gstreamer shoutcast setup with:

gst-launch-1.0 audiotestsrc ! audioresample ! lamemp3enc ! shout2send mount=/mopidy ip=<SERVER_IP> port=<PORT> password=<PASSWORD>

Unless this really is the same problem, please start a new thread for further debugging. If you can’t get the above gst-launch example to work you might find better help at #icecast.

10

That line works for me on my Icecast.

I think my issue is the same because when I press play , it says playing in ncmpcpp but the time is always at 0.

This is a pc where I do not have direct access so I cant test the actual sound card, but I am able to forward the sound via pulseaudio, and mopidy can play to remote pulseaudio. So this is something about mopidy not liking the provided lines for output.

11

I’m having the exact same issue. Did you ever figure this out?

12

No I did not, I think Mopidy has issues with Icecast, I have seen other people complaint about the same issue on other forums like Reddit selfhosters.

13

I can confirm that the issue is still occurring in my case as well. It’s strange because I used to use a mopidy+icecast without any issues until some months ago.

My setup used to dispatch the audio both to the normal audiosink and iceacast.

If I test it through gst-launch-1.0:

gst-launch-1.0 audiotestsrc ! tee name=t ! queue ! audioresample ! autoaudiosink t. ! queue ! lamemp3enc ! shout2send mount=mopidy ip=127.0.0.1 port=8000 password=hackme

it works flawlessly - I can both hear the sound out of the speakers and I can attach to the Icecast stream through any player.

However if I try to use the same configuration in mopidy.conf:

[audio]
output = tee name=t ! queue ! audioresample ! autoaudiosink t. ! queue ! lamemp3enc ! shout2send mount=mopidy ip=127.0.0.1 port=8000 password=hackme

it doesn’t work anymore. The playback remains stuck at 0:00, no output from the speakers, no Icecast mountpoint is even created.

14

Is there any plan to investigate/confirm the issue or any fix ETA?

16

I see you’ve since removed your post but there were some good points (as well as some I’m not going to comment on). So I am going to reply anyway and hopefully it still makes sense. It does partly answer your question too. These are my views, all/any of which are not necessarily shared by the other @Mopidy developers.

There are hopefully no barriers to anyone stepping up and helping to maintain Mopidy other than to provide interest in doing so. Historically people who have made a number of contributions over some time are invited to join the Mopidy organisation on GitHub but you don’t need that write access in order to make valuable contributions. We generally wait before inviting to try and work out if the person is: a) going to stick around, and b) cares. I believe FOSS maintainers have an obligation to users (one of very few actual obligations) to not give random people write access to project repositories like this; there does need to be some sort of vetting process.

But maybe more importantly, most OSS projects require help from users beyond just reporting bugs. Such as confirming bugs, working on fixes, and reviewing fixes. Everyone has the code and not being a “maintainer” doesn’t prevent anyone from doing that stuff. But I do of course appreciate that activate maintainers are needed in order to merge those fixes.

Documentation is a relatively easy contribution with immediate value that almost anyone can make. It’s also usually quick and easy to review; a win for everyone involved. Actual icecast users are in the best position to make documentation changes regarding icecast. So please submit your documentation PR and I will do my very best to review it.

Now, I’ve personally never used icecast and have no interest in it. If I had time to invest, I’d invest it in providing proper HTTP output streaming. I don’t think any of the currently active @mopidy developers actively use icecast. Maintaining support for integrations that you do not use is always a problem. If we want to make it work and keep it that way it sounds like we need a user/users from the community to take a more proactive role. Maybe that person will provide you with the things you demanded.

On to the actual issue:

The breakage might be due to Gstreamer v1.14 that’s in the latest Ubuntu 18.04 and Debian Buster. That brought changes to shout2send as well as lots of other moving parts. Perhaps our pipeline is incompatible with something there. @blacklight what is the output of your mopidys deps i.e. do you have v1.14? If someone with the issue could try running an older version of Gstreamer that would help…

I’ve also seen a few reports of a race condition when changing songs and this might be related to that. Again, that might be something to do with v1.14 but that’s also currently unknown.

17

@kingosticks thanks for your reply.

I’d be happy to provide my contribution if needed, as I did with the mopidy-spotify playlists issue already, but I can’t contribute with bug analysis and code for everything - everybody has time constraints. And I’d also expect a bit more proactiveness from the maintainers. Having to wait 6 months or more for a fix (or even an analysis) for an issue with the Spotify playlists (which hasn’t been fixed yet btw), or with icecast streaming, are the kind of things that might lead users to be frustrated, stop using a product altogether, look for alternatives, or worse forking it into their own version (something I’ve already been tempted to do with mopidy), and that’s eventually bad for FOSS and for the project itself.

When it comes to icecast integration, I understand that you and the other mopidy developers may have no interest in using icecast. But such integration is officially supported and documented here: if it’s no longer working and you’ve got no interest in fixing it, maybe it’d be worth to mark that page as deprecated, or at least mention that it’s broken and either provide an ETA for the fix or just mention that it’s no longer supported.

And if you opt for deprecating it in favour of native HTTP stream support, it’d still be worth to provide a timeline for that to be ready, because in the meantime users will just end up with no support for a feature (streaming) that is quite important for some of them and has been present in mopidy for a while.

When it comes to the actual issue, I confirm that I’m using GStreamer >= 1.14 (1.14.4.0). And the issue might indeed be related to the version upgrade because I remember that streaming through icecast use to work April/May. Downgrading might be an option, but not a viable option for me - I’ve got multiple packages relying on GStreamer and on Arch Linux doing partial upgrades/downgrades is the perfect recipe for breaking things.

Do you have any suggestions on how to pinpoint the actual issue? I don’t know much about the streaming part of the mopidy codebase.

18

You could try running Mopidy and older version of gstreamer in a container. Grab an old Ubuntu root filesystem and run it inside systemd-nspawn container (or Docker or whatever).

I don’t recall anything special in Mopidy when talking to shout2send so you could try comparing a debug log when starting to play a song using alsasink with using shout2send. Maybe script up some mpd commands so it’s as similar as possible (in terms of timing) in both cases.

19

I have managed to replicate the scenario without and with the issue through an old VirtualBox Ubuntu image.

Debug logs with the issue
Debug logs without the issue

Scenario with the issue:

  • Arch Linux
  • mopidy 2.2.2
  • icecast 2.4.3
  • GStreamer 1.14.4

Scenario without the issue:

  • Ubuntu 16.04
  • mopidy 2.0.0
  • icecast 2.4.2
  • GStreamer 1.8.3

I have tested both the cases with the same GStreamer pipeline:

[audio]
output = tee name=t ! queue ! audioresample ! autoaudiosink t. ! queue ! lamemp3enc ! 
shout2send mount=mopidy ip=127.0.0.1 port=8000 password=hackme

And both by playing a SoundCloud URI through mpc.

On the Ubuntu system I can hear the music through the device and connect to the Icecast mountpoint through VLC as well, on the recent Arch Linux installation neither of the two works.

What I have noticed is that the older installation has the following traces after the Got BUFFERING bus message lines:

DEBUG    2018-12-31 01:14:00,765 [12523:MainThread] mopidy.audio.gst
Got STATE_CHANGED bus message: old=GST_STATE_PAUSED new=GST_STATE_PLAYING pending=GST_STATE_VOID_PENDING

while instead the newer installation seems to get stuck at

Got BUFFERING bus message: percent=100%

without getting the state change event.

Actually the newer installation only reports:

Got STATE_CHANGED bus message: old=GST_STATE_NULL new=GST_STATE_READY pending=GST_STATE_VOID_PENDING

without getting to the READY->PAUSED nor to the PAUSED->PLAYING transition:

Got STATE_CHANGED bus message: old=GST_STATE_READY new=GST_STATE_PAUSED pending=GST_STATE_VOID_PENDING

so I guess something got lost in translation between mopidy and GStreamer with one of the last updates of either.

20

Please let me know if more information/logs are needed to pinpoint the issue.

21

Thanks for that thorough analysis. Can you just clarify what happens if you are not using icecast? I.e.

output = autoaudiosink