Universalmediaserver: UMS install enhancement

Created on 16 Oct 2016  路  15Comments  路  Source: UniversalMediaServer/UniversalMediaServer

Is it possible to only install (NSIS) the necessary version of _FFmpeg_ and _MediaInfo_ ?
I mean 32-bit version only for 32-bit computers and 64-bit version only for the 64-bit computers.
It'll save time and space.

enhancement

All 15 comments

No. UMS should be started in 64 bit when user will install new 64 bit Java. It is expected by user and also by UMS itself that there will not be missing 64 bit tools and libraries in that case.
Crucial is version of Java and not OS... also at time when majority of OS versions are in 64 bit but it should not be case for Java.
Edit: Ok sorry, ignored 32 bit completely as me last few years haven't seen any as I am server guy so forgot there are still 32 bit OSes:) So yes, on 32 bit it is waste of space storing 64bit libraries.

It is possible, but it would require someone to figure out how to do it in the NSIS script. Installing 64 bit binaries on a 32 bit system is pointless as there is no way they can be run. When it comes to 64 OS'es I don't know though, if both versions are used or not. 64 bits Windows can run 32 bits binaries as well, and I don't know if a 32 or 64 bits JVM impacts this in any way. I'd think not though, as these tools are started "from the command line" AFAICR.

Yeah that would be cool

${If} ${RunningX64} or ${If} ${RunningX32} ?
Maybe at the same time, install _TsMuxeR_ version and _ffmpeg_MPGMUX.exe_ only on OS that they are designed for, if it's not already done ?

@SubJunk As i suspect that you are the more NSIS skilled there... ;-)

@Sami32 Remember that the installer (NSIS) is only for Windows, so the fact that this script is at all running ensures that we're on Windows.

I've never studied the OS X install process enough to know how this works, and on Linux making an installer is close to impossible due to the lack of standards. An installer there would need to handle so many different circumstances that hardly anyone bothers to try to make installers. The only software I've seen that use an installer under Linux is Eclipse.

As to upgrade the install process, maybe eliminate the step where it's asked if we want have a advanced or simplified interface, meaning hide advanced options by default.
It'll avoid error or misunderstanding from the users, and simplify the install process and reduce the translation lines ;-) for us.
And if they are skilled for that, they will easily find how to change that from the GUI, imo.

EDIT: As @Nadahar correct me, it's a Wizard part.

@Sami32 That's not part of the installation, that's part of the "wizard" that runs the first time you start UMS. I think it's good to have the choice, I always hate software that assume that I'm stupid and make me look to find the real choices. Do you mean that the stupid users are too stupid to decide if they are stupid or not?

@Nadahar Correct, it's the wizard...my bad.
You should not hate ;-)
Have choice is good, too much is boring...
As far i understood the users complain, they want simplicity, "easyness". The one that can, run it in headless mode.
Do you think that is too much difficult to deselect "Hide advanced options" in the GUI ?

Personnaly i doesn't like this wizard. At your opposite, i found that it consider users stupid to not be able to make their own choice from the GUI.
N.B. I'm not even sure everybody read it before clicking or typing "Enter"...

I think the GUI suffer from bad organization, descriptions and some places layout. That makes it difficult to understand, not the choices themselves.

But, I realize that for very "simple" users almost every option is scary. What I don't understand is that it's too hard for them to select "I want the simple GUI". I don't know how difficult it would be for me to find "Hide advanced options" because I know where it is and what it's called. I do know though, that in general software have a tendency to remove choice or make it difficult to find the choices you need to get the behaviour you want. I find that very annoying, and think that the "fair" thing to do is to simply ask.

When it comes to users complaining about the GUI having too many options, where is this? I certainly can't remember seeing any complaints about this. Complaints that it's hard to find what you need (bad organization/layout) and that it's difficult to understand what things do (bad descriptions and explanations/help) is very understandable for me, although I can't seem to remember seeing a lot of complaints about this either.

I just "hate" the aPple way, assuming that "we" know best and that everyone is stupid. I'm insulted by such behaviour and want nothing to do with software that use that approach.

The complaints i refer to are very public ones, journalistic ones, when evey year they choose the best media servers of the year, the winner price, they comment on them.
That's said, it not specific to UMS, i can see and listen that users want things work by themself or without too much learning curve or searching.
So for me, make it directly in "simple" mode was a move to this. That's said it was just an idea, i doesn't mean it was a good or necessary one...

I never used Apple, i only know that the people love it for their design and simplicity, not sure about their price though :-D

EDIT: I doesn't like proprietary ways, things. Open source is the future ;-)

As said before, I think the threshold for getting UMS to work well is too high and I think it can be way too difficult to acquire enough knowledge of the different settings and configurations to get it to work properly. I just don't think hiding options aka "dumbing it down" does anything to help that situation.

Personally I think all the manual configuration needed on the renderer side especially is a dead end that makes it very random if it works good "out of the box". For some renderers it will work reasonably well, for others too much tinkering is needed. A more intelligent approach to this should be developed, and I think @atamariya might be on to something.

UMS suffers from having had a very "one sided" emphasis for a long time, playing movies. Other parts have been neglected and in many cases broken because it hasn't had any focus. That has led to it being very hard to live with under other circumstances. My approach from the start has been using it for audio delivery first and foremost, and my idea was that it would run on an always available server hidden away that made all our music always available to all compatible devices. The lack of formats and format variants, a working media library and misc bugs hindering long time stability means that UMS doesn't fill that role in a satisfactory way. But, it being open source and all, I figured I could always try to make it better suited for different needs, but this hasn't been an easy road to travel. I imagine that different people will have different needs/wishes and that having a broader focus, basicly doing everything it can do well, would mean that people would see it as much less "complicated".

Being complicated doesn't just mean having few options, it means having to read hours and hours of guides and forum threads to get something to work like you want it to or at all. UMS has a lot of "advanced" edge case functionality that most don't know about, need or are able to get to work. There are still things in here that still don't have any idea about how to get to work, and I think there are undocumented things in here that only one person knows how works, namely the author - which might have left the project. I think it would be much better to remove those half-broken, rare and undocumented features and do what it does well than having the current situation. That I believe, would make a real impact on users' experience of UMS being "complicated".

Edit: When it comes to aPple, it's my view that with them it's never been about the devices. They have always been mediocre at best, only the prices has been on top. But, they have been very effective at creating hype and making themselves "fashionable", so that the feeble-minded is fooled into thinking that they have to have these products to be "successful". This has, unfortunately for the human race, been an economic success for them. While this is sad in itself, it's important not to confuse this with thinking that their devices has been good or clever. They never have been, and probably never will be, and the reason is simple: They have discovered that it's much easier to manipulate the masses into thinking that their devices are great than to actually make great devices.

I guess i get the main ideas ;-)
Since @Subjunk renamed it in "Universal" and @Valid did already very good job to improve images and audio support, with you and @atamariya that seem like music as well, i guess that we can make it much better.

Concerning the many different options, i try to document the more useful or users asked for now, without judging if they are working correctly since as you told it's for specific case that i didn't have experimented myself.
I think that documenting and fixing the important code base as database and DLNA need to have a highter priority. Improve format support and fixes is of course one part of the job.
That's said your idea of "layerized" the GUI could make UMS win the first price :wink:

About the wizard part: (my old screen is fine though ;-))
http://www.universalmediaserver.com/forum/viewtopic.php?f=9&t=5534&p=20870&hilit=BDP+S370#p20870

I have a Windows 10 laptop.

I installed the UMS with no issue. (though some of the install screens were VERY VERY small, and I had to install Java )

We are now doing this with our standalone builds, because with them we can be pretty sure that the user won't replace the 64-bit JRE installation with 32-bit JRE.

Regarding doing it with our regular Windows builds, does anyone know if we can launch and use a 64-bit binary like FFmpeg from a 32-bit Java instance? If so then maybe we can do this

This is now happening in version 9+

Was this page helpful?
0 / 5 - 0 ratings

Related issues

SubJunk picture SubJunk  路  5Comments

SubJunk picture SubJunk  路  4Comments

yohonet picture yohonet  路  4Comments

SubJunk picture SubJunk  路  8Comments

SubJunk picture SubJunk  路  3Comments