I have rebuilt INDI and KStars (master) but the situation persists.
Here is an excerpt from the logs
<code>[2022-05-04T19:32:01.701 EDT INFO ][ org.kde.kstars.ekos] - "Starting INDI services..."
[2022-05-04T19:32:01.730 EDT INFO ][ org.kde.kstars.ekos] - "INDI services started on port 7624. Please connect devices."
[2022-05-04T19:32:01.796 EDT INFO ][ org.kde.kstars.ekos] - Ekos received a new device: "GPhoto CCD"
[2022-05-04T19:32:01.936 EDT INFO ][ org.kde.kstars.indi] - GPhoto CCD : "[INFO] Debug is enabled. "
[2022-05-04T19:32:09.010 EDT INFO ][ org.kde.kstars.indi] - GPhoto CCD : "[INFO] GPhoto CCD is online. "
[2022-05-04T19:32:09.012 EDT WARN ][ default] - QObject: Cannot create children for a parent that is in a different thread.
(Parent is ClientManager(0x55976c30d0), parent's thread is QThread(0x55951cad90), current thread is QThread(0x7f580307a0)
[2022-05-04T19:32:09.013 EDT INFO ][ org.kde.kstars.indi] - GPhoto CCD : "[INFO] Detected Canon Inc. Model Canon EOS REBEL T2i. "
[2022-05-04T19:32:09.014 EDT INFO ][ org.kde.kstars.ekos] - "GPhoto CCD" Version: "3.1" Interface: 10 is connected.
[2022-05-04T19:32:09.014 EDT DEBG ][ org.kde.kstars.ekos] - 1 devices connected out of 1
[2022-05-04T19:32:09.015 EDT INFO ][ org.kde.kstars.ekos] - All INDI devices are now connected.
[2022-05-04T19:32:09.229 EDT CRIT ][ org.kde.kstars.indi] - INDI driver "indi_gphoto_ccd" crashed!
Use the telescope simulator to satisfy EKOS need for a mount driver. Then choose the camera driver for Via in the EKOS guide tab if you are using the internal guider. If using PHD2. Choose the camera driver for the Mount in the connections setup.
You have subframe selected with a box size if 80 and no star selected.
I built from master on two systems recently and now KStars crasher when starting a profile containing GPhoto. However I see no recent updates have been done to the driver itself to explain it.
Attached at my GDB records from a pair of Raspberry Pi 4.
Fortunately the Canon DSLR driver saved my night out.
USB2 versions of the ASI 120 don't work well with Linux. There is a compatibility firmware you can install, which I believe you have. But it's still unreliable. And there's nothing we can do about it because it's a hardware issue in the USB controller.
Regarding your Coma Correction aberrations. You probably need check the back focus distances from it to your sensor.
At 600mm, your CC specifies 51.5mm back focus.
The ASI 533 has 17.5mm from the M42 T-thread. So you need to make up 34mm in spacers.
I don't really have a great answer for you. But I took a closer look at the behaviour I see with my camera.
My RAW images are supposed to be 5184x3456.
When set to FITS, the viewer tells me the correct dimension.
When set to Native, The viewer tells me 5202x3465. However the RAW files actually are 5184x3456 in Photoshop.
If I open an external image that was captured with just the camera normally, It comes up with 5202x3465 in the FITS Viewer.
Curiously, DeepSkyStacker also shows my raw image files are 5202x3465. But a FITS image is still 5184x3456 DSS. Because of this I can not use dark frames captured in RAW format with FITS lights.
It probably has something to do with debayering.
I think your settings probably kept resetting because you have a sequence in the queue made with those values and they are being written back to the driver when the sequence runs. That will change the frame size in FITS mode, but not in Native.
This is a quirk of DLSR's. On my Canon T3i, the RAWs have a slightly different size than a FITS. Pick one and stick to it.
This is already much better. Thank you.
I took it upon myself to try adjusting the rendering levels. I appear to get improved performance by setting int level = 2, minfov = 60, minfov /= 3. That seems to work well with only level 3 and 5 available and doesn't try to load too much level 3 detail at once. But that should probably only be changed when offline cache is used. So that might be worth considering. It might also be a worthwhile to have Level 2 images in the cache as well.
I should also mention I'm testing this on a Pi4 8gb with a USB3 SSD system drive, so the read speed are about as good as it can be on a Pi4 B+.
I found out this feature is in development. Which is fantastic! I've already been playing around with it. But seems there are a few issues to iron out. Good thing I don't have epilepsy!
There are a few glitches in the rendering. The flickering sometimes happens when I zoom in a lot then hit an arrow key to pan the view. I noticed sometimes the view doesn't update until I pan that way, but the flickering is only when very zoomed in. The background scale also doesn't always match the zoom level.
Set it to 100 Percent instead of defining pixels.
FYI for anyone else encountering build issues that resemble
. I had a bit of an issue compiling KStars with the script recently when the script did not properly recompile updates to Stellarsolver 2.0. Although it looked like it recompiled it, something old must have remained that caused an issue. Solution should be as simple as deleting old build files.
Although your build script should have taken care of it, I've just compiled Stellarsolver all on its own. If KStars complete's its build after this, I'll bring this issue to the AstroPi3 script thread. At this moment, it appears to be going well.