Last night I ran an observing sequence with the latest kstars beta from git. This morning I found out that after some 1.5 hours, temperature change triggered an AF run, and after that the image acquisition was never continued. Everything else was working: Guiding, Meridian flip, another temperature-triggered refocus. But the interrupted sequence never continued
Background: I used only the capture module. Programmed a sequence of 165 frames of 180s duration with Hα. Exposure start limit for guiding was set to 0.5", plus a re-focus on ΔT> 0.8⁰C. Focus for Hα is linked to the Red filter.

I did notice the guiding-based exposure delay now properly works (It is a bit irritating though that it 'aborts' the sequence, which triggers an acoustic alarm - would be great if that could be changed somehow....)

The log file is attached. The whole issue started 23:21:10 after image 28/165 was successfully captured.
Unfortunately only in standard log mode, I hope it's still useful.

Pit,

Thanks for testing.

Yes, I made the recent change (in 3.6.2beta, not in 3.6.1) that fixes the issue causing the system not to honor the guide deviation at start of capture. It aborts the capture and restarts it, which was a simple way to fix the issue in the complicated capture start-up logic. You can silence audio alerts, or that particular audio alert, in the menu under Settings -> Configure Notifications.

Re the bug where capture doesn't restart after temperature-change-focus, your log doesn't give much detail, other than I can see it failed that way twice in your log (23:21pm and 3:54am). Please add some debug logging and let me know if/when you see it again, or perhaps even always run that way when using experimental (or any) code.

Of course it would be great to get this fixed soon, but, FWIW, I have run with temperature-based focus and guide-deviation limits, and have not see that issue. I'll also alert Wolfgang who's the expert in that code.

Hy

KStars 3.6.2?????????
But if the 3.6.1 has been released as stable, but have a lot of problems and a list of open bugs, what is the sense to have a 3.6.2 and not a 3.6.1 definitively stable?!?!?!? Is not better have a stable starting point before introduce or change other stuffs?

Hy,
thanks for fixing that issue! I use one-pulse-dither, and probably due to that, the first guide number after dither quite often is large (although I would expect it to be zero - I thought OPD defines the first position as new lock point?). I usually don't see a real influence on the star shape, but that might be that it is only for a few seconds and doesn't contribute much for longer exposures...

As for the alarm - yes, I have already disabled most audio notifications. But 'Abort' is a really critical one (to me), so I leave that active. But now it alarms once (or even twice) after almost any dither, and as the computer is in the room where I (try to) sleep that won't work. IMO the status when guide error is too large should be (similar to) pause mode, but not abort, as it actually continues w/o interaction...

But back to topic: At least I don't think the problem is related to your fix. I had already reported it two months ago for an earlier version. It was using the scheduler, but likely also there it was within the capture module?

Let's see what Wolfgang says - he already fixed a similar deadlock in the MF code last time

And I promise to use verbose logging more often. I'll just have to keep an eye on the filesystem. Just deleted half a Gig of kstars logfiles. They are close to 'invisible' in the .local tree

I have the same issue with 3.6.1 described here:

www.indilib.org/forum/ekos/12449-3-6-1-m...ume-after-focus.html

Even with verbose logging on focus and CCD it shows nothing, just completion of focus and then when the sun comes up termination of the sequence with no capture initiated. It did one temperature initiated focus and restarted capture OK, on the second one it never recovered.

Thomas, Can you send the log? Are you logging scheduler too? It reports the state of all the various modules.

Here's the log. I will run again tonight with scheduler also set to verbose. The focus starts at 1:35 am, focus complete at 1:37 am then nothing until dawn. It didn't meridian flip, it appears the system thinks it is capturing data.

Thanks. I see what you mean.
Yes, all Ekos logging enabled in Verbose mode to file.
I'll ping Wolfgang too.

Also, which software (e.g. when did you install it, or compiled from which latest commit)?

Thanks,
Hy

I did apt-get update from the repository which pulled 3.6.1, no complie nothing more recent that latest stable build.

Here is a log with more switched on but no more insight. Focus complete at 20:35 then just a bunch of bits from the focuser... the file is too big to upload but here is the relevant part

[2022-10-12T20:35:04.047 MDT DEBG ][ org.kde.kstars.indi] - NightCrawler : "[DEBUG] RES <00025069> "
[2022-10-12T20:35:04.047 MDT DEBG ][ org.kde.kstars.ekos.focus] - Abs Focuser position changed to 25069 State: Ok
[2022-10-12T20:35:04.047 MDT DEBG ][ org.kde.kstars.ekos.capture] - Focus State changed from "Focus Offset" to "Idle"
[2022-10-12T20:35:04.047 MDT DEBG ][ org.kde.kstars.ekos.capture] - Focus State changed from "In Progress" to "Complete"
[2022-10-12T20:35:04.047 MDT INFO ][ org.kde.kstars.ekos.capture] - "Focus complete."
[2022-10-12T20:35:04.061 MDT DEBG ][ org.kde.kstars.indi] - NightCrawler : "[DEBUG] CMD <2GP#> "
[2022-10-12T20:35:04.062 MDT DEBG ][ org.kde.kstars.ekos.scheduler] - Focus State "Complete"
[2022-10-12T20:35:04.064 MDT DEBG ][ org.kde.kstars.indi] - NightCrawler : "[DEBUG] RES <00134880> "
[2022-10-12T20:35:04.064 MDT DEBG ][ org.kde.kstars.indi] - NightCrawler : "[DEBUG] CMD <3GP#> "
[2022-10-12T20:35:04.079 MDT DEBG ][ org.kde.kstars.indi] - NightCrawler : "[DEBUG] RES <00000000> "