SharpCap Script Stops Writing SER File

[Luxterra]

I ran across this bug twice when practicing for the eclipse, but times on the ASI533MC-Pro (IIRC). I have three cameras and three instances of SharpCap running; each with their own Sequencer script. All are capturing SER files with a peak aggregate data rate of ~900MB/sec. Cameras are: ASI533MM-Pro, ASI533MC-Pro, and ASI432MM. The 533's are 16bit/~20fps each and the 432 is 8bit/~120fps. The PC is Windows 11 Pro, 7940HS, 48GB RAM, several Thunderbolt 1.5TB 905P, etc. and does not appear to struggle with this workload at all; it's very powerful compared to most astro PCs.

The last successful capture is this line:
Debug 01:22:36.053969 #1 Notification (Status=OK): Capture complete. Captured : 10 frames (0 dropped) in 0:00:00 at 14.7 fps

The next capture is unsuccessful at this line:
Debug 01:22:37.002523 #1 Notification (Status=OK): Capture Stopped - Captured : 0 frames (0 dropped) in 0:00:00 at 0.0 fps

I've attache a portion of the log, but the full log is massive as this was running for over an hour and I intend to capture the entire ~2.5hrs of eclipse with this setup.

Observations:
1) I hadn't seen this until I added the third camera, ASI533MC-Pro. I've been testing and running dual cameras/SharpCaps like this with no errors (ASI533MM-Pro and ASI432MM).

2) I believe both times it was the ASI533MC-Pro that halted.

3) The camera isn't running at the 19-20fps that's the typical capture rate at these settings.

4) The Sequencer script appears to complete successfully and I don't see any errors, despite no files being written past this point.

I'm thinking this may be a camera or camera driver rather than SharpCap issue, but the lack of errors is concerning.

Thank you.

[admin]

Hi,

interesting... As you say there are no errors recorded, which actually limits potential causes quite a bit because most things would result in an error or warning in the log. The sequencer asks for a capture of 10 frames which doesn't complete, so from that we know that no frames were received from the camera after that point (well, a maximum of 9, anyway) in the 30s before the 'stop at' timelimit was hit.

For short exposures on ZWO cameras, SharpCap would report a dropped frame and timeout after ~5s with no new frame coming from the camera. Dropped frames would show up in the status at the bottom left of the window, but only get logged when certain thresholds for the count of dropped frames are passed. Because of that, we can't be sure from the log if SharpCap was recording dropped frames every 5s or so during this period, or if the capturing code was just stuck in the ZWO SDK calls and unable to proceed anyway.

That's pretty much all we can deduce from the log fragment - the only extra thing the full log would reveal is if any dropped frames had been recorded earlier in the log... If not then I would expect dropped frames at that point being the first ones to get recorded in the log, which then lean towards the stuck in the ZWO SDK idea.

In either case, I think your analysis is correct - the camera has stopped responding to the software - either a glitch on the camera (rare, but not impossible), in the USB communication or in the ZWO SDK running as part of SharpCap. While you might have been able to recover by closing/reopening the camera or stopping/restarting SharpCap, it's quite possible that an unplug/replug of the camera would have been needed.

There is no obvious thing to do to eliminate the chance of this happening, but some general things that might reduce the chances

* Try different USB ports - you may hit problems if you are trying to run two high speed cameras from two ports that are connected to the same internal hub

* Reduce the Turbo USB setting on the camera - this may reduce frame rate, but can help improve stability

Hope this helps,

Robin