I'm guessing some sort of operator error but I'm getting an EKOS time out and don't know what is causing it.
With all the cloud about I've been messing around with Kstars/Ekos/Indi to get it all working reliably before I make the big switch from y current cobbled together solutions on Windows.
I'm now comfortable with the CCD module and the new features are fantastic. So for my next trick I wanted to set up a CCD sequence of, say, LRGB to be repeated many times over. This is as opposed to taking a set of L followed by a set of R etc.
So I figured the eay to do this would be to use the Scheduler and tell it to execute the LRGB sequence, say, 50 times.
Seeing as I am still experimenting I tried to keep it all simple. I created a schedule targetting the polar region so slewing would be minimal. And no platesolving or guiding since it is cloudy and I just want to get the hang of the module. Before running the schedule I first ran the sequence and it did just as I expected.
So I then kicked off the schedule to run ASAP, it starts and about a minute later says EKOS has timed out.
I'm just looking for pointers as to what is causing this. Attached are the sequence, schedule and log file.

I just tested it on Windows and it worked fine. Maybe dbus-daemon.exe is not up and running? Check in task manager if such process is running.

I'm having the same problem with Indi (1.5) on RPi, Ekos (1.8.2) on Windows.

2017-08-27T22:57:31 Ekos timed out.
2017-08-27T22:56:28 Found candidate job M 31 (Priority #10).

No dbus-daemon.exe process running. When is that process meant to be launched?

dbus-daemon.exe is not running. I have found it under my ANSVR cygwin installation in /bin but I'm not clear on how to run it as a windows process.

Edit: Aha! Just found it also under my Kstars installation. So I just need to know how to launch that in background

Looks like my installation is missing (under the Kstars installation directory) /share/dbus-1/session.conf or system.conf
There is a /etc/dbus-1/session.conf but if I run dbus-daemon.exe with that as the config file I get
dbus[3540]: warning: Failed to start message bus: Configuration file needs one or more <listen> elements giving addresses

So I created a /share/dbus-1 sub-directory under Kstars and copied session.conf from cygwin but that failed. So I then downloaded the dbus windows instaler 1.4.12 from code.google.com/archive/p/dbus-windows-installer/downloads and installed it. Then I copied the session.conf file to my /share/dbus-1 directory
From a command line session I could then run dbus-env.bat and dbus-daemon --session
The scheduler worked so now I just need to launch dbus-env.bat and dbus-daemon in Windows startup

It's suppose to run automatically with KStars, I'll check it out.

Please uninstall KStars and dbus, and install the updated version of KStars I just uploaded. check dbus-daemon.exe now start automatically.

Success!
dbus-daemon is now started by Kstars and I could run a schedule consisting of 2 runs of LR with each filter at different gain. Surely this makes Kstars/Ekos the most versatile astro-imaging tool available and all for free.
Thanks Jasem.

Nice find, that's an interesting track. I was about to post a log of the apparent same issue to help, but under Linux. But it might be something else. Anyway.
Somehow my scheduler got stuck in the infinite alignment problem I have with eqmod, and looped waiting for the process to "finish" with the same symptom.

Line 4879 in the attached log, but I can't ensure this is the same problem, plus it's mixed with the eqmod alignment issue.
Line 21675 (yes...), twilight approaches and the scheduler realizes it's time to go to sleep (aha), aborts the solver (it could probably ask before!) and parks everything.
What is good in that situation is that the scheduler still has observatory security under control.

However, at the end of the process, the whole application freezed and was not functional at all anymore. So there might be dire consequence somehow.

I think I'll also post the alignment issue on github because it's certainly related to how the INDI driver handles alignment.

EDIT: kstars bleeding 5:17.04+201708191642~ubuntu17.04.1, INDI built from github master.

-Eric

Ok after investigating the log a bit, it appears that remote astrometry is _not_ enabled after the restart. You can see in the previous call:
Just after "Capturing Image...", but in the last time, nothing like that appeared so for some reason the remote astrometry was never enabled. I checked in solverFailed() but nothing appears to be related. So it would take some more investigation.

On a related note, I added option to reset mount model in the scheduler in case of alignment failure. Sometimes the mount model becomes the problem, so this option is in there just in case.

Sometimes I noticed that based on the order by which my INDI CCD drivers are enumerated (possibly "initialized" on the server side), the devices used in Ekos by default do change.

For instance, I have an Atik and a MGen, and sometimes when starting Ekos the MGen ends up as default CCD in Preview, Focuser and Alignment. Of course it's obvious when trying to focus on a remote UI, and having a choice on the CCD used is definitely a must. I never considered this could be an issue for the Scheduler but now it tickles me.

Could this device mix have an impact on the symptom described in this thread?

(thanks for the mount model reset, eager to test this!)

-Eric