VS2017 64Bit Build

[bryanzim]

So I had a little bit of time and wanted to take a stab again and producing a 64 bit version of SageTV. I have a completely compiling source tree except for third_party\SageTV-LPGL\Pushreader. A 64 bit version of this library is needed for successful build of the solution.

I was unable to compile with MinGW for lack of a config.h file in the third_party\ffmpeg folder.

Does anyone have any ideas about this and maybe it should be looked into to update ffmpeg also?

Will also need a 64 bit build of the jar files. I am using the 8.0.1620.1 JDK.

[JustFred]

".. And The Heavens Rejoice .."

Well, at the very least, I'm certainly happy to see this.

Q1: I'm assuming that once they're pulled into the repo, all the .sln and .vcxproj files will be updated for the 64-bit build. Can developers continue to use VS2015, or will VS2017 be required at that point?

Q2: Will it still be possible to build 32-bit binaries? Is this the end of the road for 32-bit and/or XP? Personally, I won't shed any tears for the loss of either of them, but others may feel differently.

[tmiranda]

Originally Posted by bryanzim

So I had a little bit of time and wanted to take a stab again and producing a 64 bit version of SageTV. I have a completely compiling source tree except for third_party\SageTV-LPGL\Pushreader. A 64 bit version of this library is needed for successful build of the solution.

I was unable to compile with MinGW for lack of a config.h file in the third_party\ffmpeg folder.

Does anyone have any ideas about this and maybe it should be looked into to update ffmpeg also?

Will also need a 64 bit build of the jar files. I am using the 8.0.1620.1 JDK.

My hero

I was working on it but there were sooooo many errors and warnings I never made it through them all.

You can use the jar from the linux build.

[jusjoken]

Originally Posted by bryanzim

So I had a little bit of time and wanted to take a stab again and producing a 64 bit version of SageTV. I have a completely compiling source tree except for third_party\SageTV-LPGL\Pushreader. A 64 bit version of this library is needed for successful build of the solution.

I was unable to compile with MinGW for lack of a config.h file in the third_party\ffmpeg folder.

Does anyone have any ideas about this and maybe it should be looked into to update ffmpeg also?

Will also need a 64 bit build of the jar files. I am using the 8.0.1620.1 JDK.

Another developer very interested. I am assuming the installer would also need some work to support both.

Let me know when you are ready to share and i will help out with the installer side... sorry i cannot help with the questions.

k

[wayner]

Originally Posted by JustFred

Q2: Will it still be possible to build 32-bit binaries? Is this the end of the road for 32-bit and/or XP? Personally, I won't shed any tears for the loss of either of them, but others may feel differently.

One reason I can think of for keeping 32 bit is firewire tuning as some people use that and the drivers only work with 32 bit systems in Windows. But that will likely fade over time as fewer cable boxes will support firewire.

[SHS]

Originally Posted by wayner

One reason I can think of for keeping 32 bit is firewire tuning as some people use that and the drivers only work with 32 bit systems in Windows. But that will likely fade over time as fewer cable boxes will support firewire.

Have you try this ? wayner.
https://blogs.msdn.microsoft.com/usb...ewire-package/

[btrcp2000]

I have no skills to help with development, but would be willing to test. I'm trying to move to UNRAID for 64bit, but have had no success getting my r5000 tuners to work with a linux sage server.

[Taddeusz]

Originally Posted by SHS

Have you try this ? wayner.
https://blogs.msdn.microsoft.com/usb...ewire-package/

The problem isn't with FireWire support itself but with the drivers needed for the tuners themselves. Those drivers are proprietary in nature.

[SHS]

Originally Posted by Taddeusz

The problem isn't with FireWire support itself but with the drivers needed for the tuners themselves. Those drivers are proprietary in nature.

So are say it the STB it self then ?.

[Taddeusz]

Originally Posted by SHS

So are say it the STB it self then ?.

Yes, the STB drivers are 32-bit only and I'm unaware of any 64-bit drivers. It apparently uses a standard interface but someone would need to have the knowledge to build a new version of the driver. This is the same interface used to communicate with old SVHS recorders.

[SHS]

Originally Posted by Taddeusz

Yes, the STB drivers are 32-bit only and I'm unaware of any 64-bit drivers. It apparently uses a standard interface but someone would need to have the knowledge to build a new version of the driver. This is the same interface used to communicate with old SVHS recorders.

So there a 2nd driver that ride on top of windows firewire driver ?.

[wayner]

Originally Posted by SHS

So there a 2nd driver that ride on top of windows firewire driver ?.

Yes, there were some drivers that were "hacked" together - I believe it was by a guy named Tim M Moore. If I remember correctly he reverse engineered the ones for a Panasonic D-VHS recorder. These drivers were supposed to work for both video capture and changing channels. I never got the video capture to work with my boxes reliably but the channel changing was rock-solid. They were never officially supported by any company (or person) so it was always kind of a kluge.

But the drivers don't work on 64 bit systems. There has been some discussion here about the issue here and more on the AVS forums. Here is one thread that hasn't been updated in about five years, perhaps there are other threads as well: http://www.avsforum.com/forum/42-hdt...-1394-a-5.html

The best drivers for 32 bit can be found here: https://exdeusweb.github.io/stbfirewire/

Of course, this stuff is very old so there are lots of broken links, etc.

[SHS]

Originally Posted by wayner

Yes, there were some drivers that were "hacked" together - I believe it was by a guy named Tim M Moore. If I remember correctly he reverse engineered the ones for a Panasonic D-VHS recorder. These drivers were supposed to work for both video capture and changing channels. I never got the video capture to work with my boxes reliably but the channel changing was rock-solid. They were never officially supported by any company (or person) so it was always kind of a kluge.

But the drivers don't work on 64 bit systems. There has been some discussion here about the issue here and more on the AVS forums. Here is one thread that hasn't been updated in about five years, perhaps there are other threads as well: http://www.avsforum.com/forum/42-hdt...-1394-a-5.html

The best drivers for 32 bit can be found here: https://exdeusweb.github.io/stbfirewire/

Of course, this stuff is very old so there are lots of broken links, etc.

I see what going on looking at the INF it self in this case look like it build around 9x WDM architect so driver them self could very well be build around same old architect that could explain why there are some compatibility issues with newer OS so with out the original source code there is no hope for you in near future in tell the patent expire and by time there be no telling where SageTV will be at.

[bryanzim]

If this ever were to work then you would be able to build both a 32 bit build and a 64 bit build.

So it looks like PushReader is using a combination of FFMPeg and Mplayer from the 3rd party library. I was able to pull down and compile a new version of FFMpeg; I converted most of the code in PushReader to the newer FFMpeg except for the audio conversion. As I am not a FFMpeg expert this may take some time.

At this point in time it looks as if maybe I want to try to compile the version of mplayer in the third party library and revert push reader since the new mplayer source tree does not contain the audio conversion functions any more either.

So currently at a stumbling block.

[btrcp2000]

Just wondering if you have had any luck with a 64 bit windows setup?

[jusjoken]

Originally Posted by bryanzim

If this ever were to work then you would be able to build both a 32 bit build and a 64 bit build.

So it looks like PushReader is using a combination of FFMPeg and Mplayer from the 3rd party library. I was able to pull down and compile a new version of FFMpeg; I converted most of the code in PushReader to the newer FFMpeg except for the audio conversion. As I am not a FFMpeg expert this may take some time.

At this point in time it looks as if maybe I want to try to compile the version of mplayer in the third party library and revert push reader since the new mplayer source tree does not contain the audio conversion functions any more either.

So currently at a stumbling block.

Any progress?

[sdsean]

Resurrection!!!

So I am a bit surprised that the drivers for firewire tuning don't exist in a 64bit format and even then I feel like that can be resovled with a wrapper. Serial tuning has worked for years on 64bit windows with literally 0 problems (I'm still using it today). beyond that there's still IR tuning and HTTP tuning . . .HTTP tuning has been supported by nearly all STBs be that cable or satellite for the last few years, and IR tuning works on 64 bit already.

What are the other barriers to have a 64bit build on windows? I'd really like to be able to connect more than 2 (maybe 3) HD-300s but more than 2 pretty much always peaks the memory usage beyond 1GB with plugins and what not. . . Yes I could switch to linux, but that's a whole different can of worms and would make it so that i have to create interops between things like playon (which only run on windows). Again as said many times I'm sure there are barriers but to me tuning should be the last problem needing solved. . .

[wnjj]

Thanks for the bump. I, too plan to give this 64-bit thing a whirl. I just now got the 32-bit version to compile OK using the wonderful instructions provided by previous pioneers.

The only wrinkle I ran into was the Windows SDK 6.1 is no longer available for download so I had to make a few changes to get it working on 7.1A.

1. Find a "qedit.h" and add it back to the 7.1A include directory.
2. Added a new include file with a bunch of CSLID's and IID's that are no longer in strmiid.lib for use in FilterGraphTools.cpp.

With those 2 additions, I compiled it ok with SDK7.1A.

Now I'm throwing the switch on 64-bit mode to see what fun ensues. I'm already getting warnings about _USE_32BIT_TIME_T and "long *" versus "LONG_PTR *" which I'll have to work through.

I'm making no promises as this may just be one thing after another but I'm willing to give it a shot.

[sdsean]

Sweetness, let me know what you find and if you think you need and let me know as well I can try and jump in and make edits.

[wnjj]

Update (the following was all done using Visual Studio 2015 and MSYS2/MINGW):

After doing a considerable amount of cleanup inside the VS project files to more easily build 32-bit and 64-bit into separate directories I was able to compile everything in the project except the stream demux filter (same place bryanzim got to). As he stated, it relies upon PushReader which was built in MinGW previously.

Because that filter is only used for video playback, I dumped the files I did have onto a clean machine and tried to fire it up, immediately running into the missing ImageLoader lib...dang. Since I had previously managed to compile the swscale and ImageLoader Windows dlls within MinGW, I next installed a newer MSYS2/MINGW32/MINGW64 setup that supports both 32-bit and 64-bit.

After installing some packages into MSYS2, I was able to build both 32-bit and 64-bit swscale.dll and ImageLoader.dll. I have yet to try but building PushReader should be similar.

Tonight I plan to try running with the ImageLoader dll added and see if I can't at least get a 64-bit server to start up.

The BIG caveat in all of this is that there will likely be 32/64-bit pointer issues that arise as crashes when they finally get used. Now the compilers do warn about them and I fixed a few but so many aren't 'real' issues (like subtracting pointers and storing the result into an 'int').

Still chugging along...