Universal Media Server | Forum

With the Linux installs, UMS does not install libzen and libmediainfo.
Those 2 library files need to be already on the Linux computer.

The only options that I know of are:
You can configure UMS.sh to use the included Java or use the Linux system Java.
I always my Linux system Java.
I did try using the included UMS Java in V14.12.1 but the issue was still present.

You can use the UMS included ffmpeg and tsMuxeR or use the Linux system ffmpeg and tsMuxeR
I always use my Linux system ffmpeg and tsMuxeR.
With a UMS install for Linux, it is set to use the Linux system ffmpeg and tsMuxeR.
This can be overridden to use the UMS supplied ffmpeg and tsMuxeR in UMS.conf
EG:
# Path to ffmpeg (absolute or relative from project.binaries.dir)
# Example: /usr/bin/ffmpeg
# Win: win32/ffmpeg.exe
# Mac: osx/ffmpeg
# Linux: ffmpeg + system PATH
ffmpeg_path =
# Remux videos with tsMuxeR when possible instead of transcoding
# Whether FFmpeg should remux videos with tsMuxeR when possible instead of
# Remux videos with tsMuxeR when possible instead of transcoding
# Transcoding Settings Tab: tsMuxeR Page
# Path to tsMuxeR (absolute or relative from project.binaries.dir)
# Example: /usr/ums/linux/tsMuxeR
# Win: win32/tsMuxeR.exe
# Mac: osx/tsMuxeR
# Linux: tsMuxeR + system PATH

I don't believe that any of this is the issue as it worked fine prior to UMS V14.12

My UMS is running on a 32-BIT version of Gentoo Linux.
So I would think the relative folder in ums.jar is: Linux-i386.
But that folder has no files relating to libzen and libmediainfo in either V14.12 or V14.11 of ums.jar.
There is a another folder though named "linux-x86".
It is located at: "com\sun\jna\linux-x86" in ums.jar
The file inside this folder "libjnidispatch.so" is exactly the same for V14.11 and V14.12 so I wouldn't think this is the issue.

My guess is that a configuration file in ums.jar now has the path for libzen and libmediainfo set to "com\sun\jna\linux-x86" which is incorrect.
I'm sure the developers would know straight away where this configuration file is in ums.jar.
Thanks

Bump

I'm not sure if the other linux-x86 folder at "com\sun\jna\linux-x86" is the same as the one where UMS is looking for libzen.so

Try what I suggested and make the "linux-x86" folder in the root of ums.jar and copy libzen.so and libmediainfo.so from your install in here and see if it at least gets rid of this message. You could also try putting them into "com\sun\jna\linux-x86" too but I am guessing this is more for Java libraries.

All of this is guesswork as I don't know the structure of the code and don't know how different it will be on Linux

If this does clear this libzen message then we will have an idea if this was the cause of the OutOfMemory error or if it is something else.

I just need to clarify something.

You are aware that libzen.so and libmediainfo.so has never been included in the Linux version of UMS?
The Linux version of UMS has always required that libzen.so and libmediainfo.so be installed on the users Linux system outside of UMS.

I will give it a try (copying my Linux server versions of libzen.so and libmediainfo.so to ums.jar) and check the outcome.

To me, considering that libzen.so and libmediainfo.so have never been included in the Linux version of UMS and relies on the users Linux system already having those, the issue is simply one of a slip up of the path for libzen.so and libmediainfo.so in ums.jar.

Yeah I get that, just since UMS is looking there if it can find those files then this will eliminate one possibility if you still get the out of memory error.

I'll create an issue for MediaInfo but will be good to know if it is a just mis-configuration or if I need to make a a separate issue for the out of memory error.

I did not know that MediaInfo still needs to be installed separately on Linux, I thought that was part of the installation.

Another thing I was thinking of is since you are using a 32bit OS, the 64bit bit version might have been installed but since UMS does not install this then it won't be the cause.

@mik_s
I have created the folder "linux-x86" in the root of ums.jar and copied my servers versions of libzen.so and libmediainfo.so to that folder.
I will let you know the outcome.

As far as I am aware, only these are included with the linux version of UMS:
Java
ffmpeg
tsMuxeR
And UMS can be configured so it uses those or the ones on the Linux system.

With the default install (Linux), UMS is configured to use the UMS supplied Java and the Linux system versions of ffmpeg and tsMuxeR.

Out of interest, there was an long running "OutOfMemory" problem with UMS and especially when running WebOS versions LG TV's.
That issue did seem to get resolved several main versions ago though.
This is one of the many threads about the issue from 2016.
https://www.universalmediaserver.com/fo ... php?t=9014

PS: Also of interest, there were 2 log files in the UMS V14.12 program folder which I have never seen before in any version of UMS.
It seems that they might have been created at the time UMS V14.12 had the OutOfMemory issue and crashed.
The 2 files are attached in the zip file.

I don't know enough to figure out what those 2 log files are. I looked through them but did not understand them.

It does confirm a memory problem and being unable to allocate 1.5Mb This is insignificant amount so it is very unlikely to actually be out of space, just that it is not allowed to be allocated.
Looking further down I think this is the actual error "unable to create native thread" There is also mention of being unable to find those libraries So this may be the root cause.

Hopefully Subjunk will be able to get a better idea from this.

What was the result of making the changed to UMS.jar? Does it still complain about unable to find those libraries?

Looking over that other thread from what I got was UMS needed a core rewrite to fix some memory problems, but if this is referring to the networking and cache this has been totally changed since v12 I think and the UPnP library used was switched last year, and the database implementation also got redone.
This is probably what fixed that issue so is probably unrelated.

Could you do more logs with that logging option I suggested before set to all/full?
There might be something the LG TV communication that is tripping up UMS and this is normally hidden even in trace mode.
I suggest making sure the LG TV is turned off when starting UMS to let it settle then after a while (5-10 mins) turn on the TV and see what happens in the logs.
This will help eliminate other factors like UMS scanning or other devices on the network talking.

@mik_s
Thanks for checking over those 2 log files.
I don't think I mentioned it before, but those 2 log files were created prior to creating the folder "linux-x86" in the root of ums.jar and copying my servers versions of libzen.so and libmediainfo.so to that folder.

I will keep you updated.
Cheers