Universalmediaserver: DTS not supported for Linux

[Fenzor]

Refering to: http://www.universalmediaserver.com/forum/viewtopic.php?f=10&t=1588

[Fenzor]

Found out that tsMuxeR is not supported while running 64-bit Ubuntu...
It will return error-code: 127
Meaning that it misses some 32-bit libraries.

Installing these packages with dependencies fixed that problem:

• lib32z1
• lib32ncurses5
• lib32bz2-1.0
• libgtk2.0-0:i386

Now everything works. :)
But this should be incorporated into the project somehow...

[Sami32]

@Fenzor Did that issue already solved with the latest UMS version ?
@SubJunk Since you use Linux and make compile you will know better than me if this issue is again valid or if these libraries need to be imported for Linux 64 bit version ;-)
To me it's look like Linux "issue".
EDIT: Linux forum are full of this kind of asks, so it's have nothing to do with UMS issue.
http://askubuntu.com/questions/637113/unable-to-locate-package-lib32bz2-1-0

[Fenzor]

It has to do with tsMuxeR being an 32-bit executable. If it would somehow be possible to get compiled a version of tsMuxeR for 64-bit architecture then UMS could just run the version with correct architecture. (Or perhaps if it was statically linked...) Last time I checked the tsMuxeR-project it was closed source, so it may be difficult to make a workaround for this...

[Nadahar]

I'd say it's easier to just install the needed 32 bits modules. Since UMS doesn't have an installer for Linux (and that's not really viable either when you think of all the different distros and configurations out there), these should just be added to the documentation for Linux installation (for 64 bits Linux only). There are already other libs that need to be installed manually on Linux like libmediainfo and libzen, so these could just be added to that list. I'm not really into Linux versioning, but it's be preferrable not to specify a particular version of the library unless it's strictly needed (much easier for people to find).

[Fenzor]

Yeah, I would absolutely agree with that! :) But since the initial problem was somewhat difficult to track down, it could be communicated better to the end-user that they could miss some libraries. Otherwise make a sticky thread on the Linux section of the forum informing about the installation-process for some common Linux distributions. I have been out of UMS-usage for some while, so it may have been documented without my knowing... :)

I will now close this issue, and hope that this will not be any issue in the future.

[Sami32]

@Fenzor Thanks for answering.
@Nadahar Like always, helpful comments ;-)
For the same reasons that you mentioned above, i guess that it cannot be add to _contrib/binaries-deps-versions_, _contrib/download-pms-binaries-source.sh_ and _contrib/build-pms-binaries.sh_ files for an easy build by users ?
I will add that to the Linux documentation, i just didn't know it had one 8-/ On Github i din't found it, so perhaps you was refering to the forum ?

[Fenzor]

Yeah, I was referring to the forums. (http://www.universalmediaserver.com/forum/) :)
I think it perhaps can be a sticky post under the section: "Linux-specific Support".
The best solution would be some sort of wiki, where multiple people can contribute information more efficiently.
I can contribute some of my experiences with UMS, but I don't have the time to maintain a post in the forums...

[Sami32]

@Fenzor Thanks for sharing and contributing :-)
I submited this request to @SubJunk , now it's after him.

P.S. Don't worry, closed not mean that your sharing will be lost for other users, this issue will appear when searches will be done in Github.

[Nadahar]

There is a Wiki but it's severly lacking. I can't even see the probably most important topic of all there, namely how to install UMS. The installation process for each OS should be documented there.

There's also INSTALL.txt where a couple of lines are dedicated to dependencies:

1) Install the dependencies (this only needs to be done once):

    sudo apt-get install mediainfo openjdk-7-jre
# you can also optionally install dcraw and VLC: sudo apt-get install dcraw vlc

This should be improved. First, only explains installation on Debian/Ubuntu. Second, it's not necessary to install Java 7 if Java 8 is already installed, or some other compatible JVM is installed. It should be explained that openjdk should only be installed if no other compatible JVM is installed already. Third, I don't remember which distro, but during my testing on different Linux installations I know that I had to install libzen manually at least once. Libzen is normally a dependency of libmediainfo and should be installed when installing Mediainfo, but in my experience that isn't always the case. It might be just as easy to just add libzen to the apt-get to avoid issues.

If there's any other relevant information found on the forums it should also be added to both the Wiki and INSTALL.txt, and the installation of the above mention libs should be included for 64 bits Linux'es if tsMuxeR support is desirable.

[SubJunk]

Yeah, our documentation is really lacking in every way. We welcome improvements :)

[Sami32]

@Nadahar Oooyyy i missed that one, but i'm afraid very few users will go check in _install.txt_, wiki seem more user friendly. Maybe on the forum it will have a bigger spread, visibility ? Not meaning that it could not be on Github though, but i'm afraid that the wiki on Github will not be too much updated; on the forum, a collaborative wiki maintaining will have more chance to be updated...only my opinion though.

I don't know if one specific guy is in charge of the forum's Linux section, for compiling useful Linux informations, since my knowledge about Linux is near zero for explaination that could be difficult...
But i can try doing something and the hope that someone will continue, ameliorate it.

**Which library need to be used _libstdc++6:i386_ or _libgtk2.0-0:i386_ ? because i found the two and i'm not able to wisely choice one...

I did some work on _install.txt_, very simple though, so don't hesitate to correct me, please.
Thank you for you input :+1:

@SubJunk For the wiki, i don't know how to do that on Github, so any advice, guidance are welcome ;-)
About my email on the forum concerning a special thread used for Linux users concerning all useful informations that could be need, do you agree ? or have an other idea to do that ?
I can begin a thread that @Fenzor could completed and after that if you like you could make it in "Announcements" part of the "Linux-specific Support" ?

[SubJunk]

@Sami32 if you're interested in contributing the wiki that's great and I can probably give you permissions to do that, just let me know :)

[Sami32]

@SubJunk I'm interested, but it will only be a very modest contribution though...as my Linux knowledge.
And what about one specific thread on the forum ? No answer mean that you think it's not a good idea ?

[Sami32]

@Fenzor Please, feel free to contribute ;-) As for now, it's all i can do.
http://www.universalmediaserver.com/forum/viewtopic.php?f=10&t=8518

[Nadahar]

@Sami32 I think both the Wiki and INSTALL.txt should be correct. What people will find will probably vary, I for one would probably look for a readme or install file for hints. Reading a Wiki would be some of the last things I tried, as it would require me to first figure out that a Wiki existed, where to find it and then finally I'd expect that it might require some effort to actually locate the information I was seeking within the Wiki. People are different :wink:

[Sami32]

@Nadahar I agree, I do about the same ;-)
But, as you told, everyone is different, so i tried to spread these informations in all the place possible to give a better "chance" for Linux users to get it, as they take the time to share their discoveries, experiences. Maybe i feel responsable as well for closing issue without doing that.

Who told that knowledge is done to be shared ? i can't remember.
That may be a drop in the ocean though...

[SubJunk]

A simple solution to the issue of having multiple sources of the information is to remove some. Maybe we could have the Wiki be the main source of information and INSTALL.txt just has a link to the Wiki. Our FAQ on the website is also in a bad state so maybe I should remove that and link to the Wiki instead. The fourth doc we have is the in-program one. We could remove that and replace it with a portal to the Wiki. After doing all those things we just have one source of official docs.

[Sami32]

@SubJunk I'm just afraid that the wiki will lack of updates, from who ?, so not sure about linked INSTALL.txt. To be honest, few people like to do that kind of work...

That's said, consolidate informations in one or two place seem to me a excellent idea.
I hope I didn't offend anyone involuntarily.

[Nadahar]

Personally I'm not that fan of Wiki's, they tend to be messy and hard to find the relevant information. But, that obviously depends on whoever writes it.

I do however favor having some local information available. Not everybody is online all the time, the computer can be on a location without internett access or where it's very expensive (like it is if you have to use mobile Internet here in Norway), the webserver can be down, there can be internet outages, routing problems, sensorship++. Having the most basic information available without going online is a good as I see it. INSTALL.txt shouldn't be much of a "competitor" to the general documentation anyway, it just needs to cover the installation, not everything else. It should absolutely be available inside the download in my opinion. The text itself can just be a copy and paste (that is, the installation instructions in INSTALL.txt and the Wiki can be identical). Having installation instructions in the help section isn't needed, that should be about how to use the program - and could also share much of its content with the Wiki.

I think the challenge to worry about is getting someone to write documentation, not where it should be available if it exists. Copying text isn't that hard after all. Imo all new functionality should be done via PRs and any merged PR should include relevant documentation, but as we've already estabilished we don't agree on how things should work. In any case the biggest hurdle would be to get the documentation updated for everything that's already done without being documented.

As I've mentioned before, there's a general attitude among programmers that they "shouldn't waste their precious time on documentation". While I also find writing documentation very boring and sometimes hard (it can be hard to find a good way to organize/describe a topic), I think the idea concept is nonsense unless you have someone specificly assigned to the task of writing and updating documentation as things evolve. The programmer is the one person that, at the time of coding, knows the logic and how things work in detail. For anybody else to aquire that information they'd either have to read and understand the code, or do often extensive testing. That's a waste of time in my book, and the only logical thing to do is to write down the information already in the developer's head.

That said, in UMS' case (and many other projects) there's the language barrier. Often the developer doesn't have a good enough knowledge of the "base language" (English in UMS' case) to write clear and consise documentation without putting in a lot of effort. That's the only challenge I see that doesn't have an obvious solution. I guess it would be better if the developer documented it in his/her native language than not at all, but it could require some serious effort to get that translated into actual understandable English. The thing with documentation is that if it's not clear and consise, it's close to useless.

[Sami32]

I should not have said it better, maybe because I use Google translate :-D