Since upgrade to 3.7.1 (Ubuntu 22.04 PPA) a few days ago, every night ends with a crash sooner or later.
All three have some timers/threads error close to the end.
I restart KStars in the morning to finish remaining sky flats and it can do 5 to 20 of them before crashing again. I ran it under ekos debugger with a hope to get some more details.
Bonus question, maybe unrelated. One night it was able to stay all the way until the morning and captured half of planned sky flats. See log_20-15-52.txt. But it did not adjust the flats exposure! Several first files were OK, next are totally blown up as expected.
Read More...
I have two ZWO cameras, ASI2600MM Pro and ASI174MM Mini.
Occasionally, capture hangs on primary camera. I am yet to figure out the root cause. It may be a USB hiccup or ZWO driver bug, who knows. But it goes like this most of the times. New exposure is started. Ekos waits for 30 minutes more than expected and declares that exposure hangs. Ekos restarts CCD driver. Ekos cranks its re-initialization procedures and starts a new exposure. KStars crashes.
Once I caught this in real time and watched how it crashes. Immediately after that I restarted KStars, without touching any devices or cables. I had to agree to kill and restart INDI. I reloaded the schedule and it successfully continued from there.
A couple of thoughts here. First, Ekos waits for too long before doing anything. I understand there is no single timeout value that everybody would like. Can I configure it somehow?
Second, restarting just one driver on the fly seems too tricky. Stopping the whole session, terminating INDI server, waiting for a configured time interval and restarting the schedule might be easier and work more reliable.
Read More...
I use bin 2 for guiding with an ASI174MM Mini camera. Latest KStars (3.7.0 from Ubuntu PPA) resets this setting to 1 on each new session most of the time. I have to change it to 2 manually each time. A couple of times it actually started with 2 on its own. I have no idea how those sessions were different from others.
Several older versions worked fine in this regard.
Tell me if you need any particular verbose logs or files.
Read More...
I have similar problem. I use EKOS with local profile. After latest upgrade, it silently does not connect the EFW device, even though it starts the driver. I changed EKOS profile to use INDI 'remotely' and start INDI server manually. Now it works again. Didn't have time to dig anything out of the logs yet.
Read More...
I set 'locked to G' in AF filter settings, so that it runs AF with G filter no matter what is the Capture's current filter.
I run AF at the beginning of each job, every N (usually 30) minutes, and when temperature drifts 0.7°C. The last two effectively randomize what would be in the filter wheel right before AF starts.
Yes, I do have AF Overscan too.
Read More...
I am out of home for the next three weeks.
I have zero offsets for everything but B. All filters locked to G for AF. Adaptive start position is enabled and temperature compensation coefficients are set for all filters to the same value.
Read More...
I had a multiple jobs schedule last night. All lights jobs have Track, Align, Focus, and Guide boxes checked. Scheduler runs a few jobs successfully. Then next unlucky job slews to target and hangs right on initiating focus. I have not touched anything on UI by this point yet. I noticed the problem and hit just the Auto Focus button manually. It ran the focus, then Scheduler picks up from there and continues just fine.
The exact same thing happened twice: 18:49:44 and 20:05:41.
Read More...
I had a long schedule last night. A few jobs went through happily. Next job started, focused, aligned, switched filter wheel and sat idle. See around 00:47:50 in the log. At 00:51 I noticed that and hit the stop button in the Capture module (not the Scheduler). It cranked through its error handling and successfully restarted and kept working fine through the rest of the night.
This is not a new error. I saw it multiple times over last couple years. Sometimes, like this night, I see the sequence in Capture correct, just not running. Sometimes the sequence is empty, like not loaded from specified file.
Read More...
I caught an even better one last night! I only shot H subs, so only one simple flats job at the end. But instead of having the '231115' prefix from the schedule's target name it borrowed the 'Rosette_11' prefix from the last executed lights job. This simple scenario used to work fine before and I had no updates last days. The only new thing last night was that my schedule has two groups of jobs cycling through each for a few hours.
Read More...
3.6.7 Build: 2023-10-14T21:36:52Z, the latest from Ubuntu PPA. I saw this issue in 3.6.6 too, each night when I did RGB.
Read More...