Indeed, my system's been capturing many targets from my basement during the last few days as a side note, work on the scheduler is progressing. You are right @knro, this is quite a complex beast!

-Eric

I have made changes to the scheduler a few days ago that would re-evaluate all jobs anytime evaluateJobs is called. Just FYI if you are not aware of that. That fixed problems with the "Messier Marathon" scheduler list that I received.

I saw this too, and was about to check the reason. With a 30-item scheduler job it takes ages for the evaluation on my low-power VM But I don't want to hijack that thread, I'll report my findings in the other thread.

-Eric

There were indeed few memory leaks that are now fixed in GIT.

Thanks. My setup has been running for three weeks without power interruption. During these two weeks, there have been three indiserver crashes induced by indi_eqmod_telescope, always while slewing or tracking. None of these crashes had the disconnection messages. All crashes did damage the functioning of the camera driver, which was used during the tests. The focuser and guider drivers were connected but not actively used, and never suffered from the driver crash (except that they died along).

I'll pick the changes in indiserver and let you know the outcome. With my changes in the scheduler it's time to test jobs auto-scheduled over multiple nights

About leaks, I suggest we set a static code analysis of the tree periodically. I know Synopsis/Coverity provides such service free of charge for open-source projects.

-Eric

I suppose your were running everything from GIT after my memory leak fix?

No, the last three weeks were not embedding your fixes. We just have an intuition the issues come from those leaks. Now I'll include them in my tests.

-Eric

Hi,
Can you be more precise in what has happened?
Writing that a process (indi_eqmod_telescope) may damage the functioning of another process (the camera driver) is somewhat surprising.
Hopefully it did not kill the camera itself!
Jean-Luc.

Yeah sorry for the choice of words I was referring to damaging the process area in indiserver : when the eqmod driver crashes, it has a side effect which also kills the camera driver, and sometimes the indiserver too. Because driver process memory areas are somewhat independent, it means the crash in eqmod has an impact on indiserver, which in turn breaks the communication with the camera driver. I observed that the other drivers (moonlite, filter wheel sim and MGen guider) were not reacting to this. I'll admit this is quite vague and not backed up with log information. I'll double check the logs, but most often a crash was just a "died" notice unfortunately.

-Eric

Ok, I understand what you mean now, Concerning the indi-eqmod crash, did you use alignment ? A sequence of capture/solve/sync on the same target as ekos does may cause an issue in some circumstances. Besides I've seen in a preceding post that you leave your mount parked and powered a day long: be warned that parking the mount does not stop motor powering, there is no (direct) way to disable the driver ICs but using the power switch.

No I didn't use alignment. The scope being in the basement, I only ticked "Track" in Ekos for my tests.

About motor ICs remaining powered, I'm not sure I understand what your warning applies to. You mean that it could be damaging in the long term, or that it still consumes power even when parked? I plan to have a power controller in the observatory to shut down supply in some situations, but with the current code I don't think a park/unpark operation in Ekos or INDI could be linked to that control.

-Eric

The crash is most likely due to a memory leak I fixed earlier but Eric didn't use the fix in his branch. At least I hope this is it