UMS runs as a Windows Service after doing this

[sisyphus]

Read this if you want to run UMS as a Windows Service: Open TCP Ports 5001 and 9001 in Windows Firewall.

Has anyone succeeded in running the latest UMS (5.3.1) as a Windows Service on Windows 10?
When run as an Application Program, it works perfectly. But, when I run it as a Windows Service on Windows 10, it "fails":
I never even get the the UMS Icon on the TV!
Clearly, something isn't working correctly when run as a Windows 10 Service.

To diagnose this problem, I suppose you will need a more detailed Log Trace or an NMAP trace?
If so, just tell me where to send it.

=====> Unlike the trace when run as an Application Program, there was no Trace Record: <=====
=====> x:xx.xxx [UPNPHelper] Access granted to /192.168.1.17 by rule: 192.168.1.17 <====
And, I do get the identical results without the "IP Filter" specification.
And, even with Java 1.8.0_25 which is what the UMS Installer downloads.

I hope it is easily readable but all of the relevant Log Records are below:
==========
:35:55.483 [WrapperSimpleAppMain] Language not specified, defaulting to OS language.
:35:55.842 [WrapperSimpleAppMain] Starting Universal Media Server 5.3.1
:35:55.842 [WrapperSimpleAppMain] http://www.universalmediaserver.com
:35:55.842 [WrapperSimpleAppMain] Build: 7228d86b2 (2015-11-22)
:35:55.842 [WrapperSimpleAppMain] Java: Java HotSpot(TM) Client VM 1.8.0_66 32-bit by Oracle Corporation
:35:55.842 [WrapperSimpleAppMain] OS: Windows 10 64-bit 10.0
:35:55.842 [WrapperSimpleAppMain] Encoding: Cp1252
:35:56.342 [WrapperSimpleAppMain] Reading ip_filter: "192.168.1.17,192.168.1.32" (default: "")
:35:56.592 [WrapperSimpleAppMain] Loading MediaInfo library
:35:56.623 [WrapperSimpleAppMain] Loaded MediaInfoLib - v0.7.78
:35:56.639 [WrapperSimpleAppMain] Loading renderer configurations from C:\Program Files (x86)\Universal Media Server\renderers
:35:56.717 [WrapperSimpleAppMain] Added file watch at renderers: renderers\\Samsung-EH5300.conf
:35:56.779 [WrapperSimpleAppMain] Enabled 118 configurations, listed in order of loading priority:
:35:57.170 [WrapperSimpleAppMain] UPNP Services are online, listening for media renderers
:35:57.170 [WrapperSimpleAppMain] Attached http player control handler to web server
:35:57.409 [WrapperSimpleAppMain] Using address /192.168.1.32 found on network interface: name:eth1 (Realtek PCIe GBE Family Controller)
:35:57.409 [WrapperSimpleAppMain] Created socket: /192.168.1.32:5001
:35:57.425 [cling-14] Matched media renderer "Samsung EH5300" based on dlna details "[TV]UN40EH5300 192.168.1.17
uuid:0ee6b281-00fa-1000-ba05-78abbb583770 Samsung Electronics UN40EH5300 AllShare1.0
Samsung RVU TV 2012 series 5 http://www.samsung.com/sec http://www.samsung.com/sec"
:35:57.426 [cling-14] Reading CharMap: "/ :" (default: null)
:35:57.427 [cling-14] Reading MediaInfo: true (default: false)
:35:57.428 [cling-14] Reading RendererName: "Samsung EH5300" (default: "Unknown renderer")
:35:57.428 [cling-14] Adding status button for [TV]UN40EH5300
:35:57.429 [cling-14] Reading RendererIcon: "Samsung-EH5300.png" (default: "unknown.png")
:35:57.440 [cling-14] New renderer found: "[TV]UN40EH5300" with dlna details: {friendlyName=[TV]UN40EH5300, address=192.168.1.17,
udn=uuid:0ee6b281-00fa-1000-ba05-78abbb583770, manufacturer=Samsung Electronics, modelName=UN40EH5300,
modelNumber=AllShare1.0, modelDescription=Samsung RVU TV 2012 series 5,
manufacturerURL=http://www.samsung.com/sec, modelURL=http://www.samsung.com/sec}
:35:57.440 [cling-14] Adding device: urn:schemas-upnp-org:device:MediaRenderer:1 (RemoteDevice) Identity: (RemoteDeviceIdentity)
UDN: uuid:0ee6b281-00fa-1000-ba05-78abbb583770, Descriptor: http://192.168.1.17:7676/smp_18_
:35:57.440 [cling-14] Subscribing to RenderingControl service on [TV]UN40EH5300
:35:57.441 [cling-14] Subscribing to ConnectionManager service on [TV]UN40EH5300
:35:57.441 [cling-14] Subscribing to AVTransport service on [TV]UN40EH5300
:35:57.449 [cling-14] Created upnp player for [TV]UN40EH5300
:35:57.483 [WrapperSimpleAppMain] WEB interface is available at: http://192.168.1.32:9001
:35:57.663 [WrapperSimpleAppMain] A tiny cache admin interface is available at: http://192.168.1.32:5001/console/home
:35:57.718 [WrapperSimpleAppMain] Sending ALIVE...
:35:57.994 [WrapperSimpleAppMain] The server is now available for renderers to find
:36:00.504 [cling-5] Subscription established: ConnectionManager on [TV]UN40EH5300
:36:03.516 [cling-13] Subscription established: RenderingControl on [TV]UN40EH5300
:36:06.524 [cling-13] Subscription established: AVTransport on [TV]UN40EH5300
:36:07.994 [UPNP-AliveMessageSender] Sending ALIVE...
:36:28.001 [UPNP-AliveMessageSender] Sending ALIVE...
==========

[Nadahar]

When running UMS as a service, you have to configure everything via the configuration files since there's no GUI, but the default configuration files are shared with the application mode so that any configuration done in application mode will also apply to the service. Do not run both at the same time though, in addition to trying to use the same ports, both versions will try to write to the same files which could cause problems. Stop the service before launching the application.

But, when it comes to logging configuration there's separate files for "headless" and "GUI" mode, "logback.headless.xml" and "logback.xml" respectively. I'm not 100% sure which file a windows service will use, even though it should be the "headless" file (headless mode is primarily there for use on Linux). When looking now, I see that the's a bug in the install script for Windows, it doesn't copy the "logback.headless.xml" file. That could mean that it falles back to "logback.xml" or it could mean that it uses some default configuration, I'm not sure. In any case it won't really be optimal.

To set the log level to trace, edit the file "UMS.conf" also found in the profile folder. Look for "log_level =" and set it to "TRACE" so it ends up like this: "log_level = TRACE". You should change it back to DEBUG/blank when this is over, since TRACE generates a lot of logs and will impact performance somewhat.

The easiest way for you to get the file is for me to paste the contents of the logback.headless.xml file here. Create a file in UMS' profile folder (default %programdata%\UMS) called "logback.headless.xml" and paste the content below in there. Save the file and restart the service. If that doesn't help, rename the file to "logback.xml" and restart again. I'll fix the install script for the future versions.

Code: Select all

<configuration>
	<!--
		See http://logback.qos.ch/manual/ for more information on how to
		configure the Logback logging engine.
		Available levels: ALL < TRACE < DEBUG < INFO < WARN < ERROR < OFF
	-->

	<!--
		Let UMS decide the path for the logfile: either the current directory
		or (when that is read only) the system temp directory.
	-->
	<define name="logFilePath" class="net.pms.logging.DebugLogPropertyDefiner">
		<key>logFilePath</key>
	</define>

	<!-- Get the user-preferred root logging level. -->
	<define name="rootLevel" class="net.pms.logging.DebugLogPropertyDefiner">
		<key>rootLevel</key>
	</define>
	
	<!-- Get the logfile name -->
	<define name="logFileName" class="net.pms.logging.DebugLogPropertyDefiner">
		<key>logFileName</key>
	</define>

	<!-- Appender for the console -->
	<appender name="console" class="ch.qos.logback.core.ConsoleAppender">
		<!-- No threshold filtering, log everything the root logger allows -->
		<encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
			<charset>UTF-8</charset>
			<pattern>%-5level %d{HH:mm:ss.SSS} [%thread] %msg%n</pattern>
		</encoder>
	</appender>

	<!--
		Appender for the default logfile that will keep the file growing in size
		until UMS is restarted.
	-->
	<appender name="default.log" class="ch.qos.logback.core.FileAppender">
		<!-- No threshold filtering, log everything the root logger allows -->
		<file>${logFilePath}${file.separator}${logFileName}</file>
		<append>false</append>  <!-- Start new logfile on each application start -->
		<encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
			<charset>UTF-8</charset>
			<pattern>%-5level %d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %msg%n</pattern>
		</encoder>
	</appender>

	<!--
		Appender for the default logfile that will roll the logfile after 10 MBytes
		and will keep a maximum of 5 old and compressed logs.
	-->
	<appender name="default.log.10MB" class="ch.qos.logback.core.rolling.RollingFileAppender">
		<!-- No threshold filtering, log everything the root logger allows -->
		<file>${logFilePath}${file.separator}${logFileName}</file>
		<rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
			<fileNamePattern>${logFilePath}${logFileName}.%i.zip</fileNamePattern>
			<minIndex>1</minIndex>
			<maxIndex>5</maxIndex>
		</rollingPolicy>
		<triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
			<maxFileSize>10MB</maxFileSize>
		</triggeringPolicy>
		<encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
			<charset>UTF-8</charset>
			<pattern>%-5level %d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %msg%n</pattern>
		</encoder>
	</appender>

	<!--
		For debugging purposes it can be handy to define custom levels for
		specific classes or packages. For example:
	<logger name="net.pms.dlna.DLNAResource" level="ALL" />
	<logger name="net.pms.network.RequestHandlerV2" level="ALL" />
	<logger name="net.pms.util" level="ALL" />
	-->

	<!-- silence noise from external libraries -->
	<logger name="org.apache" level="WARN" />
	<logger name="httpclient.wire" level="WARN" />

	<!-- Root logger defines the minimum log level for all loggers -->
	<root level="${rootLevel}">
		<appender-ref ref="console" />

		<!--
			If unlimited growth of the logfile is not desired use the
			appender-ref "default.log.10MB" instead of "default.log".
		-->
		<appender-ref ref="default.log" />
		<!-- <appender-ref ref="default.log.10MB" /> -->
	</root>
</configuration>

When it comes to the problem itself, the reason UMS doesn't "work" as a service, I must say that I suspect some firewall is at play. Have you tried to disable the Windows firewall? When UMS runs as a service it runs in a "different context" so that any firewall rules you have made for the .exe file / UMS Application won't apply. I'm not sure how to create firewall rules for a service, but you can probably find that out by searching the net if that is in fact the problem.

[sisyphus]

We might be making progress but, unfortunately, I need a little more assistance.
I discovered that there is a C:\Program Files (x86)\Universal Media Server\service\win32\ folder that contains
a "wrapper.log" file with additional Log Records including:

STATUS | wrapper | :36:04 | Launching a JVM...
INFO | jvm 1 | :36:04 | WrapperManager: Initializing...
INFO | jvm 1 | :36:04 | WrapperManager:
INFO | jvm 1 | :36:04 | WrapperManager: WARNING - Unable to load the Wrapper's native library 'wrapper.dll'.
INFO | jvm 1 | :36:04 | WrapperManager: The file is located on the path at the following location but
INFO | jvm 1 | :36:04 | WrapperManager: could not be loaded:
INFO | jvm 1 | :36:04 | WrapperManager: C:\Program Files (x86)\Universal Media Server\win32\service\wrapper.dll
INFO | jvm 1 | :36:04 | WrapperManager: Please verify that the file is both readable and executable by the
INFO | jvm 1 | :36:04 | WrapperManager: current user and that the file has not been corrupted in any way.
INFO | jvm 1 | :36:04 | WrapperManager: One common cause of this problem is running a 32-bit version
INFO | jvm 1 | :36:04 | WrapperManager: of the Wrapper with a 64-bit version of Java, or vica versa.
INFO | jvm 1 | :36:04 | WrapperManager: =====> This is a 64-bit JVM. <=====
INFO | jvm 1 | :36:04 | WrapperManager: Reported cause:
INFO | jvm 1 | :36:04 | WrapperManager: C:\Program Files (x86)\Universal Media Server\win32\service\wrapper.dll:
XXXX =======> Can't load IA 32-bit .dll on a AMD 64-bit platform <=======
INFO | jvm 1 | :36:04 | WrapperManager: =====> System signals will not be handled correctly. <=====
INFO | jvm 1 | :36:04 | WrapperManager:

If I am interpreting this error message correctly, a 64-bit JVM routine is attempting to load the 32-bit module "wrapper.dll".
But, I am a novice when it comes to Java programming. If so, shouldn't there be a 64-bit version of "wrapper.exe" and "wrapper.dll"?
From the Application Library location "C:\Program Files (x86)\Universal Media Server\, I thought that all of UMS ran 32-bit!
So, I am surprised to see an error like this. I did check and both "wrapper.exe" and "wrapper.dll" are 32-bit modules in the library.

The last time I installed UMS, I had both 32- and 64-bit Java Runtime libraries available. On previous installs, only the 32-bit
Runtime library was available. So, is there something else that could cause the "load" to fail? Or, is it really a 64-bit JVM!

As for the "permissions" possibility, SYSTEM has "Read, Write, Modify and Execute" authority for both modules.

[Nadahar]

Regarding 32 and 64 bits it's a bit different with Java since it's the installed Java version and not the application itself that determine whether it is 32 bit or 64 bit. UMS should work with both, and the install path is probably just where it's "always" been.

The wrapper is a software used to run a Java program as a Windows service, and to be honest I know nothing about it. It definitly sounds like you've got the wrong version, but I'm unsure if it's the Java version or your Windows version that's incompatible.

This stackoverflow article suggests that it's the installed Java version (JVM) that's the deciding factor. I'm guessing you're running 64 bit Java?

The UMS installer probably needs to install different versions of the file depending on JVM version, but since Java could be uninstalled/installed independent from UMS this could easily end up being wrong. I (or somebody else) have to investigate the matter to figure out how this is tied together, I'm just guessing here now, but I'm very confident that you found the problem. The only thing you can do to get it to work is probably to use a 32 bit Java, but we need to figure out how to handle this situation better.

[sisyphus]

Diagnostic Success! There are two distinct problems which complicated diagnosing my problem:
1) First, UMS has to be able to run on a system with both 32-bit and 64-bit Java Runtime Libraries!
---When I installed UMS with ONLY the 32-bit Java Runtime Library, it SOLVED the problem:
------Unable to load the Wrapper's native library 'wrapper.dll'.
---I am confident that the developers will be able to remedy this problem.
2) The second problem appears to be the need for multiple Firewall Definitions.
---When I opened TCP/UDP Ports 5001, I still could not get the message:
------Access granted to /192.168.1.17 by rule: 192.168.1.17
---So, throwing all caution to the wind, I completely disabled the Firewall and IT WORKS!!!!!
------althought I noticed some kind of glitch on the TV when I terminated the connection.
---NETSTAT indicated quite a few TCP/UDP Ports in use. So, I picked a few that might be UMS
------and opened them on a lark. I couldn't find the right Port(s).
---If you happen to know some additional Ports that UMS might use, I will give them a try.

Just to clarify what I mean by "opened", I completely opened them for ALL Programs and Services!
I would hope that UMS would be a little more selective but I thought it was the best way to test.

Also, my knowlege of Java and UMS is limited to being able to spell them. I can't help wondering,
however, whether one or more UMS modules need ALL of the TCP and/or UDP Ports opened for them?
How and on what Ports does the TV and UMS communicate beyond Port 5001 (and is that TCP or UDP or both)?

[Nadahar]

I don't have the full overview over the ports needed. It's not UMS that dictates this, but the DLNA/UPnP standard. It's based on multicast of UDP packages. I THINK UPnP listens to port 5000, but I'm not sure exactly what is needed to allow it's operation. Anyone that's interested can read more about here and try to figure out exactly what needs to be open. My usual answer is that most people run a firewall without a need, as they are protected by a internet router with firewall and NAT. But, some obviously don't, and in that case a firewall is needed but multicast probably won't work anyway unless they have a public IP subnet to assign to all their devices.

In addition to the UPnP communications, UMS listens for HTTP (TCP) on both 5001 and 9001 by default. Those ports can be changed in UMS' configuration however.

[sisyphus]

Once I found "http://upnp.org/specs/arch/UPnP-arch-De ... e-v1.0.pdf" and read it,
everything became clearer. And, you telling me that UMS uses TCP Ports 5001 and 9001 was all I needed.

Here is what happened:
1) UMS uses DLNA/UPnP/SSDP/and who knows what else. They use UDP Port 1900 and TCP Port 2869.
---These are normally "allowed" by Windows Firewall in a rather "unique" way which is irrelevant to the discussion.
---If you want customers to check their Firewall "status", these are identified on
--- "Inbound Rules" and "Outbound Rules" by "Network Discovery (UPnP..." and "Network Discovery (SSDP...".
---So, except for exceptional circumstances, UMS users should not have to do anything for them.

2) When you install 32-bit Java (1.8.0_66), it apparently, "allows" ALL TCP/UDP Ports for
--- "C:\Program Files (x86)\Java\jre1.8.0_66\bin\javaw.exe".
---Installing 64-bit Java would "allow" ALL TCP/UDP Ports for "C:\Program Files\Java\..."

3) The UMS Installer does NOT create any Firewall Definitions.
---But, when UMS is run as a ordinary Java Application Program, it does not need any because of #2 ABOVE!

4) However, when UMS is run as a Windows Service, it "dies" because TCP Port 5001 is "blocked"!
---Therefore, customers will have to create Firewall Definitions for TCP Ports 5001 and 9001 to run as a Windows Service.
---Unfortunately, this exceeds my knowledge of Java! There probably is a way of being more "selective"
---[by "Programs" and/or "Programs and Services" and/or "Service"] but I don't know how and nothing I tried worked.
---The best I can do is "allow" ALL Programs and Services to TCP Ports 5001, 9001 so UMS can run as a Windows Service.

Hope I made everything clear. If not, you know how to contact me. There are very good reasons to be able to run
UMS as a Windows Service rather than an Application Program. So, please do not remove this support because "configuration"
is a little more difficult. However, it would be nice if someone skilled in the art of documentation put a
brief description on the steps necessary somewhere in your "documentation" so it won't be necessary to follow in my footsteps.

Oh, and don't forget the issue when both 32-bit and 64-bit Java Runtime Libraries are available at the install of UMS.

[Nadahar]

Thank you for the detailed investigation. I'm pretty sure I remember that port 5000 is involved in this somehow too, so I'm not sure your list of ports is complete (This list somewhat backs up my memory). A quick search also gave this quote:

What ports are used in UPnP?

There are not many standard ports that are used for UPnP. The only standard port is UDP port 1900, which is used for receiving announcements. In Windows XPport 5000 TCP is also used (and this was the target of a worm in 2002). Some popular ports are 5431 (Broadcom),49152 (Linux IGD) and port 80.

However, your find of the Microsoft default uPnP rules explains why some users manage to run UMS with a firewall at all. I still maintain that normally people have no need for a firewall on their home network though.

The UMS installer does not create any firewall rules. UMS is a cross-platform application. There exists many software firewalls for Windows alone, and when you throw in OS X and the Linux distros as well you end up with a lot of different firewalls to configure. There's no practical way for us to maintain such a system, we'd need one team member that only kept track of the firewall configurations - at least. Combine that with the fact that most people run a software firewall simply because they think it's "the safe thing to do" when it does in fact in most cases do nothing useful, and I think the solution is obvious. The documentation is generally lacking, but it should recommended that people turn off their firewalls or figure out how to configure their firewall software of choice to open these specified ports.

The Java installation only allows OUTBOUND traffic for Java applications. The only situation where that would be a problem is if you have a malicious Java application running that would upload information found on your computer to somewhere else. UMS also needs outbound access, but where everything usually fails in when it comes to inbound access. Since UMS is a server (it serves clients/renderers over the network), other devices need to be able to connect to UMS from the "outside" of the local firewall. Firewalls generally blocks all inbound traffic except for explicitly allowed traffic. Whether UMS runs as a service or not, inbound access needs to be given for TCP port 5001 (for serving renderers) and TCP port 9001 (for the web interface), in addition to any uPnP related ports.

However, because the Windows firewall grants access based on the running process, you'd probably need to give UMS additional outbound access when running as a service. I'm sure there's a way to give Windows services outbound access without allowing all application that access, but as stated before, outbound access is usually nothing to worry about unless you want to keep some application from sending information from your computer.

The challenge is to dumb this down to a level that the average user would understand in a documentation. The only easy advice is "turn of your software firewall on the computer running UMS".

The 64 bit wrapper is not completely trivial either, but I've created this issue about it.

[sisyphus]

Thank you very much for your assistance. Together, we got UMS running as a Windows Service!
The reason that I prefer it running as a Service is because when I Logout, it continues to work!
This may seem trivial but I really dislike leaving my computer "accessible" when I am not present.

I understand and agree with you about the UMS Installer not creating Windows Firewall Definitions.
But, if you ever do, tell the users they need to delete them if they uninstall the product!
If a Java expert ever reads this, I would be interested in a more selective Firewall Definition
for TCP Port 5001 if one exists. However, my Intranet is, hopefully, protected by my Router Firewall
so the risk of completely opening TCP Port 5001 for UMS is miniscule.

Have a Happy New Year and I may be back. I want to convert my Server to Linux
and want a similar setup for it. By the way, I tried all of the other similar products
and, in my opinion, UMS is the best in everyway! And, I have never seen such
outstanding support for an Free, Open Source product. I hope that your users
feel similarly and will DONATE to support the effort. As a retired software engineer,
I know the complexity and COST of software development and maintenance!