stacklog.csv showing incorrect date-time

[lowenthalm]

stacklog.csv looks like this:

Date/Time, Frame Index, Frame Stacked?, Detected Star Count, Frame Star Brightness, Frame Star FWHM, Frame Offset X (pixels), Frame Offset Y (pixels), Frame Rotation (degrees), Raw frame file
2023-05-25T03:23:52.8192145-07:00, 1, 1, 32, 121.512, 5.573, 0.000, 0.000, ,
2023-05-25T03:23:52.8201317-07:00, 2, 1, 31, 119.509, 5.766, 2.426, 0.052, -0.016,
2023-05-25T03:23:52.8211352-07:00, 3, 0, 28, 113.128, 6.451, 10.839, 0.073, -0.015,
2023-05-25T03:23:52.8220970-07:00, 4, 1, 33, 117.673, 5.296, 15.468, 1.330, 0.014,
2023-05-25T03:23:52.8234225-07:00, 5, 1, 30, 116.494, 5.523, 15.292, 0.530, -0.008,
2023-05-25T03:23:52.8411935-07:00, 6, 1, 29, 116.731, 5.480, 11.562, 0.751, 0.005,
2023-05-25T03:23:52.8438867-07:00, 7, 1, 29, 117.282, 5.569, 11.504, 0.904, -0.016,
2023-05-25T03:23:52.8455126-07:00, 8, 1, 29, 115.679, 5.880, 18.155, 1.297, 0.013,
2023-05-25T03:23:52.8471951-07:00, 9, 1, 29, 115.108, 5.664, 21.400, 2.030, 0.003,
2023-05-25T03:23:52.8482869-07:00, 10, 1, 31, 117.436, 5.660, 19.457, 2.612, 0.016,
2023-05-25T03:23:52.8494744-07:00, 11, 0, 30, 114.892, 6.074, 16.421, 3.676, -0.032,
2023-05-25T03:23:52.8503678-07:00, 12, 1, 30, 116.581, 5.838, 9.653, 3.413, 0.012,
2023-05-25T03:23:52.8510968-07:00, 13, 1, 29, 115.318, 5.702, 10.700, 2.645, -0.032,
2023-05-25T03:23:52.8519465-07:00, 14, 0, 28, 113.662, 6.392, 11.803, 4.343, -0.032,
...
7 minutes of stacking worth of data...
...
2023-05-25T03:23:53.0472159-07:00, 115, 0, 30, 221.812, 6.702, 175.843, 39.663, -0.042,
2023-05-25T03:23:53.0483713-07:00, 116, 0, 32, 223.887, 6.232, 184.040, 41.023, -0.022,
2023-05-25T03:23:53.0499584-07:00, 117, 1, 33, 220.009, 5.824, 186.388, 40.824, 0.002,
2023-05-25T03:23:53.0512493-07:00, 118, 1, 32, 219.751, 5.998, 185.285, 41.918, -0.012,
2023-05-25T03:23:53.0523010-07:00, 119, 1, 32, 220.125, 5.928, 179.413, 41.385, 0.033,
2023-05-25T03:23:53.0532228-07:00, 120, 1, 34, 221.779, 5.721, 182.075, 42.703, -0.026,
EOF

The information is definitely useful. However, these are 6 second subs. The time from row to row is not incrementing by 6 seconds. The date-time data seems to indicate 7+ minutes of stacking occurred in a fraction of a second.

Addendum: It only saves the correct date-time to the stacklog file if "save raw frames" is turned on and fails to write a reasonable frame capture time otherwise.

[admin]

Hi,

well, I guess I know what is happening... When the log is activated, nothing actually gets written to the log until the first file from the stack is saved - up until that point, all the info is kept in memory ready to be written when the first file is saved. This avoids creating the output folders for the stack just to start writing the log - otherwise you would end up with lots of output folders with just a log in if you (for instance) reset the stack a few times while getting things adjusted.

It looks as though when this happens the timestamps being written are the time that the log is being written to file, not the time that the information was recorded. I have code that is supposed to set the timestamp properly, but it looks like somehow it is being ignored or overwritten.

Looking at how things work in the logging code, I think I can work my way around this to get the times to come out correctly.

thanks for the report.

Robin

[lowenthalm]

This is fixed.

However, the live-stacking log writing is still acting wonky. Sometimes you get a log, and sometimes you don't - usually when I really need to review the log (I am testing PEC behavior right now!)

Switching to a new target name will frequently cause the first saved directory to not have a stacklog file, and then the subsequent live-stack autosave to the same <target name> will produce stacklog files.

I have found a way to induce this behavior:
1) Assuming stacklogs are saving in a sequence of live stacks correctly to start...
2) When a live-stack auto-reset occurs I go to the just saved live stack directory and rename the stacklog file by adding the time to the end of the directory so I know which stacklog it is.
3) The next live-stack auto-reset will write an empty stacklog file to the previous directory where I renamed the stack log. The newly saved live stack result in the next directory does not get a stacklog file at all. Sometimes this breaks writing the stacklog from then on for that target name.

[admin]

Hi,

the intended behaviour is to not create a directory for a stack just because of the stacklog file. That means that if you never save anything from a stack then the stacklog should not get saved. As soon as you save a file (raw frame or any normal save from the stack) then the output directory for the stack gets created and the stacklog will get written into that directory.

If you can make things happen that don't match with the above then I guess I have some sort of issue and will have to look into it. From the description, I'm just unsure if the renaming you mention is a requirement to make the problem happen, which might make me conclude that it's actually OK as it is.

cheers,

Robin

[lowenthalm]

It happens when I change target names frequently. The first directory saved gets no stack log. The rename behavior is a way of getting it to happen at will. The renaming after the directory data has been saved should have no effect on saving the stacklog for the next output directory saved for the same target name when an auto-save occurs. Changing the target name changes the path, which is why I think this also causes it to fail on the first directory after a target name save.

[lowenthalm]

I ran the following sequence multiple times using the DeepSky test camera set to 1 second exposures to speed things up. Sometimes I entered a new target name and sometimes I just left it alone. About 25% of the time a StackLog .csv file wasn't written. The pattern seems pretty random. I even tried not opening any of the paths to look at them just to make sure no other processes had a some sort of lock on one of the directories.

This appears to be different than the behavior caused by renaming an already written stacklog file which produced empty stacklogs written to disk. This just causes no file to be generated at all. I also tried renaming the previous target directory and entering a new target name when I ran the script. That seemed to cause more stacklogs not to be written (3 out of 4 were missing!) Renaming or moving the previous target directory should be a pretty normal thing for a user to do.

Stacklog writing exercising sequence

SEQUENCE
PROMPT FOR TARGET
SET CONTROL "Background Subtraction" TO Off
LIVE STACKING RESET
UNLOCK CONTROLS
LOOP 4 TIMES
LIVE STACK FOR 5 FRAMES SAVING AS AllFormats COUNTING Stacked FRAMES
PLAY SOUND Alert
END LOOP
END UNLOCK
PLAY SOUND Alert
PLAY SOUND Alert
END SEQUENCE

[lowenthalm]

I have been live stacking tonight without using a sequence - just saving with save and reset every (7) minutes. Sharpcap 4.1 hasn't saved a single stacklog, unless I explicitly save a fits part way through (in which case it updates the stacklog file until live stack reset - then doesn't write a stacklog in the next live stack). It saves the png preview and the stretched png and the 16b and 32b fits files, but thats it. Is there a checkbox that enables saving the stacklog or is it supposed to always save it?

[admin]

Hi,

interesting... there is an option (in the right-hand-most 'Settings' tab of the live stacking area), but I suspect that is on or you would see nothing.

I wonder if the auto save/reset code somehow manages to bypass creating the stacklog file - that might explain what is going on. I will investigate.

cheers,

Robin

[lowenthalm]

Would the autosave/reset code also be traversed by the sequence I posted above that randomly omits saving the stacklog? That seems like that might be a different problem since the autosave checkbox is not checked when this script is running.

Sorry to be so focused on this. I using the stacklog a lot to try to debug a problem with my Celestron CGX mount. It appears that PEC playback stops or is corrupted after a slew, and the stacklog is the perfect tool for probing this problem as I don't have a separate guide camera (yet - it will arrive in about a month).

[admin]

Hi,

yes, I think it's possible. I haven't had a chance to check this yet, but my theory is that the stacklog will get held in memory until you save an image from the stack. But... I think it will then only get written when the next frame is stacked, so if the first save is immediately followed by something that resets the stack and starts a new one, the opportunity to write the stack log is missed.

cheers,

Robin