![]() |
|
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. |
![]() |
|
Thread Tools | Search this Thread | Display Modes |
#41
|
|||
|
|||
I figured out why the HD200 was coming up on the server. I needed to include "RemoteClients.properties.defaults" in the Sage directory. That's where it gets most of its settings, including one that forces the rendering onto the remote device.
Now the extender connects and works! The fonts are still funny looking because of the missing FreetypeFontJNI.dll. I'll work on that next. |
#42
|
|||
|
|||
Quote:
For DirectX I learned which versions of DX were installed by the old installer and then determined which of the cabs were needed. Code:
DSETUP.dll dsetup32.dll dxdllreg_x86.cab DXSETUP.exe dxupdate.cab Jun2010_D3DCompiler_43_x86.cab Jun2010_d3dx9_43_x86.cab The other redistributables the installer handles as here... Code:
ac3filter_2_6_0b_lite.exe VC_redist.x86.exe vcredist_x86.exe k
__________________
If you wish to see what I am up to and support my efforts visit my Patreon page |
#43
|
||||
|
||||
Quote:
__________________
Sage Server: 8th gen Intel based system w/32GB RAM running Ubuntu Linux, HDHomeRun Prime with cable card for recording. Runs headless. Accessed via RD when necessary. Four HD-300 Extenders. |
#44
|
||||
|
||||
I'll pay attention to this thread now...so if you have more questions let me know but it seems like you sorted most of it out.
![]()
__________________
Jeffrey Kardatzke Founder of SageTV |
#45
|
|||
|
|||
I got FreetypeFontJNI.dll built a couple days ago so the fonts are happy now.
After much thrashing and iteration, I managed to compile a 64-bit pushreader.dll, which means I should be able to compile the last of the VS source (the Sage demux StrmDeMux). Since the Pushreader source code had yet to be compiled as 32-bit open source it took some doing. I had to add some 'configure' options and even tweak a couple spots inside the ffmpeg code. I'm guessing something must have been setup slightly different when the 32-bit DLL was originally built. One difference may be the MinGW environment I'm running versus a years-old one. There was one thing I couldn't make any sense of: In pushreader.c, there's a function prototype: Code:
void *av_memcpy(void *dest, const void *src, unsigned int size); Jeff, do you know why this function is there versus using a standard memcpy? Was it optimized for performance? The next thing I need to figure out are the external .exe's that get called from within Java using Runtime.getRuntime().exec (e.g. SagetvTranscoder, jhead, ipconfig, etc.). It looks like the majority of them are for Linux so that helps. When called from a 64-bit JVM, they try to run in a 64-bit cmd.exe shell. I think the easiest solution is to run the 32-bit exe's via the 32-bit cmd.exe shell by either coding it into Java (with OS detection if/else) or wrapper batch files that detect and run the 32-bit cmd.exe. The Java option means tweaking the core code. The batch files are a big hack. Any thoughts on this? The next major unknown for me is tuners. I assume those need 64-bit drivers from the manufacturer? Can OpenDCT bridge the gap? If nothing else, an encoder server could be run in 32-bit mode, right? After that I'll have to see what else may need work and then it'll likely be ready for beta testers. You should be able to convert a working 32-bit system over to a 64-bit one by simply replacing binary files and registering the new filters. I'm sure there are plenty of video formats, options and modes that could have issues and even crashes. Anyone wanting to try this should keep a backup system ready to roll. The wiz.bin is completely interchangeable and sage.properties only has path differences in it so you could even copy it back over to a 32-bit system and edit it to get running. |
#46
|
|||
|
|||
Ken,
If you want to start in on the installer, I can always bundle up the binaries I have and put them on Dropbox for you. Getting a clean build environment pull request into Github can take a bit longer. I looked through the installer files and most look like path differences and of course a different binary support file directory. Does it make sense to replicate the installer into a separate one or somehow build options into the existing one or at least share some of the common, bit-independent setup files between them? There was one 64-bit change I had to make in Java. DirecTVSerialControl.java was passing a handle by and forth as an int instead of jlong. The exec calls may end up getting changed in Java too. |
#47
|
|||
|
|||
Great work!!!!!
Quote:
I have a SageTv test bed, running Win7-x64, with assorted Hauppauge PCIe tuners as well as several Hauppauge USB capture devices (and their 64-bit USB drivers). This is the system I used when I first ported all the Sage Native code from it's original VS2005 to VS2015. It's also the box used when I added support for the most recent Hauppauge devices in Sage v9. Let me know when you're ready for a smoke test.
__________________
System #1: Win7-64, I7-920, 8 GB mem, 4TB HD. Java-64 1.8.0_141. Sage-64 v9.2.1 ATSC: 2x HDHR-US (1st gen white) tuners. HD-200. System #2: Win7-64, I7-920, 8 GB mem, 4TB HD. Java 1.8.0_131. Sage v9.1.6.747. ClearQAM: 2x HDHR3-US tuners. HD-200. System #3: Win7-64, I7-920, 12 GB mem, 4TB HD. Java-64 1.8.0_141. Sage-64 v9.2.1 ATSC: 2x HVR2250; Spectrum Cable via HDPVR & USB-UIRT. 3x HD-200. |
#48
|
||||
|
||||
Quote:
https://patchwork.ffmpeg.org/patch/2659/ I agree with JustFred the Hauppauge Tuner drivers shouldn't pose any issue other then older PVR 250/350 model which is a hardware issues it self, and being that main diff from 32 vs 64 bit has to do with how it handles large amounts of random access memory. |
#49
|
|||
|
|||
Quote:
|
#50
|
|||
|
|||
Quote:
I'm sure there will be some 64-bit -vs- pointer issues to resolve. I plan to recompile everything and go through all of the warnings. I've fixed a few already. For example, there are a lot of them where the difference between pointers is compared as an int (i.e. string compares) and practically speaking those should never overflow a 32-bit int. |
#51
|
|||
|
|||
Quote:
The final solution for me needs to begin with source code and all the scripts for compiling them in 32 or 64 bit. I have the complete build from source scripted so I run 1 powershell script and it builds from source, creates the various installers and then uploads them to Bintray/Github. But if I have the binaries I can just start later in the process to work out all the steps. I will also need to change my development environment over to VS2017 even though I don't use the GUI for the build as I use MSBuild.exe through the script. As I research the WIX installer I see I will need to create a new separate MSI for 64 bit. I could combine 32/64 into a single bootstrapped exe (wrapper that I use that prompts the user) but I don't see the value in that and the exe size would just get large. So I am thinking 2 installers would be available for the server - 1 for 32 bit and 1 for 64. The 2 installers would certainly share any files that are the same between the 2 bitness. Also, the default install folder for a 64 bit app on windows will be a different location if I follow standard windows process....which I believe I will. Which means an "upgrade" from 32bit to 64bit would require special handling. Likely the user could just point the installer at the old 32bit location (or the installer could search for it) but that will need to be tested to ensure that is a valid case. Likely an upgrade would be an install to the new 64bit location, run once to get the new properties established and then shutdown and copy in the wiz.bin... anyway. this will need input and testing. k
__________________
If you wish to see what I am up to and support my efforts visit my Patreon page |
#52
|
|||
|
|||
Quote:
First of all, I hijacked this thread and probably should have started a new one. I'm building all of this in VS2015 so no conversion needed there yet. I also used Windows SDK 7.1a since the link for 6.1 doesn't seem to work anymore. The only missing things in 7.1 were qedit.h and another include with a bunch of clsid's that I just found online. You can probably find and compare the equivalent one from the 6.1 SDK. I think putting those into the code base and using 7.1a makes sense. I figured there's some value in you having the binaries early because of the logistics of install directories, registry, etc. I'm a bit uncertain about how to manage the compiles so your input is needed here: I changed all of the VC project files to use $(Platform)/$(Configuration) for intermediate and output file locations. Everything ends up (locally and output) into Win32/Release or x64/Release. This allows building both 32 and 64 without having to move the output files out between builds. When I got to the MinGW stuff, I realized none of those projects would do that as easily though it could be added (i.e. place output binaries into bit-specific folders). Is that worth doing or would you rather have your main build script build everything for 32-bit, copy the output somewhere, clean and then rebuild 64-bit in the same directories? If that's the case, I may put all of the VS projects back to just 'Release' (and 'Debug') no matter the bitness and just send the final output files into specific directories. The advantage to keeping them split is build speed since any unchanged object files will still be there, per-bitness. Your thoughts on this? Also, I did get StrmDeMux.ax compiled last night but like so many other things, testing is another story. |
#53
|
|||
|
|||
Quote:
k
__________________
If you wish to see what I am up to and support my efforts visit my Patreon page |
#54
|
|||
|
|||
Quote:
I haven’t built the 32-bit MingGW stuff (other than Imageloader which I did previously) but it should be exactly the same scripts just running from a 32-bit shell. If you haven’t already installed it, Msys2 is the newest incarnation of MinGW and it lets you run either shell right from simple exe programs/shortcuts. It also has a complete package manager “pacman” to install what’s needed and I’ll give you a list of packages. Once in a shell, your drive is mapped already as /c/path/... You can probably launch the shells and start the compile from a batch file so it’s fully automated. |
#55
|
|||
|
|||
Quote:
https://github.com/google/sagetv/com...b79561ab18c1b9 |
#56
|
||||
|
||||
My guess on why av_memcpy is like that is because it probably exists in the libavutil binary that we were linking against on Windows...but then we updated the FFMPEG code later and that likely got removed from it but we never recompiled the libavutil binary. It would just be some kind of safe/potentially optimized in some way I can't think of variant of memcpy.
![]() Just defining it as memcpy with pointer validation should be sufficient.
__________________
Jeffrey Kardatzke Founder of SageTV |
#57
|
|||
|
|||
Just to update everyone:
I haven't stopped working on this but got a little busy recently so not much new to report. I've been cleaning up my code including all of the unnecessary dead ends and working to make the builds automated. Hopefully in the near future there will be at least a beta Windows installer for some of you to try. You can take your wiz.bin and (modified) Sage.properties with you when you switch over and/or take them back to 32-bit Sage if needed. Ultimate, I plan to document most of the things I ran into for future benefit. I've kept messy notes along the way. ![]() One thing I'm stuck on right now is getting some of the ASM code to compile in FFMPEG. I get an error like this: Code:
C:\msys64\tmp\ccjdCxgt.s: Assembler messages: C:\msys64\tmp\ccjdCxgt.s:15689: Error: operand type mismatch for `cmp' make: *** [common.mak:43: libswscale/swscale.o] Error 1 ![]() I assume FFMPEG compiles fine on Linux 64-bit since it's part of the build scripts? When I got Pushreader compiled before, I had disabled asm in FFMPEG but from what I'm reading online that will cause a large performance hit so I need to get it working. Jeff, I also have a few questions/comments I'll be sending in a PM. |
#58
|
||||
|
||||
I can't help fix the problem, but I can say that ffmpeg does compile under linux (although, I think I had to use a specfic version of gcc (the newer ones don't work)).
It would be nice, if ffmpeg could simply be upgraded to use the latest, where we could pull the latest code, and then just patch it with our changes. I know I've tried that, but, it was too much for me. ![]()
__________________
Batch Metadata Tools (User Guides) - SageTV App (Android) - SageTV Plex Channel - My Other Android Apps - sagex-api wrappers - Google+ - Phoenix Renamer Downloads SageTV V9 | Android MiniClient |
#59
|
||||
|
||||
Quote:
Huge and massive thanks to wnjj for doing this, it might help me to find time to complete the new generation of the TS decrypter + commercial skipper for the 64bit architectures (Linux/Windows) I've been working on ![]() Cheers 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 |
#60
|
|||
|
|||
Quote:
Using the latest or at leas something from this decade would be great. Maybe that will be a future challenge for me. ![]() SageWisdom made an attempt here but I haven’t seen any posts from him for awhile. https://forums.sagetv.com/forums/showthread.php?t=62935 |
![]() |
Tags |
64bit, vs2017 |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
|
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
Linux 64bit MiniClient (issues with JTux on 64bit) | stuckless | SageTV Github Development | 23 | 08-19-2015 12:54 PM |
xp 64bit & HVR-2250 | vikingisson | Hardware Support | 13 | 06-07-2010 10:05 PM |
New Build with Sage7 - Win7 or no? 64bit or 32bit? | ThePaladinTech | SageTV Beta Test Software | 6 | 05-22-2010 09:01 AM |
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 |