--- Comment #2 from TallFurryMan <> ---
Yes, logs can be generated by KStars, Ekos and INDI (when the .indi/logs folder
exists!), but the only relation with the current observation plan is the name
of the target and index of the scheduler job. The log doesn't say which job XML
is processed for instance. 
Having the excerpts of logs stored along with either the scheduler job XML, or
the capture sequence job XML, or the storage for captures, would be helpful to
gather relevant information for an observation. This would help posting debug
information in issues too. 
However I realize this is harder to specify than it seems, as the notions of
input (the scheduler job, the sequence job, the input fits...) and output (the
captured frames,... ) have no well-defined hierarchy or dependency. Jobs could
be in a read-only location for the scheduler for instance, which would prevent
the tool to use that place for output.
Perhaps introducing variables that may be used as location placeholders could
be a solution. I'm thinking about the way Eclipse manages paths here and the
default "Target" placeholder naming capture files. "$SchedulerOutput", which
could be used to define "$SequenceOutput" or even "$IndiOutput" for client-side
data. This way all relevant output information can be stored in the same
Use case for captures would be:
- create a capture sequence job, assign an output using the undefined
"$SchedulerOutput" as prefix for the sequence job, say
"$SchedulerOutput/some/path", this defines "$SequenceOutput" for the job. 
- create a scheduler job, assign a capture sequence, assign an output, this
defines "$SchedulerOutput" for the scheduler job, say
- when the scheduler job executes, the capture sequence job uses
"$SequenceOutput", which is ultimately "/home/me/yyyymmdd/a_target/some/path". 
- any module that write logs or store data can then have those copied to the
path resulting from those variables.

You are receiving this mail because:
You are watching all bug changes.

Reply via email to