mcrossley wrote: ↑Tue 03 Dec 2019 11:36 amYou *can* clean it up and make it sequential (purely for ease of human reading) by renaming Cumulus.ini to something like Cumulsu.ini.bak whilst MX is running, and then either making a minor change to a config item (and reversing it), or shutting down MX. It will then write out a new Cumulus.ini in a logical order.
Tried this yesterday; copied my entire MX directory to another PC & carried it out there.
Simply renamed the INI while MX was running then shut MX down.
Interesting when I compare the 2 files with diffMerge, (Thx BetelJuice), there is a very big difference in the placement of the data blocks & also the position of the entries within those blocks. Not sure whether that would impact at all on timings, or potential errors from the previous; that's one only for the programmers.
My original ini still contains some Cumulus 1 entries also that can probably be dispensed with, particularly references to EasyWeather.
Might look at rebuilding my ini file from scratch, as the only notable changes seem to be the omission of the Com3 entry (as the station did not connect)
& the enrty for LastLoggerDownload.
Is the above entry the only one that changes when MX is Started & stopped without config changes, or are there other entries to consider?
Adding the ini file to backup is a good idea.
Unfortunately the added above backup didn't help me in this case as the copy I required had expired but the time I discovered the issue.
Is an ini setting for
number of backups number of days backups are retained feasible, given that MX is often unattended for long periods?
In the mean time I might just schedule a task to copy them out of where they live & let them accumulate in another folder.
(And again search for a decent Win8 backup replacement).
Cheers
Phil.