A couple of weeks ago, I updated the Astroberry to kstars/ekos 3.5.5 I found a little issue where a schedule won't run if ekos is started and the schedule loaded via a dbus command via python for some automated management I've been working on.

Previously on 3.5.3, the sequence was load ekos, load schedule, run schedule and then it connects devices and off it goes.

However in testing 3.5.5 (not tested on 3.5.4) some issues have crept in where sometimes it will not read the equipment profile from the schedule and won't load the profile unless that is injected over dbus via setProfile(), sometimes it loads the sequence in an inconsistent state which requires triggering of resetAllJobs() to force the scheduler to load the capture sequence and the target co-ordinates. Finally when triggering the start command the schedule is holding at idle with "no job running" until manually pausing/stopping and then restarting the scheduler via the ekos scheduler interface.

On the spare Astroberry, I built 3.5.7b from source to test if it was a one off, but the issues still present, and still end with the same result where it sits spinning the wheel with no job running.

Hello Sean and welcome to INDI forums!

Please write step-by-step how to recreate this issue.

Hi Jaseem, thanks for the welcome!

It'll be later on today when I get around to it as I'm just on the way to work, and I'll attach the python script that's used for the initiator, command line call, etc.

In the mean time here's the logging output from the scheduler module if it's useful I made yesterday evening from both 3.5.3 and 3.5.5, generated by simulators but it's the same behaviour as the physical hardware attached. The 3.5.3 is up to the point where the simulator is generating the first frame, but 3.5.5. doesn't log any further than where the last line of the log is generated without manual intervention. 

Right, back from work and here's the rest of it.

The script, ekos_controller.py was put together by another member here, I can't remember who off the top of my head but it was another thread about dbus from quite a while back; I've gone through it, found no noticeable errors in it, rebuilt it a couple of times to make sure and matched it up to the scriptable functions in scheduler.cpp

On the machine, the configuration is a Pi4B 8GB, with the indiserver set to remote though on the same machine to maintain the current settings should kstars go down, the profiles in ekos are set to auto-connect.

The sequence which worked on 3.5.3, was from the terminal (or ssh, or shell script); examples assume relative to desktop.
The CurrentSequence.esl is just a copy of whatever the sequence I am working on at that time.

However on 3.5.5 (and 3.5.7b) using the same python script, the process is :
This, however, only goes so far to start the scheduler, but when the schedule is started in this manner even with a valid job in the queue, it doesn't select the job and start.

Starting and running a sequence by direct input doesn't cause the same issue to appear. 

I found the issue and it's fixed in GIT now. Please try again.

Thanks Jasem!
I built from git on version 3.5.7b tested with the simulation profiles and the different ways I can think if to arrive to sequence start, and each time it is equal to the behaviour on 3.5.3 and without issue or workflow modification to force anything to happen. I'll throw some more tests at it over the coming days, but I'm not seeing anything different from previous (3.5.3) on it at the moment.
Thanks for the time looking in to this one and thank you for implementing the fix!

Hello again.

I've been doing a bit more testing with the 3.5.7b with the changes to the scheduler.cpp that were pushed to the repo, and found some more problems; I'm not sure if it is a continuation of the same issue or it's another that was hidden by the previous one.

With testing further via the interface, I've found that the scheduler is now causing problems and hanging at the "No Job Running" state when starting the tasks locally via the scheduler interface within Ekos; it's appearing to fall over in exactly the same way as the dbus interface was previous but stopping and force reloading the schedule or toggling pause does not bring the queue to life.  I've been through and checked it with viable targets and with all the overrides turned off (altitude, twilight, etc) a few times just to make sure that it wasn't something I'd overlooked.

I've attached scheduler the log from the last test I ran with it as it's a carbon copy of the others.

Saw the 3.5.7b build that was pushed on to gitlab earlier, built it and testing it now; initial tests show that interacting both directly and indirectly over dbus both seem to be functioning and nothing untoward has popped up in use or the logs.

I'll keep throwing some tests at it, just to check and hopefully towards the end of next week get chance to test it on real equipment in a real world situation; if anything pops up I'll keep you informed.