SageTV Open Source Download Area

[stuckless]

Originally Posted by SageWizdom

Stuckless, I'm re-doing the walkthrough using the .deb files instead of the tar.gz.

Would you mind / Is it possible for you to create a file download directory or location where the directory and filenames don't change each build? Something like a "latest" directory with an extra file in it named "buildnumber.txt" that contains the build/version number and/or the build date? Would you mind?

This would help me in two ways.
1) I won't have to keep updating the walkthrough with new links each time a build comes out. I don't mind doing the updates, but they only happen when I notice.

2) With my eventual goal to script as much of the install as possible, if there is a consistent place to download the file, the script will both always be up to date, and also able to check for updates (buildnumber.txt) or by grabbing the newest and attempting to install it. I'm hopeful to at least make a guided install script to simplify the whole process on Linux.

Much Appreciated

The following url is a url that links to the latest version download area
https://bintray.com/opensagetv/saget..._latestVersion

I'm open to suggestions on how to the buildnumber.txt. As long as we can fully automate it (I don't manually upload the builds), I'm ok with making changes.

Eventually, I'd like to get the .deb packages into a valid repo format... unfortunately, I don't know how to automate that using the bintray upload tasks in the gradle file.

[SageWizdom]

Originally Posted by stuckless

The following url is a url that links to the latest version download area
https://bintray.com/opensagetv/saget..._latestVersion

I'm open to suggestions on how to the buildnumber.txt. As long as we can fully automate it (I don't manually upload the builds), I'm ok with making changes.

Eventually, I'd like to get the .deb packages into a valid repo format... unfortunately, I don't know how to automate that using the bintray upload tasks in the gradle file.

Awesome. Its a bit late tonight to play with this, but hopefully tomorrow I'll find some time. I'm decidedly a fan of "fully automate it." I'll start with this and see how far I can get. Thanks.

[dtox86]

Is there a way to remove needing to allow administrator privileges when the program is run? It's setting off the User Account Control for Win (running 10) and I don't really think I need it to. Previous versions haven't and I'm ok with it.
Unless there's some sinister conspiracy going on behind the scenes I should know about....

[Taddeusz]

Originally Posted by dtox86

Is there a way to remove needing to allow administrator privileges when the program is run? It's setting off the User Account Control for Win (running 10) and I don't really think I need it to. Previous versions haven't and I'm ok with it.
Unless there's some sinister conspiracy going on behind the scenes I should know about....

I agree with this. I think the problem with the registry possibly might be a permissions issue. This hypothesis needs to be verified of course.

[jusjoken]

Originally Posted by dtox86

Is there a way to remove needing to allow administrator privileges when the program is run? It's setting off the User Account Control for Win (running 10) and I don't really think I need it to. Previous versions haven't and I'm ok with it.
Unless there's some sinister conspiracy going on behind the scenes I should know about....

Client/Server ? Which one or both ?

The EXE's have been updated with a manifest to force needing elevated privileges in order to ensure the EXE can read/write the proper registry keys.

Previous versions would have failed to read/write from the registry and likely eventually caused issues if any of those values were needed.

k

[jusjoken]

Originally Posted by Taddeusz

I agree with this. I think the problem with the registry possibly might be a permissions issue. This hypothesis needs to be verified of course.

It is most definitely a permissions issue and resolved by mimicking V7 manifest change to enforce needing Admin privileges. There are certainly other ways to change the code in SageTV Client/Server to resolve this but in theory V7 had the same manifest built in.

I personally think this is no issue on a Server but I agree it should not be needed on the Client....however, something would need to be changed in the code to handle reading heap values for the Client if the manifest was reverted back.

k

[Taddeusz]

Originally Posted by jusjoken

It is most definitely a permissions issue and resolved by mimicking V7 manifest change to enforce needing Admin privileges. There are certainly other ways to change the code in SageTV Client/Server to resolve this but in theory V7 had the same manifest built in.

I personally think this is no issue on a Server but I agree it should not be needed on the Client....however, something would need to be changed in the code to handle reading heap values for the Client if the manifest was reverted back.

k

What I meant are the registry permissions.

[jusjoken]

Originally Posted by Taddeusz

What I meant are the registry permissions.

Are you suggesting there is another way to resolve the registry permissions without the manifest change for the exe? I am open to suggestions.

[Taddeusz]

Originally Posted by jusjoken

Are you suggesting there is another way to resolve the registry permissions without the manifest change for the exe? I am open to suggestions.

Ok, doing some research it appears that apps now need an access control set to access the registry. I no longer have the Windows build environment set up to try and test this:

https://msdn.microsoft.com/en-us/lib...ontrol.aspx#Y0

[jusjoken]

Originally Posted by Taddeusz

Ok, doing some research it appears that apps now need an access control set to access the registry. I no longer have the Windows build environment set up to try and test this:

https://msdn.microsoft.com/en-us/lib...ontrol.aspx#Y0

Interesting but this solution changes the model used from HKLM to HKCU which would mean each user on the machine would need a separate set of keys and potentially different values created.

Not sure we want to go to different registry values per user but i guess thats what a discussion is for...to see how others feel about the approach.

BTW...not sure i would be taking this type of change on right now.

k

[Fuzzy]

Originally Posted by jusjoken

Interesting but this solution changes the model used from HKLM to HKCU which would mean each user on the machine would need a separate set of keys and potentially different values created.

Not sure we want to go to different registry values per user but i guess thats what a discussion is for...to see how others feel about the approach.

BTW...not sure i would be taking this type of change on right now.

k

I'm pretty sure user level programs can READ HKLM just fine, they just can't write to it without administrator privileges. This really means that the only thing that'd really need administrator would be the installer, and the SageTVServiceControl.exe (which if we add the heap settings there, would be super clean). SageTVService.exe, SageTV.exe, and SageTVClient.exe should all be able to operate non-elevated, and should still be able to read the HKLM keys to get their heap values (as well as the other registry based items).

[jusjoken]

Originally Posted by Fuzzy

I'm pretty sure user level programs can READ HKLM just fine, they just can't write to it without administrator privileges. This really means that the only thing that'd really need administrator would be the installer, and the SageTVServiceControl.exe (which if we add the heap settings there, would be super clean). SageTVService.exe, SageTV.exe, and SageTVClient.exe should all be able to operate non-elevated, and should still be able to read the HKLM keys to get their heap values (as well as the other registry based items).

The key there is "should". In practice so far that has not been the case. Some users even manually created the heap info and Sage would not read it. As well there are reports of Sage not reading the capture card entries either until we elevated the EXE's.

However, I agree that it should be able to so when I have time I will play with the installer creating and setting permissions to the HKLM entries and see if that can allow us to remove the manifests that force the EXE to be elevated.

k

[Taddeusz]

Originally Posted by jusjoken

The key there is "should". In practice so far that has not been the case. Some users even manually created the heap info and Sage would not read it. As well there are reports of Sage not reading the capture card entries either until we elevated the EXE's.

However, I agree that it should be able to so when I have time I will play with the installer creating and setting permissions to the HKLM entries and see if that can allow us to remove the manifests that force the EXE to be elevated.

k

I have not tried but I bet these EXE's will work fine without elevation prior to Windows 8. I think the problem will only be on systems with Windows 8 or newer.

[phantomii]

I had issues with SageTV reading both the Java Heap as well as my capture card values from the registry and I am on Windows 7. I am not sure what all the Manifest changes are that are being discussed but my general feeling are "Don't mess with it if it ain't broke" and for me at least, things are working just fine at this point. Just one man's opinion......

[Fuzzy]

Originally Posted by jusjoken

The key there is "should". In practice so far that has not been the case. Some users even manually created the heap info and Sage would not read it. As well there are reports of Sage not reading the capture card entries either until we elevated the EXE's.

However, I agree that it should be able to so when I have time I will play with the installer creating and setting permissions to the HKLM entries and see if that can allow us to remove the manifests that force the EXE to be elevated.

k

I believe the issue is that the launcher is trying to open the key as full access (KEY_ALL_ACCESS) - it is actually trying to create the key, using RegCreateKeyEx, which will create the key or simply opening the key if it already exists. I'm guessing that this is causing the key to simply not get opened, because it cannot obtain the ALL_ACCESS permissions, so since the key cannot be opened, it cannot be read. If we rewrite the registry code in launcher.cpp to only use RegOpenEx with KEY_READ permissions, it may work without elevation (obviously, the keys would need to be read elsewhere, or at the very least, if the key doesn't exist, the launcher should just use the default value (currently, it sets the key to the default).

[wnjj]

Originally Posted by Fuzzy

I believe the issue is that the launcher is trying to open the key as full access (KEY_ALL_ACCESS) - it is actually trying to create the key, using RegCreateKeyEx, which will create the key or simply opening the key if it already exists. I'm guessing that this is causing the key to simply not get opened, because it cannot obtain the ALL_ACCESS permissions, so since the key cannot be opened, it cannot be read. If we rewrite the registry code in launcher.cpp to only use RegOpenEx with KEY_READ permissions, it may work without elevation (obviously, the keys would need to be read elsewhere, or at the very least, if the key doesn't exist, the launcher should just use the default value (currently, it sets the key to the default).

There are calls from some of the native code that use KEY_ALL_ACCESS too.

[Fuzzy]

Originally Posted by wnjj

There are calls from some of the native code that use KEY_ALL_ACCESS too.

Those would need to be changed as well. I really can't imagine any that need it, assuming keys are created by the installer or the service control exe. Just good practice would be to avoid using ALL ACCESS when READ would suffice.

[jusjoken]

Originally Posted by Fuzzy

Those would need to be changed as well. I really can't imagine any that need it, assuming keys are created by the installer or the service control exe. Just good practice would be to avoid using ALL ACCESS when READ would suffice.

I have resolved the permissions issue by having the installer create the top level Frey entry with full control to the user "Everyone". I removed the manifest changes forcing the Client and Server to run as Administrator and both applications read and write properly to the entire tree under the top level Frey entry.

At this time I think this is the best approach to resolve this. Eventually someone can look into doing something different in the code for any/all of the registry entries but the cleanest change for me is to do this in the installer and return the Client and Server EXE's to not requiring elevation.

PS: I will leave the Service Control needing elevation as it needs elevation to make changes to the service settings.

I will create another pull request to under the Manifest changes for the Server/Server Service/Client and the next installer release will include these changes.

k

[stuckless]

FYI... I did update the sagetv binaries (and jar)... There were a couple of updates this week for linux and ffmpeg..

[rerooks]

Is there a way to set that shortcut to be pre-authorized for administrator, so we don't need to type in the administrator password every time we launch sage?