PrintTimeGenius Causing UI Reloads

[TheKrush]

Before reporting, check if your problem is here:
https://github.com/eyal0/OctoPrint-PrintTimeGenius/wiki/Common-problems

Please fill this out:

OctoPrint Version: 1.3.11

PrintTimeGenius Version (if you know): 2.0.1

What did you try:

What happened: Seems PTG is causing the UI to need reloads

What did you expect to happen: The UI to not need a reload due to changes to the config

If relevant, upload the PrintTimeGenius log and any problematic gcode files (you might need to rename them).

Here are the changes to the config that I believe is causing the UI to need a reload.

[eyal0]

I have not seen this before. What do you mean that "the UI needs a reload"?

[TheKrush]

It gives that message about how the system has changed and needs to reload the interface, but the printers / octoprint never went offline and the only thing that happened was a print with I'm guessing these updated PTG modifications to the config. (it was mentioned in something I found online a similar issue was happening with the Telegram plugin because it had a timestamp related to images)

[eyal0]

That's interesting. Usually the system requires a reload after new plugin is installed, such as PTG. But not when the config changes. PTG changes the config after each successful print. Are you seeing the notice about a reload after every print?

[TheKrush]

Not every print usually when I haven't looked at it after some prints that had downtime after them, perhaps it's not doing it's processing when I'm actively swapping prints quickly but when I leave gaps it does some more processing?

Also possible it's something else, but I hadn't seen any config changes other than PTG.

[eyal0]

It says a new version of the server. Maybe it's OctoPrint itself that is updating? You could look at OctoPrint's version number and then wait until it happens again and then see if the version number has changed.

Maybe there is some configuration that you set that causes you to always get automatic updates to the latest OctoPrint, so you get them more frequently?

[TheKrush]

It's definitely not octoprint I manually update and I'm currently on the latest (just did a re-image to get up to 0.16.0 OctoPi as well). I'll backup my config and look at it next next time this occurs and see what it says was changed, but I'm pretty sure any config changes are triggering UI reloads.

[TheKrush]

OctoPrint/OctoPrint#2950 Here's the issue where another plugin was causing it.

OctoPrint/OctoPrint#2950 (comment) This comment is saying any config changes triggers a UI reload:

https://github.com/foosel/OctoPrint/blob/8409fdaa48ff692bbb050086e8d7c09940b58c59/src/octoprint/static/js/app/dataupdater.js#L197

            // if the version, the plugin hash or the config hash changed, we
            // want the user to reload the UI since it might be stale now
            var versionChanged = oldVersion !== VERSION;
            var pluginsChanged = oldPluginHash !== undefined && oldPluginHash !== self._pluginHash;
            var configChanged = oldConfigHash !== undefined && oldConfigHash !== self._configHash;
            if (versionChanged || pluginsChanged || configChanged) {
                showReloadOverlay();
            }

This is inside a self._onConnectMessage which might explain why I only see it after leaving the computer for a while or having it run in the background because my connection to octoprint is broken and when I come back it reconnects and then does the configuration check.

Does the print history need to be in the config? Maybe put it elsewhere or give an option to disable it writing it to the config.

[foosel]

Quoting fabianonline/OctoPrint-Telegram#156 (comment):

As a side note, the settings are really the wrong place to store volatile data (e.g. a constantly changing URL with a cache buster).

Take a look at the data directory maybe, or the file metadata?

[eyal0]

Nice catch. This is probably the problem.

@foosel What is the right way to access to the data directory? For settings, I use octoprint.plugin.SettingsPlugin. This makes sure that my settings don't interfere with other plugin settings. Is there something similar for plugins using the data directory?

Also, when did this reload issue appear? I never noticed it before in older versions.

[foosel]

It's not an issue, it's a feature and has been in there for years at this point 🤷‍♀️ Config changes can influence the UI, hence it asks you to reload said UI if the config changes. That's all.

As for the data folder, see http://docs.octoprint.org/en/master/modules/plugin.html#octoprint.plugin.types.OctoPrintPlugin.get_plugin_data_folder - your plugin implementation automatically has that.

And for file metadata see http://docs.octoprint.org/en/master/modules/filemanager.html#octoprint.filemanager.storage.StorageInterface.get_metadata and http://docs.octoprint.org/en/master/modules/filemanager.html#octoprint.filemanager.storage.StorageInterface.set_additional_metadata

[eyal0]

@foosel Thanks for your quick response! That looks like it'll work.

The data that I need to store is of the 5 most recent prints. I don't think that storing it in the metadata attached to the file is a good idea because if the file is deleted, the data is lost. And also, I need to be able to access it all at once. So I will store it in the data directory.

get_plugin_data_folder() seems like a good choice and I can continue to maintain the yaml format. Maybe I will use the opportunity to add a version number to the data, too, for easier migrations in the future!

[foosel]

Ah, yeah, if historic data irrelevant to currently existing files in the system is needed, then the data folder is the right way forward.

And I can only strongly recommend using a version number somewhere in the data scheme - it can safe you from a TON of grey hair 😅

[eyal0]

If you're willing to try this, you can install it using this link: https://github.com/eyal0/OctoPrint-PrintTimeGenius/archive/data_dir.zip

You can install it from the plugin installation dialog within OctoPrint. Just put in the above URL. If you're able to test it out and see if it solves your problem, I would appreciate that. And then I'll make a new release with this fix.

Please also test the PTG settings where it's possible to remove rows. That ought to work, too.

[TheKrush]

I'll give it a go tomorrow night.

[eyal0]

BTW, the print_history will not longer be in ~/.octoprint/config.yaml, it will now be in ~/.octoprint/data/PrintTimeGenius/print_history.yaml. The format is mostly unchanged. You may continue to see a print_history inside your config.yaml file but it is unused. There is no migration from config.yaml to the new file so your print_history will start over from 0.

I couldn't figure out how to make the new print_history viewable in the settings directory so you may find that after you print something, it will be added to the history in the file but not in the settings. Reloading the webpage will fix that. I didn't bother to fix this because it's difficult and anyway most people don't much need to go into the settings and view or delete rows from the print_history.

[TheKrush]

It seems to have fixed the issue.

[TheKrush]

I may have spoken too soon, give me a bit to debug this on my end.

[TheKrush]

Well it's not changing the config anymore so I'd say if I still have something causing reloads it isn't this plugin with this change.

[eyal0]

I'm fine with an incremental change, too... Hm, actually, now that I think about it, I am storing the printer's config in there, too. Oy, that sucks. I should be storing it in the data directory, too.

I'll fix that in a separate PR.

At the least, in your testing, do you find that the the saving and storing of print_history is as you expect? That is, after you print, it shows up in the new print_history.yaml file. And when you look in the settings, the rows look right and the delete row button works as expected?

[eyal0]

You say that you're still seeing a reload, and probably because the config is changing. I thought of another place where that might be happening. Want to try another version?

https://github.com/eyal0/OctoPrint-PrintTimeGenius/archive/printer_config_yaml.zip

This moves the printer_config out of the config.yaml file and into a new yaml file in the data directory, similar to what was done for the print_history. This fixes up another place where the config is often modified. Maybe this will solve a problem?

You could also do an ls -l on the .octoprint/config.yaml file to see what the file date is on there. That might give you a clue as to what is doing the updating.

Please try the new code and let me know if it solves the problem. Or causes new one. :-)

[TheKrush]

The reload i saw after installing the new version seems unrelated. I let the printers run overnight and when I checked this morning it didn't have the usualy request to reload so I'd say you fixed it with the version i have.

I'll try the new version tonight and check those files, I hadn't actually paid much attention to the history part of the plugin in the past but I'll give it a once over as well.

[TheKrush]

I'm trying the new thing, I haven't seen any reload prompts. Was there something else you wanted me to look at in this?

[eyal0]

Nope, I think that's it. I'll push a new version soon.

[eyal0]

Actually, maybe you could also look at ~/.octoprint/data/PrintTimeGenius/printer_config.yaml and check that it looks right? I'm feeling pretty good about this latest version. It should save the print history into one file and the printer config into another.

I made a few more cosmetic changes so, just in case, please re-install with the same link and if everything looks fine to you, I'll make it a proper release.

Thanks a bunch!

[eyal0]

You should see your printer's configuration in there, if you have a config. It should have parts of the output of the printer's M503. Not all printers have a stored config, some of them put all the config into the gcode file, so maybe you won't have anything. That's okay, too.

[eyal0]

Fixed by #167

[thisiskeithb]

Thanks for patching this! I didn't have time to track down which plugin was causing the UI refresh requests, but they stopped under each instance I've updated this plugin on.