NINA doing fast images confused and saves with wrong file name (and/or contents)

Issue #1082 resolved
Linwood Ferguson created an issue

Synopsis: In doing 500 images each of gain 0 and 100, I ended up with 498 and 502 instead

I was doing a series of bias images in a simple loop (attached) where it takes 5 bias at gain 0, then 5 at gain 100. I broke it up like this to put a cool-camera in between each 5 in case temperature was rising from readout (it does). The loop ran 100 times, should yield 500 images of each gain.

When I integrated to masters, I had 502/498. I went back to check, and the log clearly shows the async handling got confused. There are 500 start exposures for each, 500 Finishing Category for each gain, but the actual file names saved (which contain the gain) have 498 and 502 of each. The file sequence numbers are correct (0-499 for each), but there is a duplication in one, and absence in the other.

In the attached log starting at 9:00:24 you can see it saving file sequence 0085 for gain 100 the first time. Then at 09:00:30 you can see it saving the same file sequence and gain a second time, but with a different time stamp (so no file name collision). There’s another one in there somewhere also, they are a bit hard to find as the only clue is the duplicated sequence/gain combination.

The FITS headers both say gain 100. I do not know if it saved a gain 100 file instead of a gain 0 file (the results are nearly identical in terms of statistics) or if it saved the gain 0 file labeling it as a gain 100. But it clearly got confused.

This happened in Beta 48 x64, windows 10x64, an ASI6200MM Pro camera. I saved the instructions used as a template and that is attached.

I did not try to reproduce this, hoping that the log detail would be adequate to see the issue, but if a reproduction is needed I can attempt. I have not seen such an issue on DSO sequences, but then again there is never overlap of imaging and saving to this extent there due to long exposures.

Comments (5)

  1. Stefan B repo owner

    I’ve spent some time on this and I think I have found a root cause for it.
    When we capture and download the image we fill the metadata based on the cached camera info - the one that is polling in the background - and not the live camera data.
    So for your example where you have a short burst of exposures it could happen that the camera data is outdated. I will create a fix for it to populate this particular meta data directly from the camera driver instead. This should fix the problem.

  2. Linwood Ferguson reporter

    Seems reasonable. I’ve had it happen again once or twice, but quite rare, consistent with some kind of race. Thank you.

  3. Log in to comment