Issue
Data Monitoring graphs from session S979 didn't use the intended MasterGraph starting time, had used an earlier setting which caused most of the night's data to be missed off the width limited plots.

Description
Data Monitoring graphs from session S979 used an inappropriate MasterGraph starting time (08:30), which caused various plots to not show much of the time based data from the session (22:04 onwards). Problem hit across all plots using a time (hour) based x axis. This including Best Focus, Zenith FWHM, Sky Quality CCD Temperature, Cam2 Temperature plots. 

Analysis
Plots seem to have a starting time (where shown) from 08:30 in the morning, even though session '2022-02-28 S00979' wasn't opened until 22:04.   The log file which was opened at 22:04:49 and shows some initial anomalies. After 'the 'Initialising Session Data' message  the 3 following messages are given  'Session data has been successfully read' , 'SkyConditionsTabNo set to 3' & 'Resuming Session Charts'.  For normal session startup these messages would have been 'Session Data has been written',  'SkyConditionsTabNo set to 1'. 

Shortly after this it would be expected to see the message  'Setting MasterGraphStartTime to 22:00'    and "Setting Graph StartTime to MasterGraphStartTime (22:00).    but instead of that there were messages like  'Setting Graph StartTime to MasterGraphStartTime (08:30)' .  Earlier the general session '2022-02-28' was automatically opened at 08:30 in morning which Set MasterGraphStartTime to 08:30. The AstroMain program was been restarted at 13:39 in order to upgrade to version 3.50.6.  Log file shows 'Reopening Session Charts'  and  'SkyConditionsTabNo set to 2' messages.  

It seem that upon opening the S979 session the Initialise Session Data routine, looked for existing an 'Session.dat' file, but might have looked in the session folder associated with the previous general session (and found one which then read-in) instead of looking for it in the newly created Session folder (where there would normally be one initially).   Since this has being working in all recent sessions and there have been no changes to code in this area, it would seem that there is a timing issue, with the InitialiseSessionData() routine (called from AssignObservatorySession, line 64906) running ahead of things and testing the existance of 'SessionDataFileName' before this file path variable had been set elsewhere with new session details.

SessionDataFileName is set in SetupFileNames() routine. This can be called from 6 code areas.  Only two are relevent in this case - from OpenBaseFiles() and OpenObservatoryFiles(). The former is called when program is initially loaded ,  the latter is called from AssignObservatorySession, line 64849.  This is before the call to InitialiseSessionData() so it seems impossible that theSessionDataFileName wasn't set. 

Session folders were created ok and report indicating that Session.SessionFolder and Session.Name were fully defined before call to OpenObservatoryFiles() & SetupFileNames(). Correct setup of live session filenames depends on Session.IsSelected being True.   If it had been false then all files references would have pointed to incorrect location and mutiple files would be incorrectly located/named and this evidently hasn't happened.  Since there is no explicit or implicit  indication of any exception occuring in SetupFileNames() before the code line setting SessionDataFileName.  

The only remaing hypothesis is that SessionDataFileName was set ok,  but between this point (22:04:49.73) and the call to InitialiseSessionData (at 22:04:49.85), i.e with a 120ms window,   there was an inappropriate call to WriteSessionDataFile() which would have created a session.dat file with MasterGraphStartTime set to the previous setting (08:30).    WriteSessionDataFile() is normally called every 60s or so from the OverseerLoop, so the probability of experiencing this issue was approximately 1 in 500.

Conclusion.  
The source of the issue is considered to be very probably due to a rare (1:500) timing scenario where OverseerLoop operation interferes with Session creation.

Although it is may be a long time before this issue will be seen again, the code should be modified to put a suitable block on the execution of WriteSessionDataFile() whilst a new session is being created in order to prevent this from this occuring.

Actions

Modify code to block execution of WriteSessionDataFile() whilst a new session is being created.       (Completed 2022-03-01)