[Solved] FATAL ERROR: Unable to start upnp service

[doctpd]

Running ver14.4.0 on Win10 24/7 i3 server running UMS, LMS, PTRG, NAS, oVPN, CCTV recorder ADVR, podcatcher Juice.

UMS was working fine on 18Aug went on hols and then noted yesterday that server was not coming up on TV's VLC.
Checked the log and noticed "FATAL ERROR: Unable to start upnp service" - as if Java was missing.
No major changes/programs added to server (other than Windows updates) as far as I can remember.
UMS can see web browsers but not Samsung TV, appleTV VLC or iPad VLC

Rebooted a few times
Re-installed UMS ver 14.4.0
Re-installed java 32 and 64 bit which are acknowledged in the terminal by >java -version
checked firewall
checked upnp service running (not sure whether needed)
checked port 5001 free
forced interface and IP
checked Win discovery on private network
used clean UMS.conf file
... all to no effect.

Seems to be problems with JUPNP from the log (TRACE attached to this post)
I suspect this is something obvious I have missed since Googling shows this is not an issue for others, but I'm lost for ideas now.
Advice gratefully received please.

[mik_s]

I don't see anything odd before the error, I even compared the previous section to my logs and it was the same.
The order was slightly different for some parts but it still had everything that is in mine.

Java used by UMS is a self contained version so reinstalling it would have had no effect.


Maybe it is the firewall and is blocking UPnP or some other service. I know Avast is known to block some multicast traffic.

I don't know what all those other programs are but maybe one of them is conflicting with UMS, maybe one recently got updated and that is why it just suddenly stopped working.

See what happens if you stop all those programs then run UMS. If this starts working then you can start one at a time to fine which one is conflicting.

[doctpd]

Many thanks mik_s.
Un-installed Javas if not needed
Tried stopping all extra programs and disabling firewalls/Defender - no effect.
Installed UMS on my Win11 desktop and it works fine.

What environmental variables does UMS set ?
Does it use a JRE_HOME ?
How does it know to use the \jre directory in C:\program files (x86)\universal media server ?
I noted another program has set JRE_HOME.

[boss]

It knows to use the \jre directory in C:\program files (x86)\universal media server from the configuration file UMS.sh
In particular this part of that file:
# Use our JVM if it exists
if [ -f jre17/bin/java ]; then
JAVA="jre17/bin/java"
fi

If you comment it out like this:
# Use our JVM if it exists
# if [ -f jre17/bin/java ]; then
# JAVA="jre17/bin/java"
# fi

It will use your system java.

The environment variables it uses (which are also in UMS.sh) are:
# Provide a means of setting max memory using an environment variable
if [ -z "$UMS_MAX_MEMORY" ]; then
UMS_MAX_MEMORY=1280M
fi

# Execute the JVM
exec "$JAVA" $JAVA_OPTS -Xmx$UMS_MAX_MEMORY -Xss2048k -Dfile.encoding=UTF-8 -Djava.net.preferIPv4Stack=true -Djna.nosys=true -classpath "$PMS_JARS" net.pms.PMS "$@"

Some users have overcome problems by having UMS use their system java rather than the java version included in UMS.
Sounds like one of the windows updates doesn't like the java included with UMS.

[doctpd]

Thanks boss
Where do I find that BASH script in Windows.
Can't see it in either Program Files(x86) or ProgramData on the working desktop system?
It does sound like a JRE problem and this might be it.

[mik_s]

Linux uses the UMS.sh script. If JRE was the problem the UMS would not be running.
I think I saw that the Web UI is initialised and should be accessible but maybe the web player will not work.

I pretty sure windows does not use this and just uses the Java from "C:\Program Files (x86)\Universal Media Server\jre17".
As this is standalone then it should not be touched by windows updates.

I thought there was a section in UMS.conf that specified the Java install but it is just the paths to the transcoding binaries.

Did you update UMS recently? Will it work if you try a previous version?

[doctpd]

After many hours, checking everything, even combing the Registry I've worked this one out - A bit left field.
I restored a disc image from when I knew UMS worked. Only this time it gave the same error.
This took the entire OS out of the equation and the only thing left was a BIOS upgrade I had recently performed- but low level changes surely can't affect OS level comms?
I had to upgrade the BIOS to check a new BMC board after prepping the system disc for Win11 by converting to GPT/UEFI.
Now its on UEFI, I thought, no need for the Compatibility Support Module (CSM) to be enabled for legacy MBR boots. So I disabled it when I reset the fresh BIOS.

BUT... turns out a BIOS disabled CSM (on ASUS P10S server boards anyway) screws up Upnp.
Must be something to do with its legacy audio/video function.

Thanks for your collective help.
Older and a very tiny bit wiser.

[mik_s]

That is a strange one and I would not have been able to figure this out so glad you got it working.

I don't see how a BIOS upgrade could affect things like UPnP unless a driver was at fault and needs updating.

[boss]

Sorry about the info I posted.
My head was in Linux mode and I wasn't paying enough attention to the post.

[doctpd]

This error cropped up again on my system again recently despite my previous explanation.
I now believe that was wrong but I think I have a handle on it now.
Ignore everything posted previously. It is not BIOS.
When it happened this time I installed UMS v15 (still barfed) and took a careful look at the log and with AI help found..

java.net.BindException: Address already in use: bind

Digging I found that port 1900, which is the UDP multicast receiver, was already being used by another process which turned out to be Redfish server used by my Adaptec MaxView RAID.
UMS could not access the port while Redfish had it. But, I knew this was in intermittent problem and the two programs had been working together for the past year- so what is going on?

I killed Redfish and UMS immediately worked. I started Redfish again and UMS continued to work but not vice versa. How odd...

Turns out Redfish appears more flexible and attaches in a shared socket mode if it is coming to the party after UMS.
If Redfish starts first, UMS is blocked. UMS needs first claim to the port.
So it seems to have been a stochastic issue, with a fatal UMS uPnP error occurring if Redfish server managed to bind to port 1900 first.
For whatever reason, UMS tended to beat Redfish to the port on my system and so no error occurred.
Occasionally it must happen in reverse, no idea why, Windows patch, chance or whatever and UMS barfed with the fatal error.

I could put the Redfish service on manual start up but I'm going to try a delayed automatic start first.
I hope I am right this time!