kstars-bleeding:master

Last commit made on 2024-04-26
Get this branch:
git clone -b master https://git.launchpad.net/kstars-bleeding

Branch merges

Branch information

Name:
master
Repository:
lp:kstars-bleeding

Recent commits

1a1a800... by l10n daemon script <email address hidden>

GIT_SILENT Sync po/docbooks with svn

badf138... by l10n daemon script <email address hidden>

GIT_SILENT Sync po/docbooks with svn

7b017e7... by John Evans <email address hidden>

Autofocus Restart Bug

This fixes a bug in Focus whereby under the following conditions the Autofocus restart is not performed correctly:
1. Autofocus fails.
2. Current focuser position is within 1 tick of initial focuser position at the start of Autofocus. I think this limits the situation to an R2 failure and a more generic failure part way though an Autofocus where the current position matches the start position (unlikely). In practice this bug is quite unlikely to occur IMHO. I think its been present for a while and isn't new.

The bug is that the function changePosition detects that the focuser has <= 1 to reset its position and does not attempt to move the focuser (as some focusers can stall on 0/1 tick moves). The restart logic is triggered off the completion of the reset position movement, so in this case it's not triggered.

The code then (incorrectly) takes another focus frame and tries to process the result (which is the same data as before + the 1 new frame), i.e. Autofocus is not rerun.

This breaks Analyze because Analyze relies on matching pairs of startingAutofocus() and either autofocusComplete() or autofocusAborted() messages. With the bug, Analyze receives startingAutofocus() followed by autofocusAborted() followed by autofocusComplete(). The start time in Analyze is set by startingAutofocus() and reset to -1 after autofocusComplete() and autofocusAborted().

Coded and tested on the Sim. I would rather not rush this release because:
1. I think this is not a new bug and won't occur very often.
2. The change is to the core focuser movement function that all focus moves go through so is at high risk of breaking something else (that I can't think of at the moment).

3e41593... by John Evans <email address hidden>

Focus Abort Bug

Bug reported by Hy whereby when a Focus Abort is requested...
1. Focus signals the status change to Capture / Scheduler too soon which means that Capture / Scheduler can attempt to use the camera when Focus is not done with it.
2. Focus does not interrupt its own processing securely. This results in another exposure after the abort has been partially processed. This in turn sets the focus status to Idle - which is incorrect.

There are 2 parts to this bug:
1. If the abort request occurs whilst star processing of a focus frame is in progress, then a subsequent capture can be started after the abort processing has started.
2. Generally the signal to capture / scheduler can occur too early in the abort processing before Focus has finished with the camera so this runs the risk of capture / scheduler starting to use the camera whilst Focus is using it leading to conflicts.

The fix will make sure that when in Autofocus, captures and HFR processing are complete (and no new ones started) before starting the internal Focus abort processing that signals Capture / Scheduler of the state change.

5510440... by l10n daemon script <email address hidden>

GIT_SILENT Sync po/docbooks with svn

0f3a315... by Hy Murveit <email address hidden>

Attempt to fix issue where camera driver crash does not recover.

02633c4... by Jasem Mutlaq

Add function to return all DSO designations

026132e... by l10n daemon script <email address hidden>

GIT_SILENT Sync po/docbooks with svn

07e0046... by Yuri Chornoivan <email address hidden>

Fix minor typo

f300cde... by l10n daemon script <email address hidden>

GIT_SILENT Sync po/docbooks with svn