Windows 64 bit Installer news

[JustFred]

Originally Posted by BobPhoenix

If this is what you were calling a custom location:I think installing to C:\SageTV might be a better custom location. No UAC to complicate the situation. If I misread what you meant then PLEASE ignore this post.

The location I referred to is literally the path I installed to, in response to wnjj's post above. I chose that path merely for the purposes of trying to determine if HDHR Setup was looking for Sage in a specific location (the "usual" x86 SageTv folder). I wasn't advocating whether (nor where) the x64 installer should do something goofy like that as a means of placating HDHR Setup.

In my opinion, having the x64 installer put stuff in x86\SageTV seems problematic. In many ways. And it's easy to imagine a user manually removing it because he "knew" it didn't belong there. Or having Windows try to automatically repair a damaged Shortcut, only to end up pointing to the x86 executables. Or attempting to manually edit the sage.properties file there, and getting frustrated that his edits don't affect operation. Etc, etc.

I'm also not in favor of installing anything to C:\SageTV. Applications have no business living in the root of C:. Experience has shown that this usually turns out badly, one way or another.

[wnjj]

Originally Posted by JustFred

The location I referred to is literally the path I installed to, in response to wnjj's post above. I chose that path merely for the purposes of trying to determine if HDHR Setup was looking for Sage in a specific location (the "usual" x86 SageTv folder). I wasn't advocating whether (nor where) the x64 installer should do something goofy like that as a means of placating HDHR Setup.

In my opinion, having the x64 installer put stuff in x86\SageTV seems problematic. In many ways. And it's easy to imagine a user manually removing it because he "knew" it didn't belong there. Or having Windows try to automatically repair a damaged Shortcut, only to end up pointing to the x86 executables. Or attempting to manually edit the sage.properties file there, and getting frustrated that his edits don't affect operation. Etc, etc.

I'm also not in favor of installing anything to C:\SageTV. Applications have no business living in the root of C:. Experience has shown that this usually turns out badly, one way or another.

Maybe Bob was suggesting a "further away" place to test the directory scan theory? HDHR SW might scan the x86 directory for subdirectories containing instances of sagetv.exe which your test would still accommodate. If installing somewhere else still allows it to be found, it would imply some other method (i.e. registry) is the mechanism, unless they look everywhere except the 64-bit program files directory (not likely). If they do use the registry, we may still be stuck because they likely only look in the 32-bit location.

[JustFred]

Originally Posted by wnjj

Maybe Bob was suggesting a "further away" place to test the directory scan theory? HDHR SW might scan the x86 directory for subdirectories containing instances of sagetv.exe which your test would still accommodate. If installing somewhere else still allows it to be found, it would imply some other method (i.e. registry) is the mechanism, unless they look everywhere except the 64-bit program files directory (not likely). If they do use the registry, we may still be stuck because they likely only look in the 32-bit location.

Updated my earlier post with EDIT #3 to address the above. Other ideas?

[jusjoken]

Originally Posted by JustFred

Updated my earlier post with EDIT #3 to address the above. Other ideas?

So, its the service name. I had to name the 64 bit service differently to support both 32 and 64 on the same pc.

Not sure how to work around it. The 64 bit installer might be able to install the service twice so the old name exists...or at least the registry key exists. I assume then that if you later installed the 32 bit version it would just overwrite the fake one.

k

[wnjj]

Originally Posted by JustFred

Updated my earlier post with EDIT #3 to address the above. Other ideas?

Great detective work there. We consciously renamed the 64-bit service to keep track of them but I wonder if we shouldn’t just make them both “SageTV”. That would allow either one to be found by HDHR but obviously only have one service installed at a time. Since only one can run at a time anyway this may be a good thing to do. Changing bitness would just mean disabling one and then re-enabling the other using their respective service control programs. Not that expect anyone but beta testers to be doing that.

Alternatives are uglier, like putting a 2nd registry entry that just points to the same place. I’m not sure what Windows’ service control setup would even think of that.

Thoughts on this?

[jusjoken]

Originally Posted by wnjj

Great detective work there. We consciously renamed the 64-bit service to keep track of them but I wonder if we shouldn’t just make them both “SageTV”. That would allow either one to be found by HDHR but obviously only have one service installed at a time. Since only one can run at a time anyway this may be a good thing to do. Changing bitness would just mean disabling one and then re-enabling the other using their respective service control programs. Not that expect anyone but beta testers to be doing that.

Alternatives are uglier, like putting a 2nd registry entry that just points to the same place. I’m not sure what Windows’ service control setup would even think of that.

Thoughts on this?

I tried having 2 named the same with a different description but that did not work. I cannot recall the error but one of them would not run.

k

[JustFred]

Originally Posted by wnjj

Great detective work there. We consciously renamed the 64-bit service to keep track of them but I wonder if we shouldn’t just make them both “SageTV”. That would allow either one to be found by HDHR but obviously only have one service installed at a time. Since only one can run at a time anyway this may be a good thing to do. Changing bitness would just mean disabling one and then re-enabling the other using their respective service control programs. Not that expect anyone but beta testers to be doing that.

Alternatives are uglier, like putting a 2nd registry entry that just points to the same place. I’m not sure what Windows’ service control setup would even think of that.

Thoughts on this?

Can't simultaneously have two service keys with the same name. See EDIT #4 for a possible solution.

[Ghildebr]

Originally Posted by Narflex

The 32kHz detection is a bug...sometimes I hit that as well...sometimes it happens as 44.1kHz. I usually just transcode them and watch the transcoded version since FFMPEG usually format detects it properly when SageTV doesn't do it right. (historically we got it right way more often than they did, which is why we use our internal one as the primary detector) Happens to me about once a year.

I am having sporadic issues playing back OTA recordings on my x64 SageTV client. Tonight's "The Big Bang Theory" is a perfect example. From the x64 Client all I get on the Audio track "eng AC3 5.1" is really nothing more than a laugh track, no dialog spoken by the actors. If I switch to the Audio track of "spa AC3" I get the proper audio, along with a narrator describing what the actors are doing. If I play the exact same recording on either a HD300, or a Mi Box 3 using the Android MiniClient 1.4.3, or a x64 PlaceShifter Client, the recording plays correctly. This is the 3rd recording that I have had like this in the last 30 days.

I also cannot play certain 720p .mkv rips of Blu Rays on the HD300 without the entire system locking up with the spinning wheel of death, but the exact same rip plays fine on the x64 Client, x64 PlaceShifter, and the Mi Box. If anyone wants to look at logs just ask. I have hesitated reporting this because Narflex said it was a very seldom but know bug and has been there for a very long time. Just trying to make the product better.

Gary

[wnjj]

Originally Posted by JustFred

Can't simultaneously have two service keys with the same name. See EDIT #4 for a possible solution.

I was suggesting change the SageTV service install source code so that both 32 and 64 use the same original name, "SageTV" and that whichever one is "enabled" last will take over the registry key and point to its service .exe, not that there will be 2 keys. The name is just text passed into 'CreateService' and 'ChangeServiceConfig' in native code.

My "uglier" suggestion was like what you're suggesting which is to install both keys but point them to the same .exe if the 32-bit version isn't installed.

The cleaner solution is a one line code change: https://github.com/google/sagetv/blo...trol.java#L260

Since both cannot be running at the same time anyway, having them share a common key simply means you need to "disable" one and "enable" the other rather than just "stop" and "start". Easy enough if you ask me. This assumes you can 'CreateService' over top of one that's already there. Worst case means we modify the native to remove the existing service before installing one.

[wnjj]

Originally Posted by Ghildebr

I am having sporadic issues playing back OTA recordings on my x64 SageTV client. Tonight's "The Big Bang Theory" is a perfect example. From the x64 Client all I get on the Audio track "eng AC3 5.1" is really nothing more than a laugh track, no dialog spoken by the actors. If I switch to the Audio track of "spa AC3" I get the proper audio, along with a narrator describing what the actors are doing. If I play the exact same recording on either a HD300, or a Mi Box 3 using the Android MiniClient 1.4.3, or a x64 PlaceShifter Client, the recording plays correctly. This is the 3rd recording that I have had like this in the last 30 days.

I also cannot play certain 720p .mkv rips of Blu Rays on the HD300 without the entire system locking up with the spinning wheel of death, but the exact same rip plays fine on the x64 Client, x64 PlaceShifter, and the Mi Box. If anyone wants to look at logs just ask. I have hesitated reporting this because Narflex said it was a very seldom but know bug and has been there for a very long time. Just trying to make the product better.

Gary

If you still have that program I sent you to make small samples out of video files, you can email me them along with whatever log files make sense for the audio and/or the Blu Ray issue.

No guarantee I'll get right on it as I have plans for the next several days.

[JustFred]

Originally Posted by wnjj

I was suggesting change the SageTV service install source code so that both 32 and 64 use the same original name, "SageTV" and that whichever one is "enabled" last will take over the registry key and point to its service .exe, not that there will be 2 keys. The name is just text passed into 'CreateService' and 'ChangeServiceConfig' in native code.

My "uglier" suggestion was like what you're suggesting which is to install both keys but point them to the same .exe if the 32-bit version isn't installed.

The cleaner solution is a one line code change: https://github.com/google/sagetv/blo...trol.java#L260

Since both cannot be running at the same time anyway, having them share a common key simply means you need to "disable" one and "enable" the other rather than just "stop" and "start". Easy enough if you ask me. This assumes you can 'CreateService' over top of one that's already there. Worst case means we modify the native to remove the existing service before installing one.

Thinking out loud here...

What's the mechanism to select between 32 and 64-bit? I suppose the x64 version of SageServiceControl **sorta** could handle that. But I envision compatibility issues with an existing 32-bit installation of Sage7 or Sage9 (if user attempts to start the Sage32 service via existing 32-bit shortcuts). Expecting users to always start/stop/change the service type via SageServiceControl is something they might not be used to. It's a bit inconsistent with the way many other apps document their start/stop services (via the Mgmt console). Clearly showing both 32 and 64-bit services in the Mgmt console and Task Manager makes the situation more transparent.

OTOH, your proposal does offer the ability to prevent the user from accidentally running BOTH 32 and 64-bit services at the same time, but only if they upgrade their existing Sage-32 to 9.2.0.

I'm really expecting quite a few existing users wanting to migrate to x64 will welcome the safety blanket of having both 32 and 64-bit installed side by side. Makes it oh-so-easy to simply copy wiz.bin (and maybe properties) back and forth between the two if there's a meltdown. That's exactly what I'm doing now.

Too bad that HDHR forces us to choose our ugliness.

[wnjj]

Originally Posted by JustFred

Thinking out loud here...

What's the mechanism to select between 32 and 64-bit? I suppose the x64 version of SageServiceControl **sorta** could handle that. But I envision compatibility issues with an existing 32-bit installation of Sage7 or Sage9 (if user attempts to start the Sage32 service via existing 32-bit shortcuts). Expecting users to always start/stop/change the service type via SageServiceControl is something they might not be used to. It's a bit inconsistent with the way many other apps document their start/stop services (via the Mgmt console). Clearly showing both 32 and 64-bit services in the Mgmt console and Task Manager makes the situation more transparent.

OTOH, your proposal does offer the ability to prevent the user from accidentally running BOTH 32 and 64-bit services at the same time, but only if they upgrade their existing Sage-32 to 9.2.0.

I'm really expecting quite a few existing users wanting to migrate to x64 will welcome the safety blanket of having both 32 and 64-bit installed side by side. Makes it oh-so-easy to simply copy wiz.bin (and maybe properties) back and forth between the two if there's a meltdown. That's exactly what I'm doing now.

Too bad that HDHR forces us to choose our ugliness.

I'm not sure what you mean by mechanism. The registry key decides what .exe is linked to a named service. That key is written via the SageTV native code call to 'CreateService' which is what runs when the user clicks the 'enable' button in the service control app. There's no reason why 64-bit 9.2.0 wouldn't work fine along side 32-bit older and even V7 installs. Whichever 'enable' button is pushed last will decide which service is enabled (installed). I think that's easy enough. Want to switch back to 32-bit?...enable it through its app. Same for 64-bit.

You can test this by manually modifying the "SageTV" service registry key to point to the 64-bit .exe, then use the Windows services control panel to start it up (since the 64-bit service control app currently doesn't modify the "SageTV" service). After testing that it works normally, stop it and run the 32-bit SageTV service control app. Choose "enable" and the "start" to see if it replaces the 64-bit one in the registry and runs ok. If that all works, we can change the code to retire the "SageTV64" service name and use "SageTV" for both. This will mean either version of service control app will be able to "enable" over the currently active one.

Since changing back and forth requires copying wiz.bin and correcting properties wizard/next_uid, running the service control app is a minor and easy thing to add to the "switchover" list.

EDIT: I renamed the ImagePath .exe entry and then used 'enable'. It didn't update the .exe. Apparently 'CreateService' doesn't do anything useful if it thinks there's already one there. I'll keep looking into this.

EDIT2: Looks like even the ulgy solution will cause issues for installing 32-bit after 64-bit. According to the 'CreateService' documentation (https://docs.microsoft.com/en-us/win...createservicea), it will return an error if there's already one in there by the same name (likely even a fake one).

ERROR_DUPLICATE_SERVICE_NAME
The display name already exists in the service control manager database either as a service name or as another display name.

This means to do this right we'd have to add code to delete the existing service before installing the new one (https://docs.microsoft.com/en-us/win...ting-a-service) and then only 9.2.0 and above would play nice together.

[JustFred]

Originally Posted by wnjj

The registry key decides what .exe is linked to a named service. That key is written via the SageTV native code call to 'CreateService' which is what runs when the user clicks the 'enable' button in the service control app. There's no reason why 64-bit 9.2.0 wouldn't work fine along side 32-bit older and even V7 installs.

I see the potential advantages of using 32 and 64-bit SageServiceControl.exes to set a single ...services\SageTV key value to the associated SageTVService.exe.

Testing shows that currently the 32-bit ...services\SageTV key is only created by the 32-bit installer, not by SageServiceControl.exe.

We could fix the above by changing the source so that the new 32 and 64-bit SageServiceControl.exe's also set the key value to point to the corresponding SageService.exe executable. The new 32-bit installer would install SageServiceControl-32, as expected. The new 64-bit installer would install it's own SageServiceControl-64, along with the "new improved" SageServiceControl-32 that overwrites any legacy 32-bit version.

Each service control would need to stop the counterpart's running service before starting the new one.

The possible ugly part: what happens if installing/repairing a legacy version of Sage32 **after** a new 32 or 64-bit installation? Repair, using the existing 9.2.0 installer, results in an old SageServiceControl-32 that doesn't set the key value.

[Tiki]

Has anyone reached out to SiliconDust? They may be willing to work with us and modify their code to look for a different registry key. They do make fairly frequent updates to their software.

[JustFred]

Originally Posted by Tiki

Has anyone reached out to SiliconDust? They may be willing to work with us and modify their code to look for a different registry key. They do make fairly frequent updates to their software.

One downside to installing any newer version of HDHR software: it forces a firmware update to the HDHRPrime device (CableLabs requirement). That's been the source of some problems. It's the reason I've had to stick to using one particular old version of their software.

[wnjj]

The simplest option is to make the new code”s “enable” button delete the existing service and install its own and make the “disable” button delete the service. If all versions use “SageTV” as the service name, any version could work with any other, including legacy ones.

If new SageTV is installed over old, it will delete and replace the service. If the new service is shut down (deleted) before installing or repairing older V9, it will install fine.

One more thing you can test: Install old V9, delete the service registry keys, then run its control app and choose “enable.” I think it will recreate the entries based upon the ‘CreateService’ documentation. Is it possible the installer only added them because Ken “diff’ed” the registry to see what keys were needed. If the test works then even switching back to and old version alongside a new one will work if the new one deletes itself.

[JustFred]

Originally Posted by wnjj

One more thing you can test: Install old V9, delete the service registry keys, then run its control app and choose “enable.” I think it will recreate the entries based upon the ‘CreateService’ documentation.

SageTVServiceControl doesn't make any changes to the registry. It fails with "The system cannot find the file specified" if the ...services\SageTV key is missing or the ImagePath value doesn't point to an executable.

[wnjj]

Originally Posted by JustFred

SageTVServiceControl doesn't make any changes to the registry. It fails with "The system cannot find the file specified" if the ...services\SageTV key is missing or the ImagePath value doesn't point to an executable.

That's strange since https://docs.microsoft.com/en-us/win...ling-a-service shows the method to install a service and that's the function in the SageTV "enable" button. I'll play around with this when I get some time.

[jusjoken]

The installer actually creates the service...not just the registry entries. It also sets permissions and firewall entries for the service.

We can change that but that's what it does now.

k

[Ghildebr]

Originally Posted by wnjj

No guarantee I'll get right on it as I have plans for the next several days.

Files emailed to you. Please look at them at your convenience. I have workarounds for all of my issues. Have a good weekend.
Gary