Why are some frames being written as duplicates and others skipped?

When I generate sequences of frames, the filenames on disk are either randomly skipping or duplicating. It does this for both fn and fz frame number extensions. There is no pattern and it is completely random. I am using an SBIB STX camera. For example a sequence of files written to disk might go like this: (In this case for a bias)


This started happening on my existing computer. I bought a new Windows 10 machine and did a clean install and it does it on this machine also. Could this be related to some issue SGPro has with the SBIG drivers? Everything is up to date.

Here is a logfile from the new install I did today. Frames are skipped at 1, 9, 15, 18, and duplicated at 2, 10, 13, 16, 19


I posted about this issue with my STT camera (or it appears to be the same issue) about a month or so ago. It happens on short exposure, calibration frames in my case. I interpreted it, perhaps incorrectly, not as skipping and duplicating frames as much as misnaming some of them… Possibly because something wasn’t shaking hands properly or not keeping up. Either way, the correct number of frames shows up, but they are incorrectly named - as you describe.

In my case, though, occasionally, SGP will eventually tangled up and crash. I was able to duplicate the problem on two different Windows 7 Pro laptops, both on my telescope and with nothing connected to the laptops but the SBIG camera.

It only seems to happen on very short duration exposures, and putting a delay between exposures will sometimes, but not absolutely always, help.

Jarod had taken a quick look at this, and the next task was mine… To install the new SBIG driver which lists “improved low-level USB communications” as one of its features. Alas, I haven’t had a chance to get to that and report back… It doesn’t seem to be a widespread problem, but it is repeatable for me.

Are you seeing this with all the latest and greatest SBIG drivers and firmware?

Best regards,
Craig Smith

Hi Craig - thanks for the response. Yes, I have the very latest SBIG drivers and SGPro version installed. I did a clean install on a brand new Windows 10 machine just yesterday. You are right this seems to happen mainly on short exposure bias frames, but I have seen it on longer duration flats, darks, and lights also, though not to the same degree.

I also put 2 second delays between each frame but still see the same behavior. I also changed cameras from an STX to an older STL and the behavior repeated itself last night also.


Actually looking further at your comment… “In my case, though, occasionally, SGP will eventually tangled up and crash. I was able to duplicate the problem on two different Windows 7 Pro laptops, both on my telescope and with nothing connected to the laptops but the SBIG camera.”

My copy of SGPro has also been crashing frequently, usually randomly in the middle of generating a sequence of frames with one of those unhelpful “The program is being closed, Windows will look for a solution” type messages. There is nothing obvious in the log file. This is consistent on two machines one with Windows 7 and one with Windows 10, and with two different SBIG cameras.

This all seemed to start when I updated the SBIG drivers and to the current version of SGPro. I have been using both for several years. I think I know what I am doing, and have not observed this level of instability before. At the moment however, it seems a 50/50 roll of the dice that whenever I leave SGPro generating a sequence, whether when I check in a few hours it will still be running.


I’m disappointed to hear that the recent drivers may not fix this.

i haven’t had any time on my gear n the last six weeks for additional trouble shooting, but I hope to pick things up starting next week. I have star party trips planned in August and September, so I hope to get things sorted.

FWIW, I used 5 second delays. For my shorter flat exposures (I had no trouble with longer flats), I actually rotate the wheel between each exposure, that seems to work pretty reliably (that is, I take the flats R-G-B-R-G-B…). For me, these two work-arounds work much better than without them. It sounds like maybe there might be more than one issue going on for you?


I’ll load up the latest drivers this evening and see if I can duplicate this behavior with the SBIG simulator.

It’s interesting that we’re primarily (only?) seeing this with SBIG cameras. Maybe something in how they report their status has changed and we’re getting overlapping images, which would also explain the random crashes.


This was fun (yes, lots of sarcasm) to track down! However I have this resolved. And what is better is that this will very likely fix the crashing issue that others have mentioned as well, at least for SBIGs.

It was also mentioned that canons were having a similar problem so off to investigate that next.

I’ll try to get a release out for this later this week.


That is terrific news, @Jared! Sorry that I haven’t been more active on this. Sometimes other stuff gets in the way.


Indeed. Sounds like you have spotted the cause of all this. Great news and look forwards to the new download!

Thanks so much!


The fix for this issue has been released.


Unfortunately the crash problem has not been fixed and is now fatal in I cannot capture more than 2-3 frames before SGPro crashes with a “Sequence Pro has stopped working” message. This is consistent and happens every time when I try to generate both bias and dark sequences with both SBIG STL 6303 and ST 8300 cameras.I have uploaded a log file here:

I have now downgraded to and am again generating sequences though the crash problem was present in that version. (In I can’t generate enough frames to see if the duplicate and skipped frames problem has gone away)

Sorry for the bad news!


Unfortunately I can’t seem to duplicate this with the SBIG sim. Previously,, I could replicate the crash pretty much on command. However I can’t seem to trigger any error in I’m not really sure what could be all that different that you’re seeing considerably worse behavior with .16. The change was actually pretty minor between the two and just involved setting our internal camera status to “IDLE” rather than “ImageReady” after an image had been downloaded.

I’ll pull my STL-11000 in and see if I can duplicate with actual hardware. However if it’s a download speed issue the STL certainly won’t duplicate the issue…


Looks like this may have been caused when auto stretch was on. I was able to intermittently create a crash due to Auto Stretch but it took some work to make happen. This only showed up with the actual STL connected. I ran through over 200 frames with the STL without issue. I’m running another, much larger, set and will check on them in the morning. If you’d like to see if you can duplicate I’ve released .17 with this change.



Hi Jared - I believe you may have nailed it. First, I did check the Auto Stretch feature at the same time I installed .16 as it had been turned off before. I did not think there was any connection with frames being skipped, so I did not mention it.

I installed this morning and set a sequence of 500 bias frames running from my STL 6303 camera. So far I have generated 400+ frames with no crash at all, when previously I could not get past the second or third frame in a sequence. Better still there are no skipped frames or duplicates. I will run some more tests tonight, but it seems that Auto-Stretch bug was probably it.