Sage.properties

[KryptoNyte]

What exactly is the logic behind not being able to make [live] changes to the Sage.properties while SageTV service is running?

Is it some kind of programmatic safety feature?

[BobPhoenix]

Originally Posted by KryptoNyte

What exactly is the logic behind not being able to make [live] changes to the Sage.properties while SageTV service is running?

Is it some kind of programmatic safety feature?

The properties are read into memory. So if you change a setting from within SageTV it is not saved to disk right away. If you make a change to the text file it could be after one of those changes so it can't be reread from disk until the current memory settings are saved so you cannot edit them until SageTV is stopped.

Now you could create a plugin that would allow you to edit the memory properties from within SageTV but some of them are only read and referenced when SageTV is booted so any of those properties would not change anything even if you did write a plugin for this. So the best option is to exit SageTV and make your changes and then restart it.

[KryptoNyte]

Couldn't SageTV just re-read the properties file into memory when it detects a change in the file? I was thinking the reason would be more elaborate ... or possibly, more simplistic.

[EnterNoEscape]

Technically it could be editable live, but it adds a new level of complexity to the code and it might be hard to tell what the intent is at times. There would be many problems to overcome.

The first one that comes to mind is if you make a change to the file, then SageTV makes a change, which one should persist? Would SageTV always read everything from the file directly and write out the file every time any changes happen? You can't go by the timing of the changes because after you opened the file, maybe some things changed that you were not editing, but when you saved it, you changed them back to their old values. How would SageTV know you didn't mean to do that?

Another problem would be what if your editor is in the middle of writing the file out and several properties are missing at that moment. SageTV knows those values need to be in the file and would at the very least try to write them out or your configuration will not persist, but your editor is also writing the same file at the same time which will almost certainly corrupt the file.

The API has methods to write to the properties in a much more controlled manner whereby intent should be much clearer to SageTV. A plugin could make indirect editing a possibility, but it's worth noting that a lot of the properties not exposed somewhere to the UI require restarting SageTV to take effect anyway.

[stuckless]

As BobPhoenix suggested, I think a plugin (or web frontend) that modified the in-memory state of a property, would be the best option... but even with that, there are properties that likely only ever get read once, and changing it in memory wouldn't have any effect.

As I'm working on a new web frontend (very slowly ) have a "properties editor" in much the same way that BMT has it's properties editor, is on my list, since I hate having to shut down the server to tweak various logging settings, etc.

[KryptoNyte]

Originally Posted by stuckless

... since I hate having to shut down the server to tweak various logging settings, etc.

Yeah, that's pretty much it.

Originally Posted by EnterNoEscape

... but it's worth noting that a lot of the properties not exposed somewhere to the UI require restarting SageTV to take effect anyway.

I guess that's the issue that would be most concerning. I suppose the on-the-fly changes would have to be limited to just properties that wouldn't require a restart. Might be a real challenge to determine which properties would apply.

[CollegeProject]

Originally Posted by KryptoNyte

Yeah, that's pretty much it.



I guess that's the issue that would be most concerning. I suppose the on-the-fly changes would have to be limited to just properties that wouldn't require a restart. Might be a real challenge to determine which properties would apply.

The biggest issue is like others said many properties are only read once by the UI or at given intervals. So just because you immediately update a property doesn't mean it will be immediate effect.

[KryptoNyte]

In my simple non-programmer mind, it leads me to think there could be a Sage.Properties1 and a Sage.Properties2 file. The 1 file couldn't be edited on the fly as it would contain properties that would require a complete Sage restart, while the 2 file would have properties that could be altered on the fly.

Because we're here in the V9 development forum, I was thinking the interval for reading the 2 file might be altered to occur every time the 2 file experiences a change. I understand there is probably a more elegant way to achieve this, but not sure it's worth anyone's time with far more pressing issues.

Just wondering I guess.

[Fuzzy]

You need to describe WHAT you intend to be changing, because not all properties are handled the same. Changing the property in the file, or even directly in memory, may have zero effect on sage if sage is running, and changing this behavior would involve changing a LOT of the core code in sagetv, and each individual property would need to be looked at and changes made to handle that property explicitly. It's simply not worth the trouble and potential problems.

[stuckless]

Originally Posted by Fuzzy

You need to describe WHAT you intend to be changing, because not all properties are handled the same. Changing the property in the file, or even directly in memory, may have zero effect on sage if sage is running, and changing this behavior would involve changing a LOT of the core code in sagetv, and each individual property would need to be looked at and changes made to handle that property explicitly. It's simply not worth the trouble and potential problems.

I agree it wouldn't be easy, but, none the less, it's something that could be "tweaked" incrementatally to provide a better experience.

Phoenix, while it uses Sage.properties, actually wraps everything in it's own accessor methods. Phoenix also uses an xml configuration metadata (or java annotations) so that each property is not just a piece of text, but rather it has information like a description, data type, list of values, etc. Phoenix support allowing plugins to register event listeners on property changes. And because it's all defined in metadata, the UI in BMT for editing properties is completely dynamically generated based on the metadata for each property. it also supports property groups, so that things can be better organized, etc. My point in sharing this, is that, from day one, I found the Sage.properties to be somewhat limiting and in phoenix, it just extended the behaviour.

BMT/Phoenix actually exposes some Sage properties via this mechanism (like the debug logging), but you still need to reboot for it to take effect, but, at least you can do it all remotely, and not have to manually edit the file.

I don't think it's feasible to blindly edit the Sage.properties in memory, but I do think that properties can be classified and exposed via some other mechanism, like bmt, to make editing some properties more intuitive, and possibly the metadata could be extended to include a "need reboot" flag to indicate if changing a property would not take effect until a reboot happens. None of this really requires any programming, just some grunt work to find the interesting properties and add them to the Sage.xml configuration metadata.

[VCRUser]

Is there any documentation on what the various properties mean? I've found occasional references to certain ones, but nothing comprehensive.

[stuckless]

Originally Posted by VCRUser

Is there any documentation on what the various properties mean? I've found occasional references to certain ones, but nothing comprehensive.

Likely not. I'd say the best bet is to search the forums for the property, and if you find nothing, then just ask question, hopefully someone knows

[VCRUser]

Originally Posted by stuckless

Likely not. I'd say the best bet is to search the forums for the property, and if you find nothing, then just ask question, hopefully someone knows

Though the more likely scenario is not knowing what the specific property is, but knowing that you want to change or fix something and don't know what property, if any, could be changed to accomplish that - at least that's the case for me! A list of properties and what they do might at least provide a clue where to look.

[EnterNoEscape]

Originally Posted by VCRUser

Though the more likely scenario is not knowing what the specific property is, but knowing that you want to change or fix something and don't know what property, if any, could be changed to accomplish that - at least that's the case for me! A list of properties and what they do might at least provide a clue where to look.

There are a few problems with this line of thought:

The first one is one that I have run into with my own software. I typed up notes about most of the properties in the program, but over time some of those have changed or been moved. I then have a problem where the notes now mention things like if you have this version, you'll see this or that version you'll see something else. I moved to making the properties described through a JSON accessed interface that has yet to actually be used because it is easier than trying to maintain some notes that will inevitably be inaccurate if I forgot to to update them. Basically sometimes properties are no longer used or have changed a little in meaning and having a document can actually make things even more confusing.

The second problem is that even when properties are described, many of them are still kind of unclear without having some understanding about the code path they modify or greater understand of the bigger picture and the role of the property, so even with a very good description you might still not know if it will help you or not. Also, some properties should never be changed by hand.

The third problem is kind of started by the second problem. There are so many properties you are more likely to try to search the list by key words and might never find the one that will help you out most because you don't know what the problem you're seeing is generally called which will lead back to posting in the forums and someone suggesting that you try changing a specific property somewhat negating that we have a list.

[RobJ]

Originally Posted by stuckless

Likely not. I'd say the best bet is to search the forums for the property, and if you find nothing, then just ask question, hopefully someone knows

Originally Posted by VCRUser

Though the more likely scenario is not knowing what the specific property is, but knowing that you want to change or fix something and don't know what property, if any, could be changed to accomplish that - at least that's the case for me! A list of properties and what they do might at least provide a clue where to look.

I suspect there still is not a list of all the settings in sage.properties. In searching the file, I found seeker/disable_video_directory_verifications, currently set to false, but cannot find any mentions of it anywhere. What I am looking for is a setting that would allow me to turn off the System Messages about network drives not available ("Recording directory offline"), as I have to constantly delete about a dozen of them, over and over. I leave certain servers and machines turned off much of the time, and only turn them on when I want them. I record to local drives, and only occasionally turn a server on and move recordings over to it, then usually shut it back down.

So does anyone know what seeker/disable_video_directory_verifications does, and if it would help me? Or is there another setting I should have found? (It looks just dangerous enough that I'd rather not turn it on to test.)

[wnjj]

Originally Posted by RobJ

I suspect there still is not a list of all the settings in sage.properties. In searching the file, I found seeker/disable_video_directory_verifications, currently set to false, but cannot find any mentions of it anywhere. What I am looking for is a setting that would allow me to turn off the System Messages about network drives not available ("Recording directory offline"), as I have to constantly delete about a dozen of them, over and over. I leave certain servers and machines turned off much of the time, and only turn them on when I want them. I record to local drives, and only occasionally turn a server on and move recordings over to it, then usually shut it back down.

So does anyone know what seeker/disable_video_directory_verifications does, and if it would help me? Or is there another setting I should have found? (It looks just dangerous enough that I'd rather not turn it on to test.)

Here is the code that generates the recording directory offline warning message. I don’t see any property to suppress it.
https://github.com/google/sagetv/blo...va#L3112-L3126