I have a very repeatable pattern that leaves Kstars partially dead, INDI still running and abnormal operation:
Initial condition - 3 filter sequence in operation - HA filter complete all 20 shots (this is PRE Flip) - EKOS starts filter change - fails focus 3 times and then KSTARS crashes partially - guiding is still going on but all other functions are dead until morning twilight - mount does not park (OnStep controlled properly suspends due to west meridian error to prevent damage)
The visual pattern of this error is extremely exact (see images) and it looks like there is a failure to perhaps find the filter, BUT looking in the logs I can see that the focus process is happening but SOMEHOW the QHY Camera has suddenly flipped from mode 0 to mode 1 (or at least INDI/Kstars think it has) and thus rejects the image
This leaves the process continuing and repeating but with nothing to work with - this appears like an infinite loop in process - not sure exactly where KSTARS dies, but when the system is viewed in the morning it is not running but INDI is and still attached - the following is the start of the problem right after filter change to OIII - inspecting the analysis view I can see that guide images are still coming in but obviously once the mount hits median stop in the mount all that goes to pot....
In my estimation since I have repeated twice, the root cause is the QHY mode flip which is either false positive or legitimate defect in QHY driver, but the error handling is ODD in this case (a use case that was never expected?)
I have found a relationship between this issue and LOGGING, hence my working theory is there is a contention in the I/O processes for image writing to the disk vs logging:
same setup as above, but this time I have logging on verbose to try and capture more information
Auto run starts but cannot even finish focus routine before kstars crashes - in the morning I attempt to take test images with same setup - downloads are not working or extremely slow: test with OTHER SW connected to indi -> same result - Next I turn OFF logging (disable setting)
Image now download as expected - no problem with speed or delay
So I suspect that the start of the problems above is nothing more than the increased activity during focus and schedule = more logging = delay = more logging = feedback loop = crash
Is there perhaps a common writer object that is being used for both image to disk and log to disk?
or are they perhaps on the same thread? and blocking?
FYI I have and SSD with gigs of free space and raspbian confirms the health and speed are good