SageTV Community  

Go Back   SageTV Community > SageTV Development and Customizations > SageTV Github Development

Notices

SageTV Github Development Discussion related to SageTV Open Source Development. Use this forum for development topics about the Open Source versions of SageTV, hosted on Github.

Reply
 
Thread Tools Search this Thread Display Modes
  #1  
Old 08-15-2015, 05:48 AM
stuckless's Avatar
stuckless stuckless is offline
SageTVaholic
 
Join Date: Oct 2007
Location: London, Ontario, Canada
Posts: 9,541
Linux 64bit MiniClient (issues with JTux on 64bit)

I did get MiniClient recompiled and I updated it with 64bit jogl libraries, but, when I start the miniclient and select a server it dies immediatly in the JTux code...

Code:
Sat 8/15 6:47:29.819 Connected to gfx server
Sat 8/15 6:47:29.921 Testing to see if server can do a pull mode streaming connection...
Sat 8/15 6:47:29.922 Loaded
Type size error: sizeof(jint) < sizeof(size_t)
Type size error: sizeof(jint) < sizeof(ssize_t)
Type size error: sizeof(jint) < sizeof(ino_t)
Type size error: sizeof(jint) < sizeof(nlink_t)
Type size error: sizeof(jint) < sizeof(blksize_t)
Type size error: sizeof(jint) < sizeof(nfds_t)
Type size error: sizeof(jint) < sizeof(msgqnum_t)
Type size error: sizeof(jint) < sizeof(msglen_t)
Type size error: sizeof(int) < sizeof(ino_t)
Jtux error: Java native types don't match POSIX/SUS types.
Sat 8/15 6:47:29.923 Server can do a pull-mode streaming connection.
Sat 8/15 6:47:29.926 Max screen size=java.awt.Dimension[width=1920,height=1200]
Sat 8/15 6:47:29.926 Error w/ Media Thread: java.net.SocketException: Socket closed
Sat 8/15 6:47:29.926 Error w/ GFX Thread: java.net.SocketException: Socket is closed
java.net.SocketException: Socket closed
In reading the JTux site, it makes reference to doing the checks...
Quote:
Primitive Types

Java has only eight primitive types, whereas C has an unlimited number via the typedef facility. For a type like, say, pid_t in C, one can go two ways:

bullet Use a Java primitive type, such as int.
bullet Define a Java class named pid_t.
Jtux uses the former approach so that calling methods and dealing with fields in structures can be as much like C as possible. During start up, Jtux checks that each of the primitive types it uses as a typedef-type replacement is wide enough for the job.
So, I decided to take off the seatbelt, and I commented out the code inside of
Code:
JNIEXPORT void JNICALL Java_jtux_UUtil_check_1type_1sizes(JNIEnv *env, jclass obj)
After rebuilding, I can now launch the MiniClient on Linux in 64bit, and connect to server. It appears to work.

The code does an extensive job checking sizes, and I'm not sure just commented it out is the right approach

Code:
	if (sizeof(jlong) < sizeof(long)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jlong) < sizeof(long)\n");
	}
	if (sizeof(jlong) < sizeof(void *)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jlong) < sizeof(void *)\n");
	}
	if (sizeof(jint) < sizeof(int)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jlong) < sizeof(int)\n");
	}
	if (sizeof(jshort) < sizeof(short)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jshort) < sizeof(short)\n");
	}
	if (sizeof(jlong) < sizeof(clock_t)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jlong) < sizeof(clock_t)\n");
	}
	if (sizeof(jlong) < sizeof(gid_t)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jlong) < sizeof(gid_t)\n");
	}
	if (sizeof(jlong) < sizeof(pid_t)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jlong) < sizeof(pid_t)\n");
	}
	if (sizeof(jlong) < sizeof(uid_t)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jlong) < sizeof(uid_t)\n");
	}
	if (sizeof(jlong) < sizeof(rlim_t)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jlong) < sizeof(rlim_t)\n");
	}
	if (sizeof(jlong) < sizeof(time_t)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jlong) < sizeof(time_t)\n");
	}
	if (sizeof(jlong) < sizeof(suseconds_t)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jlong) < sizeof(suseconds_t)\n");
	}
	if (sizeof(jlong) < sizeof(useconds_t)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jlong) < sizeof(useconds_t)\n");
	}
	if (sizeof(jlong) < sizeof(off_t)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jlong) < sizeof(off_t)\n");
	}
	if (sizeof(jlong) < sizeof(fsfilcnt_t)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jlong) < sizeof(fsfilcnt_t)\n");
	}
	if (sizeof(jlong) < sizeof(fsblkcnt_t)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jlong) < sizeof(fsblkcnt_t)\n");
	}
	if (sizeof(jint) < sizeof(size_t)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jint) < sizeof(size_t)\n");
	}
	if (sizeof(jint) < sizeof(ssize_t)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jint) < sizeof(ssize_t)\n");
	}
	if (sizeof(jint) < sizeof(mode_t)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jint) < sizeof(mode_t)\n");
	}
	if (sizeof(jlong) < sizeof(dev_t)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jint) < sizeof(dev_t)\n");
	}
	if (sizeof(jint) < sizeof(ino_t)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jint) < sizeof(ino_t)\n");
	}
	if (sizeof(jint) < sizeof(nlink_t)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jint) < sizeof(nlink_t)\n");
	}
	if (sizeof(jint) < sizeof(blksize_t)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jint) < sizeof(blksize_t)\n");
	}
	if (sizeof(jlong) < sizeof(blkcnt_t)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jlong) < sizeof(blkcnt_t)\n");
	}
	if (sizeof(jint) < sizeof(nfds_t)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jint) < sizeof(nfds_t)\n");
	}
	if (sizeof(jlong) < sizeof(key_t)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jlong) < sizeof(key_t)\n");
	}
	if (sizeof(jint) < sizeof(msgqnum_t)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jint) < sizeof(msgqnum_t)\n");
	}
	if (sizeof(jint) < sizeof(msglen_t)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jint) < sizeof(msglen_t)\n");
	}
	if (sizeof(jlong) < sizeof(mqd_t)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jlong) < sizeof(mqd_t)\n");
	}
	if (sizeof(jint) < sizeof(socklen_t)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jint) < sizeof(socklen_t)\n");
	}
	if (sizeof(jint) < sizeof(sa_family_t)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jint) < sizeof(sa_family_t)\n");
	}
	if (sizeof(jshort) < sizeof(in_port_t)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jshort) < sizeof(in_port_t)\n");
	}
	if (sizeof(jint) < sizeof(in_addr_t)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(jint) < sizeof(in_addr_t)\n");
	}
	/*
		Assuming C ints (not only jints) are at least 32-bits, because of the int
		argument to field_ctoj_int.
	*/
	if (sizeof(int) < sizeof(in_addr_t)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(int) < sizeof(in_addr_t)\n");
	}
	if (sizeof(int) < sizeof(ino_t)) {
		ok = false;
		fprintf(stderr, "Type size error: sizeof(int) < sizeof(ino_t)\n");
	}
	if (!ok)
		setup_throw_errno(env, ENOSYS);
In digging through the Java Documentation, i think I know why this is failing, but not 100% sure how we should fix it.

Quote:
Primitive Types and Native Equivalents
Java Type Native Type Description
boolean jboolean unsigned 8 bits
byte jbyte signed 8 bits
char jchar unsigned 16 bits
short jshort signed 16 bits
int jint signed 32 bits
long jlong signed 64 bits
float jfloat 32 bits
double jdouble 64 bits
void void not applicable

It appears that on 64bit systems jint 32bits and size_t is 64bits, whereas on 32bit systems they are the same size. This is odd, since the C spec states that size_t should be size of unsigned int, which it would expect to be 4 as well.
Code:
sizeof(jint): 4, sizeof(size_t): 8 
sizeof(int): 4, sizeof(uint): 4
Given that JTux is used quite a bit in SageTV, I'm not sure what the impact of this is going to be. ie, I'm not sure that just commenting out the code will be a the right choice
Reply With Quote
  #2  
Old 08-15-2015, 07:29 AM
jreichen's Avatar
jreichen jreichen is offline
Sage Icon
 
Join Date: Jul 2004
Posts: 1,192
MrD reported the same thing over on your "Build SageTV (Linux Specific) + GitHub primer" thread. He hadn't replaced any 32-bit libraries so you might double check that on your installation.
__________________
Server: Intel Core i5 760 Quad, Gigabyte GA-H57M-USB3, 4GB RAM, Gigabyte GeForce 210, 120GB SSD (OS), 1TB SATA, HD HomeRun.
Extender: STP-HD300, Harmony 550 Remote,
Netgear MCA1001 Ethernet over Coax.
SageTV: SageTV Server 7.1.8 on Ubuntu Linux 11.04, SageTV Placeshifter for Mac 6.6.2, SageTV Client 7.0.15 for Windows, Linux Placeshifter 7.1.8 on Server and Client
, Java 1.6.
Plugins: Jetty, Nielm's Web Server, Mobile Web Interface.

Reply With Quote
  #3  
Old 08-15-2015, 07:35 AM
routerunner's Avatar
routerunner routerunner is offline
Sage Icon
 
Join Date: May 2008
Location: Wiltshire, UK
Posts: 1,371
Quote:
Originally Posted by stuckless View Post
This is odd, since the C spec states that size_t should be size of unsigned int, which it would expect to be 4 as well.
Code:
sizeof(jint): 4, sizeof(size_t): 8 
sizeof(int): 4, sizeof(uint): 4
The compiler should try to match the size of the integers to the maximum size of registers for that particular architecture, but unfortunately is not always the case, but regardless the architecture:

char is always 1 byte
short is always 2 bytes
long is always 4 bytes
long long is always 8 bytes

int must be at least the size of a short, so can be 2/4/8 bytes depending on compiler/architecture.

Eddy
__________________

Automatic Power Off | Squeezeslave | DVB-S Importer | DVB Decrypter & Card Client | Tuner Preroll


Every man is a damn fool for at least five minutes every day; wisdom consists in not exceeding the limit. ~ Elbert Hubbard
Reply With Quote
  #4  
Old 08-15-2015, 07:45 AM
jm9843 jm9843 is offline
Sage Aficionado
 
Join Date: Oct 2003
Posts: 286
Quote:
Originally Posted by stuckless View Post
It appears that on 64bit systems jint 32bits and size_t is 64bits, whereas on 32bit systems they are the same size. This is odd, since the C spec states that size_t should be size of unsigned int, which it would expect to be 4 as well.
Code:
sizeof(jint): 4, sizeof(size_t): 8 
sizeof(int): 4, sizeof(uint): 4
I think that this offers a pretty good explanation.

Quote:
Originally Posted by stuckless View Post
I'm not sure that just commenting out the code will be a the right choice
Yeah, probably not.
Reply With Quote
  #5  
Old 08-15-2015, 11:08 AM
stuckless's Avatar
stuckless stuckless is offline
SageTVaholic
 
Join Date: Oct 2007
Location: London, Ontario, Canada
Posts: 9,541
Again this isn't a problem with the sizeof(int) or sizeof(size_t), per se, but rather that JTux made some assumptions that sizeof(jint) == sizeof(size_t).

jint is NOT a std C type but a java type.
Reply With Quote
  #6  
Old 08-15-2015, 11:11 AM
stuckless's Avatar
stuckless stuckless is offline
SageTVaholic
 
Join Date: Oct 2007
Location: London, Ontario, Canada
Posts: 9,541
Quote:
Originally Posted by jreichen View Post
MrD reported the same thing over on your "Build SageTV (Linux Specific) + GitHub primer" thread. He hadn't replaced any 32-bit libraries so you might double check that on your installation.
I'm running a full 64bit installation with no 32bit software installed. All my .so files are elf 64bit (file *.so report all 64bit), and the java jvm is 64bit. On a 32bit install JTux would be fine, since it size_t==jint.

The good news is that on the server, JTux is not used very often, but on the Miniclient it's used quite a bit.
Reply With Quote
  #7  
Old 08-15-2015, 11:28 AM
Fuzzy's Avatar
Fuzzy Fuzzy is offline
SageTVaholic
 
Join Date: Sep 2005
Location: Jurupa Valley, CA
Posts: 9,957
Out of curiosity, what is the motivator/target use for compiling a 64 bit miniclient?
__________________
Buy Fuzzy a beer! (Fuzzy likes beer)

unRAID Server: i7-6700, 32GB RAM, Dual 128GB SSD cache and 13TB pool, with SageTVv9, openDCT, Logitech Media Server and Plex Media Server each in Dockers.
Sources: HRHR Prime with Charter CableCard. HDHR-US for OTA.
Primary Client: HD-300 through XBoxOne in Living Room, Samsung HLT-6189S
Other Clients: Mi Box in Master Bedroom, HD-200 in kids room
Reply With Quote
  #8  
Old 08-15-2015, 11:33 AM
jreichen's Avatar
jreichen jreichen is offline
Sage Icon
 
Join Date: Jul 2004
Posts: 1,192
From what I can tell, jtux was written about 10-12 years ago so maybe it wasn't originally 64-bit compatible. There are a couple of "forks" (the original wasn't on github) but they both have the same check for jint/size_t:

https://github.com/BanjoPicker/jtux
https://github.com/swenson/jtux

During some earlier searches I was doing, it looked like jint is always 32-bit, and size_t varies with the platform. However, jni_md.h defines jint as an int. To me that means it should also vary with the size of the platform.
__________________
Server: Intel Core i5 760 Quad, Gigabyte GA-H57M-USB3, 4GB RAM, Gigabyte GeForce 210, 120GB SSD (OS), 1TB SATA, HD HomeRun.
Extender: STP-HD300, Harmony 550 Remote,
Netgear MCA1001 Ethernet over Coax.
SageTV: SageTV Server 7.1.8 on Ubuntu Linux 11.04, SageTV Placeshifter for Mac 6.6.2, SageTV Client 7.0.15 for Windows, Linux Placeshifter 7.1.8 on Server and Client
, Java 1.6.
Plugins: Jetty, Nielm's Web Server, Mobile Web Interface.

Reply With Quote
  #9  
Old 08-15-2015, 12:17 PM
Fuzzy's Avatar
Fuzzy Fuzzy is offline
SageTVaholic
 
Join Date: Sep 2005
Location: Jurupa Valley, CA
Posts: 9,957
if jtux is so old, should it maybe be considered obsolete and a new solution be found? What purposes is it used for in miniclient that couldn't be done with more agnostic java library calls?
__________________
Buy Fuzzy a beer! (Fuzzy likes beer)

unRAID Server: i7-6700, 32GB RAM, Dual 128GB SSD cache and 13TB pool, with SageTVv9, openDCT, Logitech Media Server and Plex Media Server each in Dockers.
Sources: HRHR Prime with Charter CableCard. HDHR-US for OTA.
Primary Client: HD-300 through XBoxOne in Living Room, Samsung HLT-6189S
Other Clients: Mi Box in Master Bedroom, HD-200 in kids room
Reply With Quote
  #10  
Old 08-15-2015, 12:25 PM
stuckless's Avatar
stuckless stuckless is offline
SageTVaholic
 
Join Date: Oct 2007
Location: London, Ontario, Canada
Posts: 9,541
Quote:
Originally Posted by Fuzzy View Post
Out of curiosity, what is the motivator/target use for compiling a 64 bit miniclient?
There isn't a need for it... just that all my systems are 64bit. (Yes, i can run a 32bit miniclient)

Quote:
Originally Posted by Fuzzy View Post
if jtux is so old, should it maybe be considered obsolete and a new solution be found? What purposes is it used for in miniclient that couldn't be done with more agnostic java library calls?
JTux is only used in the Linux pieces, and from what I can it is handling some socket stuff, file io, etc, which could possibly be done using standard java, so I'm not 100% sure what it's needed, other than maybe it's "faster".

JTux is also used on the server code, but doesn't appear to be used quite as extensively.

Maybe Jeff will weigh in
Reply With Quote
  #11  
Old 08-15-2015, 12:44 PM
Fuzzy's Avatar
Fuzzy Fuzzy is offline
SageTVaholic
 
Join Date: Sep 2005
Location: Jurupa Valley, CA
Posts: 9,957
I'm betting it was used as a stop gap to have better socket control than what java 1.4 offered. I'm guessing 1.6 has some better options available, and certainly better performance. I would think in miniclient, which by its function, is likely to be the most portable of the bits of code, we should stick to as much core java api's as possible, and avoid OS specific calls, if possible.
__________________
Buy Fuzzy a beer! (Fuzzy likes beer)

unRAID Server: i7-6700, 32GB RAM, Dual 128GB SSD cache and 13TB pool, with SageTVv9, openDCT, Logitech Media Server and Plex Media Server each in Dockers.
Sources: HRHR Prime with Charter CableCard. HDHR-US for OTA.
Primary Client: HD-300 through XBoxOne in Living Room, Samsung HLT-6189S
Other Clients: Mi Box in Master Bedroom, HD-200 in kids room
Reply With Quote
  #12  
Old 08-16-2015, 02:11 PM
jreichen's Avatar
jreichen jreichen is offline
Sage Icon
 
Join Date: Jul 2004
Posts: 1,192
stuckless, I was looking at the JOGL upgrade and they changed a bunch of package and class names. For instance javax.media.opengl is now com.jogamp.opengl, and the GLPbuffer object no longer exists. That's as far as I got

So far I've been working on the Linux builds and haven't needed a Java IDE. Looks like it's time to work on that.

Jeff, any thoughts on the JOGL API changes?
__________________
Server: Intel Core i5 760 Quad, Gigabyte GA-H57M-USB3, 4GB RAM, Gigabyte GeForce 210, 120GB SSD (OS), 1TB SATA, HD HomeRun.
Extender: STP-HD300, Harmony 550 Remote,
Netgear MCA1001 Ethernet over Coax.
SageTV: SageTV Server 7.1.8 on Ubuntu Linux 11.04, SageTV Placeshifter for Mac 6.6.2, SageTV Client 7.0.15 for Windows, Linux Placeshifter 7.1.8 on Server and Client
, Java 1.6.
Plugins: Jetty, Nielm's Web Server, Mobile Web Interface.

Reply With Quote
  #13  
Old 08-16-2015, 02:38 PM
stuckless's Avatar
stuckless stuckless is offline
SageTVaholic
 
Join Date: Oct 2007
Location: London, Ontario, Canada
Posts: 9,541
Yeah, if you look at my build.gradle, you'll see I've been playing around with pulling in the updated JOGL... and yeah, there are lots of changes. It appears that there are more than just package name changes as well

I tried all the 2.0x versions and they all have issues. So I think the version that sage is using is either a very old 2x RC or a 1x version.
Reply With Quote
  #14  
Old 08-17-2015, 01:18 PM
Narflex's Avatar
Narflex Narflex is offline
Sage
 
Join Date: Feb 2003
Location: Redondo Beach, CA
Posts: 6,301
Quote:
Originally Posted by stuckless View Post
JTux is only used in the Linux pieces, and from what I can it is handling some socket stuff, file io, etc, which could possibly be done using standard java, so I'm not 100% sure what it's needed, other than maybe it's "faster".

JTux is also used on the server code, but doesn't appear to be used quite as extensively.

Maybe Jeff will weigh in
In the SageTV core...there's only one thing I still see JTUX being used for...and that's IOUtils.getUSBHWID (which itself, is never used anymore...it was for HW identification for the SageTV on a stick version)

So it should be fine to remove the jtux dependency altogether from the SageTV core.

In the miniclient code, it looks like there's 2 things it was doing....both are because it needed to use Unix domain sockets rather than IP sockets. One of them is for LIRC integration...the other looks like its for shared memory access for video rendering.

Quote:
Originally Posted by jreichen View Post
stuckless, I was looking at the JOGL upgrade and they changed a bunch of package and class names. For instance javax.media.opengl is now com.jogamp.opengl, and the GLPbuffer object no longer exists. That's as far as I got

So far I've been working on the Linux builds and haven't needed a Java IDE. Looks like it's time to work on that.

Jeff, any thoughts on the JOGL API changes?
I haven't looked at JOGL in a long time....feel free to update it to a more recent version, as long as you fix all the things that it breaks at the same time. I have no idea how complex that update is though.
__________________
Jeffrey Kardatzke
Google
Founder of SageTV
Reply With Quote
  #15  
Old 08-17-2015, 01:44 PM
stuckless's Avatar
stuckless stuckless is offline
SageTVaholic
 
Join Date: Oct 2007
Location: London, Ontario, Canada
Posts: 9,541
Quote:
Originally Posted by Narflex View Post
I haven't looked at JOGL in a long time....feel free to update it to a more recent version, as long as you fix all the things that it breaks at the same time. I have no idea how complex that update is though.
Jeff, I noticed on my system that I was able to run the MiniClient without JOGL... so I'm guessing that it is selectively used? Is there some advantage to using JOGL over standard java implementation, which you've done as well?
Reply With Quote
  #16  
Old 08-18-2015, 12:45 PM
Narflex's Avatar
Narflex Narflex is offline
Sage
 
Join Date: Feb 2003
Location: Redondo Beach, CA
Posts: 6,301
Quote:
Originally Posted by stuckless View Post
Jeff, I noticed on my system that I was able to run the MiniClient without JOGL... so I'm guessing that it is selectively used? Is there some advantage to using JOGL over standard java implementation, which you've done as well?
If you turn off 3D acceleration, then it will not use OpenGL....which of course means that rendering performance is not as good as one would expect. I believe that also then requires support for a video overlay surface in the graphics card...and those went out of style quite awhile ago, especially with Liux drivers....which is why we added OpenGL rendering to the MiniClient so we could support modern graphics cards on Linux.
__________________
Jeffrey Kardatzke
Google
Founder of SageTV
Reply With Quote
  #17  
Old 08-18-2015, 12:49 PM
stuckless's Avatar
stuckless stuckless is offline
SageTVaholic
 
Join Date: Oct 2007
Location: London, Ontario, Canada
Posts: 9,541
Quote:
Originally Posted by Narflex View Post
If you turn off 3D acceleration, then it will not use OpenGL....which of course means that rendering performance is not as good as one would expect. I believe that also then requires support for a video overlay surface in the graphics card...and those went out of style quite awhile ago, especially with Liux drivers....which is why we added OpenGL rendering to the MiniClient so we could support modern graphics cards on Linux.
And I assume that 3d acceleration is off by default? I'll check it on and see what happens The UI feels pretty snappy without JOGL, but I can't actually get video playback working yet, so can't really say how that works.
Reply With Quote
  #18  
Old 08-18-2015, 01:14 PM
Narflex's Avatar
Narflex Narflex is offline
Sage
 
Join Date: Feb 2003
Location: Redondo Beach, CA
Posts: 6,301
Quote:
Originally Posted by stuckless View Post
And I assume that 3d acceleration is off by default? I'll check it on and see what happens The UI feels pretty snappy without JOGL, but I can't actually get video playback working yet, so can't really say how that works.
I *thought* it was on by default...the source code will tell you for sure.
__________________
Jeffrey Kardatzke
Google
Founder of SageTV
Reply With Quote
  #19  
Old 08-18-2015, 01:15 PM
Narflex's Avatar
Narflex Narflex is offline
Sage
 
Join Date: Feb 2003
Location: Redondo Beach, CA
Posts: 6,301
Yeah, it defaults to 3D acceleration on by default:

Code:
    else if ("true".equals(MiniClient.myProperties.getProperty("opengl", "true")))
    {
      if (MiniClient.WINDOWS_OS)
      {
        myGfx = new DirectX9GFXCMD(this);
      }
      else
      {
        try {
          Class[] params = {this.getClass()};
          Object[] args = {this};
          java.lang.reflect.Constructor ctor = Class.forName("sage.miniclient.OpenGLGFXCMD").getConstructor(params);
          myGfx = (GFXCMD2) ctor.newInstance(args);
        }
        catch (Throwable t) {
          System.out.println("Error loading OpenGLGFXCMD class, reverting to default rendering:" + t);
          t.printStackTrace();
          myGfx = new GFXCMD2(this);
        }
      }
    }
But if JOGL fails to load...it'll just fall back to Java.
__________________
Jeffrey Kardatzke
Google
Founder of SageTV
Reply With Quote
  #20  
Old 08-18-2015, 01:34 PM
stuckless's Avatar
stuckless stuckless is offline
SageTVaholic
 
Join Date: Oct 2007
Location: London, Ontario, Canada
Posts: 9,541
Quote:
Originally Posted by Narflex View Post
Yeah, it defaults to 3D acceleration on by default:


But if JOGL fails to load...it'll just fall back to Java.
Well, that makes sense... I'm testing on 64bit machine without 64bit jogl at the moment.


Side question related to jtux and 64bit. I'm considering pulling JTux because of the 64bit issues that I found. I could probably spend the time trying to see if there really is a reason why JTux is very explicit about its checks, and I have done some work in that direction, but I now leaning towards just using

https://github.com/kohlschutter/junixsocket

They support linux/mac/arm and they have 32bit and 64bit packages. The other nice thing is that you only need to include the jar and the natives-jar in the classpath and it will auto-resolve/load the system dependant .so files.

Any thoughts, objections?

This doesn't cover the usb portion, but you said that wasn't used, so I was going to remove it... or find a recent libusb for java.
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
xp 64bit & HVR-2250 vikingisson Hardware Support 13 06-07-2010 10:05 PM
Anyone running 64bit with SageTV on Linux? bcjenkins SageTV Linux 74 07-05-2009 12:59 AM
Having trouble setting up Placeshifter client on Linux FC9 64bit mooseca SageTV Linux 0 03-14-2009 01:29 PM
Any advantage to using XP 64bit rdefino General Discussion 4 10-15-2006 01:47 AM
To 64bit or not to 64bit teknubic Hardware Support 19 07-25-2006 10:57 AM


All times are GMT -6. The time now is 03:39 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.
Copyright 2003-2005 SageTV, LLC. All rights reserved.