Help with UPnP / Mopidy-MPD / upmpdcli

General
1

Dear community!

First of all, thanks for everyone involved in making Mopidy the great thing it is. It has really improved the way I handle music on my computer and is in general an awesome project!

I’m having some trouble with UPnP that I really can’t seem to be able to resolve myself after a couple of days of trial and error, and would really appreciate some help, since I feel like I’m completely stuck now.

My goal is to be able to stream my Desktop ( Ubuntu 18.04 ) sounds to my Raspberry Pi ( Raspbian Buster ), running Mopidy.

To achieve this, I followed the instructions on [1] and installed upmpdcli on my Raspberry PI ( sudo apt install upmpdcli ), and made it run as as service ( sudo service upmpdcli start )

On the Desktop-side, I went about installing pulseaudio-DLNA [2], which I’m running as an application for now with ( pulseaudio-DLNA ).

And finally, to have something to test things on the side with, I installed BubbleUPnP on my two Android devices and see how they behave as well.

Now, after two days of trial and error, I’m able to pass and receive audio through UPnP various ways, but the main path ( Desktop → Raspberry ) is still not working.

Currently, from my Desktop, I’m able to pass on audio to both of my Android devices:
Desktop → Android 1
Desktop → Android 2
Suggesting that pulseaudio-DLNA seems to be somewhat working.

On the Android-side of things, I’m able to send audio between the Androids, AS WELL AS, to Raspberry:
Android 1 → Android 2
Android 2 → Android 1
Android 1 → Raspberry
Android 2 → Raspberry
Suggesting that the Android side seems to be fully functional, and the Raspberry receiving-side is also functional to some extent.

The problem is, that the most important path ( Desktop → Raspberry ) is, for some reason I can’t figure out, not working. When I try to connect my Desktop audio to the Raspberry ( the same way I connect it to the Androids ), it tries to connect for a couple of seconds, after which the stream returns to the Desktop built-in speakers. At no point, there’s audio pass through…

Would anyone know where to start troubleshooting? I’m quite confused since my tests would suggest the needed receiving/sending protocols are somewhat working, except for this specific pair.

[1] UPnP — Mopidy 3.4.2 documentation
[2] GitHub - masmu/pulseaudio-dlna: A lightweight streaming server which brings DLNA / UPNP and Chromecast support to PulseAudio and Linux

Logs

This is how pulseaudio-DLNA looks like when connecting to a working stream:

13:55:01 pulseaudio_dlna.pulseaudio INFO on_device_updated “/org/pulseaudio/core1/sink4”
03-06 13:55:02 pulseaudio_dlna.pulseaudio INFO _async_handle_sink_update /org/pulseaudio/core1/sink4
03-06 13:55:02 pulseaudio_dlna.pulseaudio INFO Instructing the device “BubbleUPnP (AGS2-W09) (DLNA)” to play …
03-06 13:55:03 pulseaudio_dlna.plugins.upnp.renderer INFO Device state is stopped. Sending play command.
03-06 13:55:03 pulseaudio_dlna.pulseaudio INFO The device “BubbleUPnP (AGS2-W09) (DLNA)” is playing.
03-06 13:55:03 pulseaudio_dlna.pulseaudio INFO _async_handle_sink_update /org/pulseaudio/core1/sink4 finished!
03-06 13:55:03 pulseaudio_dlna.streamserver INFO URL settings: /dWRuPSJ1dWlkOjk2Y2NkMjFjLTYzMTEtNDg1Mi1iZThjLWRjYjkwMzE5OTlhOCIsdHlwZT0iYnJpZGdlIg%3D%3D/stream.mp3 (udn=“uuid:96ccd21c-6311-4852-be8c-dcb9031999a8”,type=“bridge”)
03-06 13:55:03 pulseaudio_dlna.streamserver INFO Registered stream “/dWRuPSJ1dWlkOjk2Y2NkMjFjLTYzMTEtNDg1Mi1iZThjLWRjYjkwMzE5OTlhOCIsdHlwZT0iYnJpZGdlIg%3D%3D/stream.mp3” (0x7fcc7bb85510) …
03-06 13:55:03 pulseaudio_dlna.streamserver INFO Starting processes “parec --format=s16le -d bubbleupnpags2w09_dlna.monitor | lame -b 192 -r -”
03-06 13:55:03 pulseaudio_dlna.streamserver INFO Processes of /dWRuPSJ1dWlkOjk2Y2NkMjFjLTYzMTEtNDg1Mi1iZThjLWRjYjkwMzE5OTlhOCIsdHlwZT0iYnJpZGdlIg%3D%3D/stream.mp3 initialized …

After which, the stream is working as it should.

Here’s the log when trying to connect to the raspberry:

03-06 14:03:46 pulseaudio_dlna.pulseaudio INFO on_device_updated “/org/pulseaudio/core1/sink3”
03-06 14:03:47 pulseaudio_dlna.pulseaudio INFO _async_handle_sink_update /org/pulseaudio/core1/sink3
03-06 14:03:47 pulseaudio_dlna.pulseaudio INFO Instructing the device “UpMpd RASPI (DLNA)” to play …
03-06 14:03:47 pulseaudio_dlna.streamserver INFO URL settings: /dWRuPSJ1dWlkOmVlOGZmNzM3LWJiY2EtMmFkYy0xNGRjLWI4MjdlYjM2YzhmMSIsdHlwZT0iYnJpZGdlIg%3D%3D/stream.mp3 (udn=“uuid:ee8ff737-bbca-2adc-14dc-b827eb36c8f1”,type=“bridge”)
03-06 14:03:47 pulseaudio_dlna.streamserver INFO Registered stream “/dWRuPSJ1dWlkOmVlOGZmNzM3LWJiY2EtMmFkYy0xNGRjLWI4MjdlYjM2YzhmMSIsdHlwZT0iYnJpZGdlIg%3D%3D/stream.mp3” (0x7fcc7bb92ed0) …
03-06 14:03:47 pulseaudio_dlna.streamserver INFO Starting processes “parec --format=s16le -d upmpdraspi_dlna.monitor | lame -b 192 -r -”
03-06 14:03:47 pulseaudio_dlna.streamserver INFO Processes of /dWRuPSJ1dWlkOmVlOGZmNzM3LWJiY2EtMmFkYy0xNGRjLWI4MjdlYjM2YzhmMSIsdHlwZT0iYnJpZGdlIg%3D%3D/stream.mp3 initialized …
03-06 14:03:47 pulseaudio_dlna.streamserver INFO Unregistered stream “/dWRuPSJ1dWlkOmVlOGZmNzM3LWJiY2EtMmFkYy0xNGRjLWI4MjdlYjM2YzhmMSIsdHlwZT0iYnJpZGdlIg%3D%3D/stream.mp3” (0x7fcc7bb92ed0) …
03-06 14:03:49 pulseaudio_dlna.streamserver INFO No more stream from device “UpMpd RASPI”.

After which the client tries to connect for a couple of secs, after which I get the following output

03-06 14:04:03 pulseaudio_dlna.plugins.upnp.renderer WARNING Updating device state unsuccessful! Sending play command.
03-06 14:04:03 pulseaudio_dlna.pulseaudio INFO The device “UpMpd RASPI (DLNA)” is playing.
03-06 14:04:03 pulseaudio_dlna.pulseaudio INFO _async_handle_sink_update /org/pulseaudio/core1/sink3 finished!
03-06 14:04:03 pulseaudio_dlna.pulseaudio INFO on_device_updated “/org/pulseaudio/core1/sink0”
03-06 14:04:04 pulseaudio_dlna.pulseaudio INFO _async_handle_sink_update /org/pulseaudio/core1/sink0
03-06 14:04:04 pulseaudio_dlna.pulseaudio INFO _async_handle_sink_update /org/pulseaudio/core1/sink0 finished!

2

Here’s a bunch of version information and confs in case they’d give some pointers to someone!

Versions

Server

sudo python3 -m pip freeze | grep Mopidy
Mopidy==3.0.1
Mopidy-MPD==3.0.0

apt-cache policy upmpdcli
upmpdcli:
Installed: 1.4.7-1~ppa1~buster
Candidate: 1.4.7-1~ppa1~buster
Version table:
*** 1.4.7-1~ppa1~buster 500
500 Index of /upmpdcli/downloads/raspbian buster/main armhf Packages
100 /var/lib/dpkg/status

sudo apt-cache policy python-zeroconf
python-zeroconf:
Installed: 0.19.1-3
Candidate: 0.19.1-3
Version table:
*** 0.19.1-3 500
500 Index of /raspbian buster/main armhf Packages
100 /var/lib/dpkg/status

Client

pulseaudio-dlna -v
0.5.2

confs

sudo mopidyctl config (only relevant)
[audio]
mixer = software
mixer_volume =
output = alsasink
buffer_time =
[proxy]
scheme =
hostname =
port =
username =
password =
[http]
enabled = true
hostname = 0.0.0.0
port = 6680
zeroconf = Mopidy HTTP server on $hostname
allowed_origins =
csrf_protection = true
default_app = mopidy
[softwaremixer]
enabled = true
[stream]
enabled = true
protocols =
http
https
mms
rtmp
rtmps
rtsp
metadata_blacklist =
timeout = 5000
[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

sudo nano /etc/upmpdcli.conf (DEFAULT, except)
#Media Renderer parameters
# “Friendly Name” for the UPnP Media Renderer.
friendlyname = UpMpd RASPI
#MPD parameters
# Host MPD runs on.
mpdhost = 0.0.0.0
# IP port used by MPD
mpdport = 6600

3

Hello again!

Was able to resolve the issue in the end!
The pulseaudio-DLNA warning ‘Updating device state unsuccessful! Sending play command.’ made me interested in the ‘avtautoplay’-line in upmpdcli.conf which, when set to 1, resolved the issue! Woop!

Since there’s quite a bit of text already in my post, here’s TL;DR version:

Had issues with UPnP audio streaming from Ubuntu 18.04 running pulseaudio-DLNA to Raspbian Buster running upmpdcli front-end for Mopidy / MPD. In the end, setting avtautoplay = 1 in upmpdcli.conf resolved the issue.

1 Like
4

That’s for updating with the answer. I don’t use this myself but the last PiMuiscbox release did use upmpdcli so I was curious as to what this option does:

The UPnP/AV SetAVTransportURI, used to set the track to play, normally does not change the current transport state: an explicit Play command is required to start playing if the transport was stopped. Setting this parameter will synthetize a Play command after receiving SetAVTransportURI. This is needed by some control points which do not send the Play command.

I can’t say I understand what’s going on (who’s sending what to who: pc=media provider, pi=renderer, android=controller ?) but glad it’s working for you.

5

Hey @kingosticks!

Thanks for getting back on the topic!

I also find it quite a complicated myself, and can’t say either I’d understand where everything is flowing. But I’m glad it’s resolved now.