2.1 info about *.properties files??

[zoundz]

For those of us who upgraded from 2.0 to 2.1, I wonder if Jeff or someone could post something in the FAQ about which parameters are now used from Sage.properties and which ones are used from SageClient.properties. There are a lot of presumably left over parameters in Sage.properties that are not used by the server anymore and likewise for SageClient.properties. There are so many parameter lines that it would be nice to clean out the vestigial ones from Sage.properties and SageClient.properties. Obviously they aren't causing problems, but they are cluttering up the files and are a potential cause of confusion. It would be very useful to know which ones are used where.

Additionally, I find that I am confused about the usage of the mmc/python2_encoding lines versus the seeker/recording_qualities lines. Perhaps someone can explain the relationship between these two. I'm feeling awfully dense about this, but either I'm RT-wrong-FM or I just haven't found the right FM.

Thanks

[korben_dallas]

Same here. I was looking through those files last night trying to track down a few issues, but I can't tell which one takes precedence.

I'm not really understanding why the Sage service uses sage.properties while the UI uses sageclient.properties, and obviously some lines are ignored in one or the other.

[mls]

When you run with the service it will make a copy of the properties file as the sageclient.properties file. This file would not be there (and not be needed) if you were not using the service. When you run the service the UI actually is acting the same as if you had installed the SageTV Client software (in other words, it's running as its own client).

I doubt there are any lines in the properties file you could actually remove because SageTV would just put back in its own default lines again the next time it starts. I suspect the same might happen if you try to remove any lines from the sageclient.properties file, but not sure if all the other stuff will come back on its own or not.

I don't run the service (and never will), but I find it more interesting not running that way. You start up one instance of SageTV and then create another shortcut icon for "sagetv.exe -client". This then starts a 2nd instance of SageTV as a client.

Then you can resize the 2nd one and use it for picture-in-picture (or just a 2nd view of other things like the EPG). This of course does create a sageclient.properties file also, but the 2 instances of SageTV run seperate from each other this way so you can change serveral things seperately for each (such as using one STV for one, and a different one for the other). This is much more fun (and more usefull) than running with the service.

Anyway, I doubt you can actually remove much of anything from either file if your running the service. As to what is used by each file... well that's still kind of confusing, but basically the sageclient.properties should control anything for display settings, while the sagetv.properties file should control everything else.

[Opus4]

I don't really have a list of which properties are _only_ used by the service or the UI, but if you consider which ones affect how SageTV is displayed or how you interact with it (FF times, fonts, etc), those would go with the UI. The properties that describe how things get recorded, when the EPG is updated, and so on, would go with the service. If you are running the service, the UI takes its initial settings from sage.properties, I believe, and it would also revert to using sage.properties if you stop using the service, so I'm not sure there is mucch point in removing settings from either file.

As for the properties for recording quality settings, see chapter 8 in the v2.1 manual. You should find that only one set of those lines are used now.

- Andy

[zoundz]

As for the properties for recording quality settings, see chapter 8 in the v2.1 manual. You should find that only one set of those lines are used now.

Thanks. I missed that one line in the chapter that didn't seem all that relevant. <g>

That being the case, can we delete the seeker/recording_qualities lines from the files? Can I also assume that all the divx and mpeg4 lines are not displayed as options because they are not usable in my configuration?

[zoundz]

Originally Posted by mls

When you run with the service it will make a copy of the properties file as the sageclient.properties file. This file would not be there (and not be needed) if you were not using the service. When you run the service the UI actually is acting the same as if you had installed the SageTV Client software (in other words, it's running as its own client).

Eeeeek. Are you sure of this or did you just make it up. Are you saying that when I start the service it copies Sage.properties to SageClient.properties? Or is this misinformation? My SageClient.properties file has many many lines from various custom stv's that do not exist in my Sage.properties file. There are numerous parameters that are contained in both files but have different values. Now I am thoroughly confused about what the reality actually is.

[ToxMox]

Originally Posted by zoundz

Eeeeek. Are you sure of this or did you just make it up. Are you saying that when I start the service it copies Sage.properties to SageClient.properties? Or is this misinformation? My SageClient.properties file has many many lines from various custom stv's that do not exist in my Sage.properties file. There are numerous parameters that are contained in both files but have different values. Now I am thoroughly confused about what the reality actually is.

I think Opus meant the first time it generates the sageclient.properties file it copies the sage.properties to create it.

[mls]

I believe the klinker is that the very first time you run with the service it creates the sageclient.properties file. I don't know if it ever bothers updated it with anything from the original .properties file on any runs after that. I also believe that's why some people are having so many problems with the service, because some changes are not getting transferred between the files properly.

This is all just a guess of course based on what I've read from the manual, FAQ's, and other posts in the forum. All I can tell you for sure as that if you have never run the service the sageclient.properties file is not there (which makes it a lot easier to work with things since you only have one .properties file to deal with).

Going the other way, I have no idea what it might do or how it would behave if you turn off the service later, since then it would already have created the sageclient.properties file. In that case, some settings may be different between the 2 files and I don't know if it knows how to properly combine them back into one, or if it still tries to use both of them.

Anyway, using the service is just to confusing for me and having no real to use it myself (and never will) I haven't bother testing anything with the service to figure out how it behaves with any changes between those files.

[Opus4]

zoundz: ToxMox was right: I meant that the service uses sage.properties. The first time the UI portion is run, if it doesn't find sageclient.properties, then it takes its initial settings from sage.properties. Each file is updated with its appropriate properties. Just like when running a regular client, the UI uses the client properties file for all of its customizations. Those UI-specific customizations will ONLY go to that prop file, as far as I know, since that is what the client does. As I mentioned above, props that affect the core server (the service in this case), go to its prop file: sage.properties. If you are manually editing the props & don't know which one it belongs in, simply close the UI & the service & change them both. Just remember: the service has NO UI (no STV is used at all) and does not use the client property file at all, which is why you can just shut down the UI portion if you wish to change a UI feature.

Look at it this way: If you are running the service, you don't even need to run the UI on that PC. You could leave the service to run on its own and run a client ONLY on another PC. You will have the same situation here: the service uses sage.properties and the client uses sageclient.properties. The service + UI on one PC keeps things just as distinct.

You can remove those unused recording quality properties; they are no longer used. Only a single property line is used for each quality setting & they don't need to be in the client properties file. I'm currently travelling, so I can't look up details too easily.

Only the recording qualities that your capture cards can use will be displayed, so that is why you don't see the DivX & such qualities listed.

As sort-of mentioned above, if you stop using the service, then SageTV handles both the core AND UI functionality and will use sage.properties for ALL of its properties. If some UI property is not listed there or has never been changed in that file, its default value will be used, not some customization in the client prop file.

- Andy

[zoundz]

Originally Posted by Opus4

The first time the UI portion is run, if it doesn't find sageclient.properties, then it takes its initial settings from sage.properties. Each file is updated with its appropriate properties. Just like when running a regular client, the UI uses the client properties file for all of its customizations.
<snip>
You can remove those unused recording quality properties; they are no longer used. Only a single property line is used for each quality setting & they don't need to be in the client properties file.

Thanks. That clears up a lot of it. It makes more sense to me that the client would make the copy. I'm not really a neatness freak, but having lots of vestigial stuff around to cause confusion always bothers me. I guess I'll try to clean up the 2 files and see if I can manage to break the whole magilla <g>

FWIW, it still might be useful to know which properties are service, which are client and which, if any, are both. Obviously, any that have the name of an stv at the beginning are client, but even then, as the various stv's have been flying, I suspect that there are a lot of leftovers. I'm using Cayars and that incorporates a lot of stuff from the other stv's, most of which I tried earlier on. The result in the .properties file is incomprehensible madness. Maybe Carlo can let us know what properties he's using at some point, too.

Now all I need is time to watch all the stuff I record <g>

[Cayars]

Originally Posted by zoundz

Thanks. That clears up a lot of it. It makes more sense to me that the client would make the copy. I'm not really a neatness freak, but having lots of vestigial stuff around to cause confusion always bothers me. I guess I'll try to clean up the 2 files and see if I can manage to break the whole magilla <g>

FWIW, it still might be useful to know which properties are service, which are client and which, if any, are both. Obviously, any that have the name of an stv at the beginning are client, but even then, as the various stv's have been flying, I suspect that there are a lot of leftovers. I'm using Cayars and that incorporates a lot of stuff from the other stv's, most of which I tried earlier on. The result in the .properties file is incomprehensible madness. Maybe Carlo can let us know what properties he's using at some point, too.

Now all I need is time to watch all the stuff I record <g>

There are all the entries that start with "Cayars/" and then others. Actually, I've thought about going through the whole STV and making everything non-originalV2.stv start with "Cayars/" but then this will cause people to have to reset up certain things. Good and Bad. The good thing is that it would be more obvious which other items could be removed. It would also allow you to remove all the Cayars entries if you switched STVs.