Hi,
I have the same symptoms with my setup now and then. Also sometimes kstars stays active, but parking is really weird.

I'm not certain the 'illness' is the same, but my suspicion is that it has to do with how ioptron parks the mount.
More specifically, imaging -after- the mount has been parked before during that session.

When using the parking command from the handcontroller, it parks and then 'blocks out'. Maybe this has to do with it?

In that case, here is an idea for a driver feature:
Parking emulation. Issue a goto (horizon, North for example) and disengage tracking.

Last night ran a mosaic

Thanks Bart. I have got into the habit of always restarting the Pi before each session, I think I will also restart the mount each time. Ioptron parking is a little strange. Since I am running the latest firmware it does seem to be behaving much better.

I know you said you had the latest version of Kstars/EKOS/INDI but there was an issue with KStars 3.5.2 where the Fitsviewer would run out of memory and crash KStars after a while. I have the latest Astroberry which is still at 3.5.2 and I know that if I leave FITS viewing on while doing acquisition then KStars will randomly crash at some point in the night. I have seen this directly on occasion where a debayering  error pops up and then KStars crashes. INDI keeps running in the background.

This was supposedly fixed in 3.5.3 ( Fitsviewer crashes when imaging with Altair Hypercam 183c - Kstars 3.5.2 ) so if you do have 3.5.3. then this should not be the issue. If you're on 3.5.2 then turn off the FITS viewer during acquisition and give it a try.

I am running 3.5.3 but just to be sure last night I turned off the fits viewer and the whole session ran flawlessly.

I had the same problem on RPi 4 with Raspbian 10 as 32bit edition. It failed after a while due to problems with memory allocation. Its not a memory leak but it has do do that EKOS holds several images and pixmaps in its memory. Its not only the Fitsviewer, focusing and aligning have their own images that consume memory. In this combination - and depending upon the CCD frame sizes - it reaches memory allocation limits and crashes.

Resolutions:

1. Turn off the fitsviewer. The latest captured frame is also visible in the Manager, so no urgent need for using the fitsviewer.
2. Use a 64bit version of your OS. I changed to the 64bit beta version of Raspbian and have no problems since

HTH
Wolfgang

Same issue here, crashed 2 times in one night, both after one hour or so.

I am now switching off the fits viewer when I don't need it. It's is a bit of a pain because I like to be able to see a stretched version of the last sub. Since I have been doing this there have been no more crashes. I do notice that when I stop EKOS in the morning after a session the Kstars always quits (crashes?) too. If I stop EKOS before my session Kstars continues to run. Not really a usability issue but might point to the same problem.

Wolfgang mentioned "The latest captured frame is also visible in the Manager". I don't see the last captured frame anywhere except in the fits viewer. How to I make it visable and what is meant by "the Manager"?

 

The Manager is the tab where you are starting EKOS from:



You need to select "Summary Screen Preview" in Options -> EKOS -> Capture:

 

Thanks you so much! I never understood why I couldn't see my image on the Manager Screen. Now it all makes sense and once the session is started I can just display the Manager screen.

 

Crashed again last night with the fits viewer off. Same as before I find the scope pointing straight up. When I restart Kstars I get the message that a version of Ekos is still running. I am still running 32bit Rasbian so I guess I will try moving to the 64 bit version.

You have to love Linux where changing to a 64 bit kernel requires adding one line to a text file followed by a reboot.

I found that KStars continued to crash for me if the summary screen preview was enabled. i believe it still needs to do same image processing as the FITS viewer to display in the manager window so continues to eat memory over the night.

Looking forward to hearing how enabling the 64bit kernel works since KStars will continue be a 32bit application unless rebuilt as a 64bit one.

I personally build the entire INDI / KStars stack on a 64bit Debian 10. With basic Linux knowledge it's not that complicated. It's more or less copy-pasting the instructions available where the code resides.