ums-9.8.0 armhf for Raspberry Pi: UPnP server not visible

For help and support with Universal Media Server
Forum rules
Please make sure you follow the Problem Reporting Guidelines before posting if you want a reply
Post Reply
ThomasKorimort
Posts: 1
Joined: Tue Aug 25, 2020 3:40 am

ums-9.8.0 armhf for Raspberry Pi: UPnP server not visible

Post by ThomasKorimort »

I have installed ums-9.8.0 on my Raspberry Pi 4 B 4GB (Raspbian Buster) successfuly as systemd service. It starts nicely, it scans the media folders nicely, the web interface seems quite stable and usable, only the UPnP server is not visible.In the systemctl status report on the service, it says clearly that the UPnP server is visible to the home network, but it is not. What can be the problem here?

Before i had running the miniDLNA server included in Raspbian Buster, which was not really usable, but at least the UPnP server was visible, so i suspect, that with my firewall configuration everything is ok.

http://192.168.1.X:5001/description/fetch gives XML output related to UMS (X is the number of the server in my private network)
Nadahar
Posts: 1990
Joined: Tue Jun 09, 2015 5:57 pm

Re: ums-9.8.0 armhf for Raspberry Pi: UPnP server not visible

Post by Nadahar »

There can be a multitude of issues, but fundamentally, what's needed is: Port 5001 TCP, port 1900 TCP and port 1900 UDP incoming, and "any" outgoing. I have no idea of what firewall or other "blocking software" is running on the server, but these must be allow traffic through somehow.

When you access port 5001, the question is from where? Is this from another computer on the local network? If so, can this computer "see" UMS? The log is needed to say more. When it comes to "privacy" and IP addresses, only public addresses should be of concern. That means that 192.168.x.x, 10.x.x.x and 172.16-31.x.x can be shared since they aren't reachable from outside your local network. In addition, even if they were in some magical way, the perpetrator would need to find a way to identify "your" version of said address, as these addresses are used on millions of private and corporate networks.

Another frequent cause for this is that UMS isn't configured to use a particular network interface, there are multiple on the host, and UMS happens to pick the wrong one. This doesn't seem to be the case here, since that should mean that your call to 5001 would fail too.

Last, UPnP relies on multicast, and as such can't traverse subnets without a lot of "special" network configuration. This problem applies to all UPnP applications though, so it should be just the same with miniDLNA.

Without a log, this is all just guesswork, but the information you have given implies that it's all on the same subnet and that UMS use the correct network interface, which only leaves firewall or other similar "blocking software".
Post Reply