INTERACT FORUM
More => Old Versions => JRiver Media Center 20 for Linux => Topic started by: bob on September 27, 2013, 04:56:49 pm
-
We don't require a X server or X hardware support on the machine running MC.
We require this:
libX11-6: installed size 1.5 megs
the dependencies for this are:
libX11-data: installed size 1.6 megs
libxcb1: installed size .2 megs
libxau6: installed size .1 megs
libxdmcp6: installed size .1 megs
libext6
libuuid1
libgtk2.0-0
libp11-kit0
libgl1-mesa-glx or libgl1
any compliant browser
xfonts-75dpi (pcf fonts)
libasound2
Total installed X11 size : 4.8 megs
For comparison, the current package size for MC (compressed) is 67 megs.
You should be able to run with this minimal setup. The GUI should run over an ssh connection.
Runlevels are dependent on the distro. Mine is runlevel 2. Traditionally in unix runlevel 3 was GUI but the different distro makers have done this in disparate ways. Ubuntu and Debian don't use runlevels to determine whether or not the GUI is in use.
We don't care about what desktop you are using, MC is not using any desktop code nor is it using GTK or KDE.
I've run it on XFCE and Gnome. It should run on any desktop.
No ideas about NAS's.
Don't have a linux based one that I can log into.
I can tell you that the current requirements are:
X86 (32 bit)
SSE2
see above for libraries
an ALSA hardware device
I'd imagine one could run on other distro's (i.e. centos) by unpacking the deb and putting the contents into the right place IF the requirements listed above are met.
-
Are you testing/compiling this on FreeBSD at all? A lot of the guys with large media servers (myself included) are running FreeBSD to take advantage of ZFS. Looks like all the required libraries are available on FreeBSD but I'm guessing you wont be providing a source package?
If it's started up over a ssh connection, will it still run once the connection is closed?
Will it blow up if no alsa devices are installed?
-
Runlevels are dependent on the distro. Mine is runlevel 2. Traditionally in unix runlevel 3 was GUI but the different distro makers have done this in disparate ways. Ubuntu and Debian don't use runlevels to determine whether or not the GUI is in use.
Hi Bob
If I may respond and correct, I think you have your runlevels indicated here incorrect, even if you take the disparity of SOME Unix/Linux distros. The traditional runlevel 2 is multiple users, no NFS (network filesystem) and rarely used. Your indicated runlevel 3 for GUI is also not correct, runlevel 3 is multiple users, command line (i.e., all-text mode) interface and is the standard runlevel for most Linux-based server hardware, no GUI. The runlevel for GUI is runlevel 5 for multiple users, GUI (graphical user interface) and the standard runlevel for most Linux-based desktop systems.
Also incorrect with Debian and Ubuntu, yes they are not 100% compliant with UNIX and Linux standards, but they still use the runlevels, here is a post covering this in more detail for Ubuntu and how editing the lightDM config file resolves this, for those interested. http://askubuntu.com/questions/228402/boot-to-runlevel-3
Regards
-
Are you testing/compiling this on FreeBSD at all? A lot of the guys with large media servers (myself included) are running FreeBSD to take advantage of ZFS. Looks like all the required libraries are available on FreeBSD but I'm guessing you wont be providing a source package?
Not yet.
-
Hi Bob
If I may respond and correct, I think you have your runlevels indicated here incorrect, even if you take the disparity of SOME Unix/Linux distros. The traditional runlevel 2 is multiple users, no NFS (network filesystem) and rarely used. Your indicated runlevel 3 for GUI is also not correct, runlevel 3 is multiple users, command line (i.e., all-text mode) interface and is the standard runlevel for most Linux-based server hardware, no GUI. The runlevel for GUI is runlevel 5 for multiple users, GUI (graphical user interface) and the standard runlevel for most Linux-based desktop systems.
Also incorrect with Debian and Ubuntu, yes they are not 100% compliant with UNIX and Linux standards, but they still use the runlevels, here is a post covering this in more detail for Ubuntu and how editing the lightDM config file resolves this, for those interested. http://askubuntu.com/questions/228402/boot-to-runlevel-3
Regards
I shouldn't have said they don't matter at all. Of course 0,1 and 6 are well defined.
I've installed dozens of systems from scratch, though most of them have been upgraded from older versions. Never have seen runlevel 5.
Only have seen runlevel 3 on centos, an old Vanilla SVR4 system and AIX.
Here for example, is my old ubuntu bottle (booting into full GUI w/ Unity):
bob@ubuntu-vbox:~$ cat /etc/issue
Ubuntu 11.10 \n \l
bob@ubuntu-vbox:~$ runlevel
N 2
bob@ubuntu-vbox:~$ uname -a
Linux ubuntu-vbox 3.0.0-19-generic #33-Ubuntu SMP Thu Apr 19 19:05:57 UTC 2012 i686 i686 i386 GNU/Linux
Anyway, that's not the issue. The issue for MC is whether or not a GUI is needed and using runlevel as shorthand for that is not useful IMO.
-
Are you testing/compiling this on FreeBSD at all? A lot of the guys with large media servers (myself included) are running FreeBSD to take advantage of ZFS. Looks like all the required libraries are available on FreeBSD but I'm guessing you wont be providing a source package?
If it's started up over a ssh connection, will it still run once the connection is closed?
Will it blow up if no alsa devices are installed?
We've only been compiling on linux at this time.
Haven't done a lot of testing but the mediaserver switch seems to work. If that remains the case one could do:
ssh
nohup mediacenter /mediaserver&
and disconnect. (or put it in a rc file).
It should use the null device if there are no alsa devices.
-
....SSSE3....
Hard requirement? This appears to eliminate all "older" AMD CPU platforms (<Bulldozer arch).
-
Hard requirement? This appears to eliminate all "older" AMD CPU platforms (<Bulldozer arch).
At this time.
-
At this time.
Shazzbot. I assume that "at this time" means v19. Time to upgrade anyway. Here, twist my arm.... ;)
-
Hard requirement? This appears to eliminate all "older" AMD CPU platforms (<Bulldozer arch).
SSE3 was implemented in the Athlon64, so anything Socket 754/ 939 or newer should work.
Not sure where Bulldozer came from :)
-Leezer-
-
SSE3 was implemented in the Athlon64, so anything Socket 754/ 939 or newer should work.
Not sure where Bulldozer came from :)
The requirement is actually SSSE3 (note the extra S).
I'm not sure if that changes anything or not with regards to CPUs supported.
-
Yes, IIRC, pre-Bulldozer arch does not support SSSE3. Far as I can tell, AMD supports SSSE3 only post K10.
Put it this way, I installed the .deb on my openSUSE (athlon II) machine and I failures with "invalid instruction" and while I'm not 100%, it appears to be the SSSE3.
-
Ouch, you're right :-\
(Assembler makes my head hurt...)
Restricting to post Bulldozer AMD CPUs is definitely a bad move....
-Leezer-
-
It's not our intention to restrict anything. It's just a problem that hasn't been solved.
-
You have to go back to 2006 to find a generally used intel processor that DOESN'T support ssse3. 7 years is pretty ancient in computing terms.
-
Should be libxdmcp6
libxdmp6: installed size .1 megs