Windows 64 bit Installer news

[Ghildebr]

Originally Posted by Ghildebr

As soon as I get home I will send in some logs.
Gary

Here is the log file that was requested. The first part is me trying to play "The Big Bang Theory" on an HD300 on the local LAN. This played with picture but no sound.

The second was me playing the exact same episode on a SageTV Client x64. That recording played on a PC with the latest LAV filters installed along with AC3Filter software. The SageTV Client x64 played the recording with both sound and video.

Nothing changed on the Server x64 between these two attempts. I had to .zip the file it barely exceded the 750.0 KB limit

[Ghildebr]

Here is the log, zipped as well, of me playing the exact same TV show on the same HD300 using the 32 bit Sage TV server. This time the audio played back perfectly. Hopefully both of these logs will assist with the troubleshooting efforts.
Gary

[wnjj]

Looking at the logs, the 32-bit has this in the format string for the file:

[bf=aud;f=AC3;br=384000;index=1;main=yes;tag=bd-80010000;sr=48000;ch=6;lang=eng;]

The 64-bit version has this:

[bf=aud;f=AC3;br=320000;index=1;main=yes;tag=bd-80010000;sr=32000;ch=2;lang=eng;]

It's shows 2 channels (stereo) instead of 6 (5.1) and with a different bitrate. I'm just starting into looking at the code that determines this and it may have to do with some native code that helps choose.

Have you tried hitting the 'audio' button on the remote to see if it picks a different stream source? Are you expecting 5.1 through a receiver and that's why the stereo sound is gone?

EDIT: Looks like FFMPEG may be involved:

public static BitstreamFormat[] extractStreamFormatsFromFFMPEGInfo(String info)

Is 'SageTVTranscoder.exe' in your SageTV directory? The 32-bit one should work, even from a 64-bit java system. Is it the same exact one that's in your 32-bit install?

I think that runs when you first add media files. If you copied your wiz.bin from the 32-bit setup, that info should already be good.

[wnjj]

Originally Posted by wnjj

USB-UIRT support for 64-bit is coming soon!

Also, after some research I now think it may be possible to support the Hauppauge IR blaster using its 32-bit DLL by using a COM server to communicate between 64 and 32 bit like this:

64-bit SageTV -> 64-bit DLL with COM client -> 32-bit exe COM server -> 32-bit DLL

I don't know if the performance loss across processes will matter but for tuning using IR I can't think it would. There's already delay involved there anyway.

I was able to prove this concept. I built a 64-bit program that called into a COM server which in turn called into (and returned data from) a 32-bit DLL. When I get time I will build one that talks to the Hauppauge IR blaster DLL but will need help testing it.

[Ghildebr]

Originally Posted by wnjj

Is 'SageTVTranscoder.exe' in your SageTV directory? The 32-bit one should work, even from a 64-bit java system. Is it the same exact one that's in your 32-bit install?

I think that runs when you first add media files. If you copied your wiz.bin from the 32-bit setup, that info should already be good.

This particular HD300 is installed directly (via a HDMI cable) to the back of a flat screen TV. It should be only 2 channel stereo and not 5.1. The SageTV Client x64 was on a PC that only has 2 speakers as well and it played fine there.

Yes, SageTVTranscoder.exe is in the SageTV directory. Both the 32 bit and the x64 have that file that is dated 6/7/2011 12:55 PM and 7,958 KB.

The x64 install is a clean install that I completely re-setup from scratch. I did not copy anything between the old and the new. I did however use the same Media directories so that each install has access to the exact same TV shows and movies.

[dstanley]

Originally Posted by wnjj

I was able to prove this concept. I built a 64-bit program that called into a COM server which in turn called into (and returned data from) a 32-bit DLL. When I get time I will build one that talks to the Hauppauge IR blaster DLL but will need help testing it.

I wonder if something like that (if it works) could be also used for the firewire tuning package that is only available in 32-bit systems?

Dwight

[Taddeusz]

Originally Posted by dstanley

I wonder if something like that (if it works) could be also used for the firewire tuning package that is only available in 32-bit systems?

Dwight

I don't think so because the problem with FireWire tuning is that the required drivers are 32-bit and cannot be installed on a 64-bit system. You cannot do FireWire tuning without the proper drivers.

Someone would need to write 64-bit drivers.

[wnjj]

Originally Posted by Taddeusz

I don't think so because the problem with FireWire tuning is that the required drivers are 32-bit and cannot be installed on a 64-bit system. You cannot do FireWire tuning without the proper drivers.

Someone would need to write 64-bit drivers.

Help me to understand this. I’ve never heard of 32-bit drivers that can’t be installed on a 64-bit system. I get that they can’t be called from a 64-bit program but Windows allows 32-bit software to install and run.

EDIT (Thanks JustFred): I was being a confused old guy here. Drivers are kernel-level and need to match the OS architecture, regardless of which program calls into them. I guess I'm too used to modern drivers where both are provided and didn't have to think about it. 32-bit DLL's (non-driver), however, can be installed and those may or may not call into kernel-level drivers.

[Taddeusz]

Originally Posted by wnjj

Help me to understand this. I’ve never heard of 32-bit drivers that can’t be installed on a 64-bit system. I get that they can’t be called from a 64-bit program but Windows allows 32-bit software to install and run.

The way FireWire tuning works is through a special driver originally written for a Panasonic DVHS recorder at a time when 64-bit Windows didn't exist. The driver is 32-bit.

When you plug a device (i.e., cable tuner FireWire port) into a Windows computer it needs a driver to operate. Drivers that were written for 32-bit Windows cannot be installed on 64-bit Windows and visa versa. The source code for that driver is owned by Panansonic and not publicly available. A new driver would be required to be written so that it could be compiled for 64-bit.

[wnjj]

Originally Posted by Ghildebr

This particular HD300 is installed directly (via a HDMI cable) to the back of a flat screen TV. It should be only 2 channel stereo and not 5.1. The SageTV Client x64 was on a PC that only has 2 speakers as well and it played fine there.

Yes, SageTVTranscoder.exe is in the SageTV directory. Both the 32 bit and the x64 have that file that is dated 6/7/2011 12:55 PM and 7,958 KB.

The x64 install is a clean install that I completely re-setup from scratch. I did not copy anything between the old and the new. I did however use the same Media directories so that each install has access to the exact same TV shows and movies.

So you had the new install redetect all of your media and build its own wiz.bin? That’s where that format information comes from for existing recordings. If the show was recorded using V7 of SageTV or higher, the metadata is stored inside the file. If not, it uses SageTVTrsnscoder.exe to locate it and then store it in wiz.bin. If I can’t repeat this I’ll either need the show itself or you can use my Wiz2Sql tool to extract the data and see what is in each of the wiz.bins.

[wnjj]

Originally Posted by Taddeusz

The way FireWire tuning works is through a special driver originally written for a Panasonic DVHS recorder at a time when 64-bit Windows didn't exist. The driver is 32-bit.

When you plug a device (i.e., cable tuner FireWire port) into a Windows computer it needs a driver to operate. Drivers that were written for 32-bit Windows cannot be installed on 64-bit Windows and visa versa. The source code for that driver is owned by Panansonic and not publicly available. A new driver would be required to be written so that it could be compiled for 64-bit.

So the low level device drivers are the issue and do no not run like the programs do. This may break the Hauppauge idea too if the 32-bit DLL does nothing more than call into already-installed drivers. As you can see, I know very little of this 2 pieces of hardware or what is installed to operate them.

[wnjj]

Reading a bit more on FireWire it looks like it is a (technologically dying) port available on some STB”s that can send video out as well as receive channel change instructions. I assume SageTV users only want the tuning portion and still capture the video with other means. Can USB-UIRT be used instead? It’s pretty inexpensive and since it already works on 64-bit it would alleviate the need for 64-but FireWire. From what I’ve read it’s been a larger A/V community desire that has slowly died off.

[Ghildebr]

Originally Posted by wnjj

So you had the new install redetect all of your media and build its own wiz.bin? That’s where that format information comes from for existing recordings. If the show was recorded using V7 of SageTV or higher, the metadata is stored inside the file. If not, it uses SageTVTrsnscoder.exe to locate it and then store it in wiz.bin. If I can’t repeat this I’ll either need the show itself or you can use my Wiz2Sql tool to extract the data and see what is in each of the wiz.bins.

The show would of been recorded on the 32 bit version of 9.1.10. That show was recorded on 11/15/2018. Please let me know what would be the easiest way to assist. I am not a developer but I have worked in IT for over 30 years. I can easily follow directions, even if they are technical in nature.

[Taddeusz]

Originally Posted by wnjj

Reading a bit more on FireWire it looks like it is a (technologically dying) port available on some STB”s that can send video out as well as receive channel change instructions. I assume SageTV users only want the tuning portion and still capture the video with other means. Can USB-UIRT be used instead? It’s pretty inexpensive and since it already works on 64-bit it would alleviate the need for 64-but FireWire. From what I’ve read it’s been a larger A/V community desire that has slowly died off.

Yeah, when I still had cable I was using a USB-UIRT. I had actually switched from FireWire because the exetuner program was treating the channels as integers and stripping leading zeros out. That caused channel changes to occur too slowly. With the USB-UIRT I could fill out leading zeros so the cable tuner wouldn't be waiting for more "user" input before changing channels.

[wnjj]

Originally Posted by Ghildebr

The show would of been recorded on the 32 bit version of 9.1.10. That show was recorded on 11/15/2018. Please let me know what would be the easiest way to assist. I am not a developer but I have worked in IT for over 30 years. I can easily follow directions, even if they are technical in nature.

All good info. Here are a couple of things you can try to help solve this:

1. Get my Wiz2SQL program here (https://forums.sagetv.com/forums/sho...d.php?p=577768). Use the '-data' option on both wiz.bin files from the 32-bit and 64-bit installs. Then open the resulting text files in an editor and search for your show title. You should find it in there along with a video/audio format string similar to the one I posted above. See how they compare and/or post them here.

2. Alternatively: On the 64-bit system, copy the 'bad' show to another file and give it a different name. Then rescan for media. After scanning, grab sagetv_0.txt. In there you should find that show's new filename with some stuff about format detection. If it finds it in the file already (it should) you'll see something like: "Using internal format detector first for:". If that fails, it would then have something like "Now using external format detector for:".

If the data is indeed inside the file, I see no reason why both internal format detectors would be different. I believe the internal format reading is all in Java, which is identical between the systems.
EDIT: Upon further investigation, it seems the internal format detector does indeed call into a native function (getMediaAVInf0). I'll be looking at that code next.

This is assuming the difference in audio format is the cause of the issue, which seems reasonable.

[Ghildebr]

Originally Posted by wnjj

EDIT: Upon further investigation, it seems the internal format detector does indeed call into a native function (getMediaAVInf0). I'll be looking at that code next.

This is assuming the difference in audio format is the cause of the issue, which seems reasonable.

Thanks, I will wait and see if you find anything there. Being that technically there is only 1 media file in question, being both the x64 and 32 bit installs are looking at the same media folder and the same identical show recording inside that folder. I am hoping this is the issue.
Gary

[Ghildebr]

I have tested ALL of my TV recordings (currently 30 of them) using the x64 server and the same HD300 setup that I have been testing with. This is the ONLY recording that will not play on the HD300. Do you thing that there may be something wrong with this particular recording? The two screen shots, one 32bit and the other 64bit, are what I see from a x64 client. Please don't waist your time, unless you are seeing something that you believe needs to be fixed. I appreciate everything you are doing in porting Sage to 64 bit. I have minimal developing skills, but I do have a very good testing\troubleshooting background.
Gary

[wnjj]

Originally Posted by Ghildebr

I have tested ALL of my TV recordings (currently 30 of them) using the x64 server and the same HD300 setup that I have been testing with. This is the ONLY recording that will not play on the HD300. Do you thing that there may be something wrong with this particular recording? The two screen shots, one 32bit and the other 64bit, are what I see from a x64 client. Please don't waist your time, unless you are seeing something that you believe needs to be fixed. I appreciate everything you are doing in porting Sage to 64 bit. I have minimal developing skills, but I do have a very good testing\troubleshooting background.
Gary

Thanks for the detective work. I'm guessing this points to a corner case bug in the format detection that is obviously rare but should be fixed. Finding out what it is may well lead to understanding other more generic 32->64 bugs in other areas that could strike later. Each time I've found one of these kinds of quirks I search the code for other situations like it.

[wnjj]

So to follow up on the audio issue:

I wrote a simple command line program that can grab the first 'n' bytes of a file and save it to a new one. That way short samples can easily be made out of large video files without any editing software. Thanks Ghildebr for providing the video sample.

I've concluded that it is indeed a bad file. I believe it plays ok on the 32-bit system since it was originally recorded there. Whatever detection method is used for the live stream got saved into wiz.bin. Then when the file was imported into the 64-bit system, it scanned the file to determine the audio format. I believe that scanning this file into a 32-bit system will have the same problem.

I took some of the SageTV detection source code and made a simple program that extracts the audio formats. It showed this:

sr=32000 br=320000,ch=2 
sr=48000 br=384000,ch=6 
sr=48000 br=384000,ch=6 
sr=48000 br=192000,ch=1 
sr=48000 br=192000,ch=1 
sr=48000 br=48000,ch=2 
sr=48000 br=384000,ch=6
sr=48000 br=384000,ch=6
sr=48000 br=192000,ch=1
sr=48000 br=192000,ch=1
sr=48000 br=192000,ch=1
sr=48000 br=384000,ch=6
sr=48000 br=192000,ch=1
sr=48000 br=192000,ch=1
sr=48000 br=384000,ch=6
sr=48000 br=384000,ch=6
sr=48000 br=384000,ch=6
sr=48000 br=192000,ch=1
sr=48000 br=192000,ch=1
sr=48000 br=192000,ch=1

There are a couple bogus entries in there, including the first one which matches what 64-bit format detect found. The br=384k is the correct English one and the br=192k is the Spanish audio.

Perhaps the detection code could locate more entries or start looking further into the file to avoid this but I suppose there's always another bad file looking to cause trouble.

Back to working on the Hauppauge IR blaster. I hope to have something within a week or two.

[SHS]

Originally Posted by wnjj

So to follow up on the audio issue:

I wrote a simple command line program that can grab the first 'n' bytes of a file and save it to a new one. That way short samples can easily be made out of large video files without any editing software. Thanks Ghildebr for providing the video sample.

I've concluded that it is indeed a bad file. I believe it plays ok on the 32-bit system since it was originally recorded there. Whatever detection method is used for the live stream got saved into wiz.bin. Then when the file was imported into the 64-bit system, it scanned the file to determine the audio format. I believe that scanning this file into a 32-bit system will have the same problem.

I took some of the SageTV detection source code and made a simple program that extracts the audio formats. It showed this:

sr=32000 br=320000,ch=2 
sr=48000 br=384000,ch=6 
sr=48000 br=384000,ch=6 
sr=48000 br=192000,ch=1 
sr=48000 br=192000,ch=1 
sr=48000 br=48000,ch=2 
sr=48000 br=384000,ch=6
sr=48000 br=384000,ch=6
sr=48000 br=192000,ch=1
sr=48000 br=192000,ch=1
sr=48000 br=192000,ch=1
sr=48000 br=384000,ch=6
sr=48000 br=192000,ch=1
sr=48000 br=192000,ch=1
sr=48000 br=384000,ch=6
sr=48000 br=384000,ch=6
sr=48000 br=384000,ch=6
sr=48000 br=192000,ch=1
sr=48000 br=192000,ch=1
sr=48000 br=192000,ch=1

There are a couple bogus entries in there, including the first one which matches what 64-bit format detect found. The br=384k is the correct English one and the br=192k is the Spanish audio.

Perhaps the detection code could locate more entries or start looking further into the file to avoid this but I suppose there's always another bad file looking to cause trouble.

Back to working on the Hauppauge IR blaster. I hope to have something within a week or two.

Shouldn't that be Mulit Audio tracks
it not uncommon to see that with ATSC file