SageTv/Java and 64bit OS?

[Skybolt]

I have recently switched to a new server, 2008 R2 64bit. I was hoping Sage wouls work with 64bit Java, but the service only crashes. So I reverted back to 32bit Java and it seems to work on this OS.

On 2003 server I rarely needed to restart the srevice, now it seem to be once a week. Has anyone else been seeing issues with the 64bit OS? Or heard any rumors of Sage supporting a 64bit OS (64bit mode) or Java 64 bit?

Thanks,
Skybolt

[mayamaniac]

I had it running under Vista 64 bit, and it was running fine, no crashes or anything unusual. The only problem is there is no 64bit drivers for firewire channel changing, so I'm now running it in Win7 32bit.

[Skybolt]

Originally Posted by mayamaniac

I had it running under Vista 64 bit, and it was running fine, no crashes or anything unusual. The only problem is there is no 64bit drivers for firewire channel changing, so I'm now running it in Win7 32bit.

Yeah, I had to add a few reg hacks to get video capture to be found when I was setting up the video sources.

Were you using 64bit Java?

Thanks,
Skybolt

[Fuzzy]

Sage is 32 bit softrware, and as such, will only run in the 32-bit JVM. Nothing is stopping you from having a 64-bit and a 32-bit version of java installed, so you CAN run 64-bit java apps, but it will do nothing for sage.

[mayamaniac]

For Vista 64bit, I used whatever version that was included with the SageTV installer, which is definitely 32bit Java. I had a PVR-150 and 350 on the server at the time, plus an HDHR. I didn't have to do any registry hack to get the tuners to show up.

[Skybolt]

Originally Posted by Fuzzy

Sage is 32 bit softrware, and as such, will only run in the 32-bit JVM. Nothing is stopping you from having a 64-bit and a 32-bit version of java installed, so you CAN run 64-bit java apps, but it will do nothing for sage.

Yeah, That is the conclusion I came to.
Thanks,
Skybolt

[sflamm]

Is this because of the JNI usage?

Otherwise there should be no 32-bit restriction as java is compiled to byte code.

[Slugger]

Originally Posted by sflamm

Is this because of the JNI usage?

Otherwise there should be no 32-bit restriction as java is compiled to byte code.

Exactly.

[sflamm]

Wish we could get Google to release the source or simply simply recompile under 64-bit (easy on windows)...

[Slugger]

Neither are that easy otherwise Narflex would have just done it long ago. The issue is most likely that the bulk of the JNI code is code not written by the Sage team (device drivers, etc.) and that would all be 32bit code. You'd have to track down 64bit versions of all that code and my guess is it doesn't exist otherwise, again, Narflex would have just done a 64bit build along with the 32bit builds.

And for the JNI code written in house, converting to 64bit isn't just a matter of recompiling, there are other considerations involved, which make the task a little more challenging -- certainly not impossible, but definitely not just a matter of "recompiling" and that's it.

[sflamm]

Going to assume that most of what they call natively is through DirectX (which has 64-bit API_... not sure what else they would need to call... ?

As for their own code - actually it is quite simple. They just need to regenerate the JNI stubs and recompile. There is nothing 'extra' to account for...

In both cases the startiung point for 3rd parties (us) would be for them to release the source code to the JNI code... then it would be possible for one of us to port to 64-bit without their re-releasing the product at all...

[gplasky]

Originally Posted by sflamm

Going to assume that most of what they call natively is through DirectX (which has 64-bit API_... not sure what else they would need to call... ?

As for their own code - actually it is quite simple. They just need to regenerate the JNI stubs and recompile. There is nothing 'extra' to account for...

In both cases the starting point for 3rd parties (us) would be for them to release the source code to the JNI code... then it would be possible for one of us to port to 64-bit without their re-releasing the product at all...

You know what they say about assuming. But no-what they call natively is not through Direct X. (Only thru Windows client and they also went EVR for Windows 7) For the extenders, Mac and linux it is definitely not. And as mentioned before - if all it took was a recompile it would have happened a long time ago.

Gerry

[Fuzzy]

All the recording backbone is all native code as well. Might be able to strip that all out and use network encoders, but aside from that, i don't see the gains. The server itself would not gain much from 64-bit. The added memory footprint would be more useful for client side graphics, which, at this point, would be better off going with a whole new front-end. STV was nice, and very good for it's time, but there are many better ways to draw a UI these days. Accelerated graphics rendering was added with v6, but it wasn't anything compared to actually drawing on full direct3D surfaces, or more importantly, rendering the UI objects as actual 3D objects - which I'm not sure any current UI's really leverage fully.