When a schedule is started that is looping AND there are already existing images in the target directory,
the capture module refuses to continue and signals that there exist already sufficent images - which
should be never the case for looping schedules.
Details
Details
Take any schedule where the sequence is repeated infinitely often. Start it and let it run for at least
one cycle. Then abort it and restart it. Switch to the capture tab and see, that no more images will be
taken.
Diff Detail
Diff Detail
- Repository
- R321 KStars
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Comment Actions
I don't understand the relation between ignoreJobProgress and the loop configuration of the scheduler job. If the Scheduler is causing the Capture module to consider all captures are complete, the the problem is in capturedFramesMap, not in that flag.
Besides, I strongly believe that this flag should NOT be used anymore in the Capture module. It should be moved from the Capture settings to the Scheduler settings. The rule that I think must be enforced is : unconditionally capture when the user uses the Capture module directly, honor the flag when the Scheduler uses the Capture module.
Comment Actions
OK, makes sense. My thought was that ignoreJobProgress was set via ignoreSequenceHistory() from Scheduler for infinite looping jobs, but never used in Capture.
I'll revert the change and shift this as proposed to Scheduler.
Comment Actions
Scheduler does not set captured frames map for SchedulerJob::FINISH_LOOP jobs.
Instead of changing Capture to ignore the captured frames map, the map is not set for
those scheduler jobs that loop until termination.
Comment Actions
Hm, it seems like my code changes did not find their way to this differential. Here is what I did:
wolfgang@debianlive:~/sterne-jaeger/git/kstars-master$ arc diff --update D14928
You have uncommitted changes in this working copy.
Working copy: /home/wolfgang/sterne-jaeger/git/kstars-master/
Unstaged changes in working copy:
kstars/ekos/scheduler/scheduler.cpp
Do you want to amend this change to the current commit? [y/N] y
Linting...
No lint engine configured for this project.
Running unit tests...
No unit test engine is configured for this project.
SKIP STAGING Unable to determine repository for this change.
Updated an existing Differential revision:
Revision URI: https://phabricator.kde.org/D14928
Included changes:
M kstars/ekos/capture/capture.cpp
M kstars/ekos/scheduler/scheduler.cpp
wolfgang@debianlive:~/sterne-jaeger/git/kstars-master$Any hints?
Comment Actions
First, make sure you create a development branch, and that this branch tracks the master branch, either local or remote. "arc diff" will push commits up to the fork point. Or you can use "arc diff <fork point>", such as "arc diff master" if you checked out "kde/master" locally.
So FINISH_LOOP does not fill a capture map? Well that makes sense, I wasn't sure I had done something there. But in that case, what happens in the Capture module? I would expect it to act as if all items were set to zero!
Comment Actions
Aaaa, it seems like my changes now made it into the Phabricator.
I simply leave the captured frames map empty for SchedulerJob::FINISH_LOOP. The Capture module remains untouched. The behavior in the capture module is quite simple: since it does not find the signature in the captured frames map, it assumes that there are no frames - i.e. it simply executes the entire set - as desired. Quite simple...
| kstars/ekos/scheduler/scheduler.cpp | ||
|---|---|---|
| 4454–4455 | I propose you use a switch case so that we don't forget the special situation of FINISH_LOOP. I think we should also do the same for FINISH_AT, as there are no requirements on captures there neither. | |
Comment Actions
Captured frames map not handed over for FINISH_LOOP and FINISH_AT
Additionally, switch statement used instead of a simple if clause.
Comment Actions
Took the liberty to pick that differential up to squash changes and rebase onto master.
Tested OK for both FINISH_LOOP and FINISH_AT, good to go.
Comment Actions
@wreissenberger Please commandeer this differential to get ownership back, so that your name appears in the commit (ah, phabricator...).