Hi Eric and Jasem,

I found a new unexpected behavior of the scheduler. I had programmed a sequence in the imaging module to image the Eastern Veil in Ha, Oiii, Sii, LRGB (this was the only .esl instance I had programmed in the scheduler) and encountered the same problem twice last night;

After finishing the Ha sequence (30x240s), the scheduler restarted the Ha sequence instead of moving on to the Oiii sequence. I caught it around 2.45 am, stopped the scheduler, deleted the Ha portion from the imaging sequence (now Oiii was next in line) and restarted the scheduler. Then shortly before 5 am the same thing happened: The Oiii sequence was finished and the sequence was now supposed to move on to Sii, but again the Oiii sequence was restarted, although it had already completed.

This was certainly introduced during the last update to 2.9.7, because the same .esq sequence had worked fine under 2.9.6.

Can you have a look at the code? It appears to me that now instead of moving on to the next exposure set in the imaging sequence, the scheduler forces a restart of the entire sequence from the beginning and doesn't care about the fact that the Ha and Oiii sequence in this case had already completed.

Again, the log is too big to attach, you can download it here: www.dropbox.com/sh/tj5c8nudklv1dus/AACPk...1efnOj1p8Aarxqa?dl=0

Thanks for looking into this.

Jo

Wow this is interesting. Your capture "EasternVeil_Light_Halpha_240_secs" appears erratically in the log (started 22:16, then 22:30, 23:06, 23:15, 23:19, 00:28, 00:30, 01:57), and always states "1 out of 30 is complete", just after execution is prepared... Sounds not good at all, I'll have a look. I hope it's not D14357...

I assume you got no captures out of this schedule? Could you provide .esl and .esq as well?

-Eric

I feared that you would ask for those.... I had turned off the mini-PC controlling the rig before downloading these files, just saved the log.
I will have to wait until tonight before I get to these files. But as I wrote, the .esq file I had used before under 2.9.6 and it had worked fine, moving through the sequence from Ha to Oiii to Sii, etc. It only stopped doing this last night after I had updated to 2.9.7

Actually, I got good frames out of this session. No problem with the exposures, they look fine, I just got more frames than I wanted and only of one kind, the first one in the capture schedule (Ha and later, after manually deleting Ha from the imaging .esq file, Oiii). From the way it works at the moment, there is probably only one target and one filter I can get from the schedule.

I'll upload the .esq and .esl file tonight, but please note that both have changed since the initial problems started. I had to manually edit them to continue to get the frames I wanted and I needed the scheduler to align the scope to the coordinates in the FITS files I had already collected so that I can stack the frames afterwards. Thus, neither the .esq nor the .esl files will reflect what they were when the Ha frames were collected.

Aside from that, I like what you have done to the scheduler, Eric! The refocusing upon filter change is great, and the fact that ASAP now works as it is supposed to is also great.

Best

Jo

Thanks, more fixes to come!

No issue for the seq/capture files, I'm not in a position to study that log right now. Could you also check the verbosity of the capture and scheduler modules? They don't tell much in the log, and what they tell seems unrelated to what you have in the end. I don't know if you process your guiding values afterwards, but this part is very verbose on the opposite, and could be muted a bit.

-Eric

I'll need to look into the capture and scheduler verbosity. I am not sure where to find those, though, do they appear in real time at the bottom of the modules? If so, those seem to reset after I quit Ekos, is there a way to retrieve them and if so, where would they be stored, if not in the log folder?
I have never processed my guiding values, actually not sure what that would accomplish. If the stars are small and round, I consider the guiding was good and that's about the extent of processing I expend on it.

The Logs button is on the second button group on the first Ekos tab. There you can select the verbosity, and the modules you want logs for. If you don't use the guide information, you can disable the log output there.

-Eric

Yes, I know that and as far as I remember, I have all the important ones selected, but I don't know where these logs are saved. Apparently not in the logs folder. I see them displayed at the bottom of the respective modules, at least I think that;s where they go, but I don't know where they are being saved. If they are being saved anywhere.

Everything is saved in the KStars log file once you select it.

All the documentation is now in the Dropbox folder (see my first post above).
I do not see where the verbose logs for the modules I selected are saved.
What am I missing?

They should be in ~/.local/share/kstars/logs and are saved there in a sub directory named for the date at which KStars was started.

All good in terms of log verbosity. I can see debug logs for the scheduler. I was surprised at the lack of debug logs from the capture module, but it appears to be the expected amount. Sorry for causing confusion.

I'm now looking for regressions into D14357.

-Eric

Do you have option "Remember Job Progress" set in your configuration? That may be a hint of why the count of captures is never updated.

EDIT: I'm deducing from your log that you have that option disabled, sorry for asking.

EDIT2: wrong deduction! seeing log "1 out of 30 is complete" means you have "Remember Job Progress" enabled as root condition.

-Eric