Timelapse stops capturing images

[astra]

Hi. I'm pretty new to solar imaging, so probably I'm missing something or it is an issue with camera. I'm using PlayerOne Apollo-M.

I can successfully capture single movies with start capture tool. But when I start solar timelapse, I have about 50% success rate. Sometimes in the middle if timelapse, let's say, exposure doesn't happen. The interval passes and image acquisition should start buffering, but it doesn't. There should be "0/500 frames captured" in the bottom right corner, but I can see only a progress bar (without green) and there is no text. Looks like the process is in the state of BEFORE starting acquisition. So I have to stop capture and star again. I have checked the logs, not much there. There is a big gap from 15:13 to 15:17
I never had the issue with individual capture, only in timelapse. I've tried to limit fps (didn't help, somehow sharpcap started to
write 4 fps on saving file, while 60fps limit is selected) and USB speed change (not sure if that helps, but looks better)

Any ideas?

[admin]

Hi,

thanks for posting the logs - I can see in the log that there is something odd happening at the time your short SER file is created - basically SharpCap has internally decided that it has captured enough frames when it really hasn't. That stops it from adding new frames to the file, so it never reaches the target length and gets stuck.

I haven't seen this happening before, so I will investigate possible ways that the code might get into that state and see if I can come up with some sort of explaination of what might be going on.

cheers,

Robin

[astra]

I have at least two similar cases, if you need logs. Another issue that deserves a separate thread is that I run SC on a mini pc that is loaded almost 100%. Probably that is entangled. I know that question was asked before and probably the answer is no, but it would be great to have an ability tolower "presentation" fps of the liveview and have a maximum fps while capturing. It seems to me that firecapture is able to lower view азыб but unfortunately it is more unreliable for me.

[admin]

Hi,

SharpCap tries to automatically lower the displayed frame rate when the PC is under heavy load to prioritize getting frames from the camera and saving them rather than displaying them on screen. The target is to keep the CPU usage of the display system below 75% of one CPU core and the display update rate between 1 and 30 fps. Unfortunately in some cases Windows prevents SharpCap from accessing the performance metrics it needs to do this (check the log for an entry starting 'Failed to create performance counter for processor usage.') If your mini PC only has a 2 core processor, it might still struggle though - SharpCap is designed around spreading the work across multiple cores.

I had a look into the causes of the failure to capture enough frames - unfortunately there were 3 or 4 different theoretical ways it could happen and nothing in the log to help distinguish between them. I have added some extra logging for the next update that should help me identify the cause if you can catch it happening again.

cheers,

Robin

[astra]

So that happened not only in timelapse today, but ordinary capture. The UI looks like this, an empty file is generated
I bought sharpcap today to set larger memory limit, that didn't help

[admin]

Hi,

yes, looks like the same problem as last time where SharpCap has decided not to save any more frames for a reason that we have to determine. I hope to get a new update out today/tomorrow which will have the extra logging to help determine what is going on.

One thing I can see from that log is that SharpCap is struggling in terms of performance on your Celeron processor, particularly when tools like the focus tool or the feature tracking are active. I don't think that's the primary cause of the problem, but it might be making something that would otherwise be extremely rare happen more often. It may be worth de-activating any of these tools while capturing to see if that helps avoid hitting the problem.

cheers,

Robin