ola
ola copied to clipboard
OpenLightingProject
Save port patchings immediately rather than on shutdown
From nomis52 on October 21, 2010 08:05:49
If we only save on shutdown, the patchings aren't saved correctly if olad crashes which is annoying during development.
This needs to be done asynchronously though so we don't block dmx processing while waiting on disk writes.
Original issue: http://code.google.com/p/open-lighting/issues/detail?id=124
From [email protected] on October 21, 2011 08:29:33
Labels: -Milestone-Release0.8.13 Milestone-Release0.8.14
Any news on this enhancement ? I have been using OLA with nard, which is something meant to be used as a device that doesn't require shutdowns, and it's a problem when the universe patches aren't saved when when created.
I realize that it would be beneficial that the save procedure happens in a separate thread in order to not impact dmx, but as a quick hack in the meanwhile couldn't we use a cmd line switch to enable this feature (explicitly explaining it's possible causes) and save it anyway in OladHTTPServer::CreateNewUniverse ?
Something like:
--save-on-demand Saves settings immediately after configuration changes through the UI but may cause DMX flicker
and on OladHTTPServer::CreateNewUniverse
...
if(save_on_demand_flag) {
m_server->savePreferences();
m_server->saveUniversePreferences();
}
...
Hi @rbarreiros it's been on our GSoC list in the past, but never been picked by anyone.
It'd probably be a question for @nomis52 if something "hacky" like that makes it in, but given the relevant triviality, you could always create a PR and see. Likewise we'd value any help in adding the separate thread to do it in. The best solution for the hack may be to only expose the option if a configure flag is added, like the root stuff: https://github.com/OpenLightingProject/ola/blob/master/configure.ac#L683
I think trying to find a way to have options saved without flicker would be ideal. Loading and saving config in a separate temporary thread seems not too difficult to implement.
If that is not possible, then I also think it would be reasonable (though obviously not the most ideal) for changes from the web UI to be saved immediately (possibly with flicker) but changes via API would not be saved (and thus not flicker). A change from the UI is manual intervention from a human that is less likely to occur in a live installation.
As seen in #1856 a more unfortunate side effect of not saving options until exit is that changing preferences and restarting/reloading OLA is not possible if OLA is already running. This overwriting bit is not very user-intuitive. Not all options are configurable via web UI.
Another way to deal with the override issue is to simply not save if the config files have changed since OLA started, but this is less ideal.
The ability to reload settings/plugins on the fly (i.e. sending a SIGHUP or systemctl reload olad) would also be really nice.
