Suddenly getting `GStreamer warning: Failed to connect: Connection refused`

Q&A
1

I use Mopidy with mopidy-mpd and mopidy-jellyfin. This lets me stream music through an mpd client like ncmpcpp from my Jellyfin server.

Mopidy conf (note I get the same error even with the default options under audio!): mopidy config · GitHub
Mopidy deps: Mopidy dependecies · GitHub

The setup has been working great for well over a year until the Python 3.10 upgrade, where things have fallen apart. After I rebuilt mopidy-mpd and mopidy-jellyfin manually I can no longer get Mopidy to connect to my audio, with the following error message (I also passed in GST_DEBUG=3 to get the first two additional lines):

0:00:37.258147435 11354 0x7fa3480512d0 WARN                   pulse pulsesink.c:614:gst_pulseringbuffer_open_device:<pulsesink0> error: Failed to connect: Timeout
0:00:37.258913699 11354 0x7fa3480512d0 ERROR                playbin gstplaybin2.c:5555:activate_group:<playbin0> failed to activate sinks
ERROR    2021-12-24 16:58:27,184 [11354:MainThread] mopidy.audio.gst
  GStreamer error: Failed to connect: Timeout
WARNING  2021-12-24 16:58:27,185 [11354:Audio-2 (_actor_loop)] mopidy.audio.actor
  Setting GStreamer state to GST_STATE_PLAYING failed
WARNING  2021-12-24 16:58:27,186 [11354:Core-7 (_actor_loop)] mopidy.core.tracklist
  Track is not playable: jellyfin:track:ecb4c9a12996e40aa20036c4a54d2f21

I’m on Parabola GNU/Linux-libre, which is very similar to Arch Linux. I use Pipewire and pipewire-pulse, with the configuration M0Rf30 lists in issue #1974 in the GitHub tracker (I’d link to it, but I’m not allowed to apparently).

The thing that confuses me the most is that even when I comment out my custom settings for audio and use the default

[audio]
mixer = software
mixer_volume = 
output = autoaudiosink
buffer_time =

I get the same error message. So I have no idea what’s going on.

Doing sudo netstat -tunlp | rg 8888 does return what I’d expect:

tcp        0      0 127.0.0.1:8888          0.0.0.0:*               LISTEN      899/pipewire-pulse

so the port is open.

2

Are you sure you are editing the correct config file? Please provide the entire log file.

3

And is this running as a system service or user service? Arch is not the same as debian in that respect, I’m not sure how arch configures that differently. So I guess the service status output would also be useful

4

Yes I’m sure I’m editing the correct config file.

Entire output of /var/log/mopidy/mopidy.log here: /var/log/mopidy/mopidy.log · GitHub

It’s running as a system service, status output below:

● mopidy.service - Mopidy music server
     Loaded: loaded (/usr/lib/systemd/system/mopidy.service; enabled; vendor preset: disabled)
     Active: active (running) since Wed 2021-12-29 15:48:14 GMT; 24s ago
   Main PID: 16571 (mopidy)
      Tasks: 16 (limit: 19000)
     Memory: 47.8M
        CPU: 692ms
     CGroup: /system.slice/mopidy.service
             └─16571 /usr/bin/python /usr/bin/mopidy --config /usr/share/mopidy/conf.d:/etc/mopidy/mopidy.conf
5

Try setting

“tcp:8888”

to

“tcp:127.0.0.1:8888”

Failing that, try updating as per suggestion at pulseaudio over network ends in "connection refused" due to module access starting at 0.3.41 (#1946) · Issues · PipeWire / pipewire · GitLab

I’m a bit wary that you are running Mopidy as a system service but Add documentation for running as a user service · Issue #1974 · mopidy/mopidy · GitHub is referring to user service, as apparently a system service and pipewire-pulse has issues (probably related to acl and different users).

Anything in your pipewire logs about an access issue?

Edit: that gitlab issue has a link to https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1863 which sounds like your problem.

6

I had actually tried the tcp:127.0.0.1:8888 already but that didn’t fix it.

I can confirm though that that GitLab issue is indeed my issue – running wireplumber compiled from Git fixed things. Thanks!

7

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.