Hello everyone and happy to be here on this forum (it's my first post!)
My name is Marco and since a month I decided to switch from SGP to Astroberry-Kstars-Ekos and I must admit that I truly love the INDI platform even if at first I asked myself if everything would have worked fine with my equipment, but actually it did! Much better than on Windows I have to say.
Now talking about the only real issue I'm facing and I cannot get around..I run Kstars and Ekos on a raspberry PI 4 with Astroberry, so I went for the headless approach and mounted my raspberry directly on the refractor scope.
I'm experiencing random crashes due to memory I believe. This happens if I use Kstars with DSS images pretty often and I can understand that, so I decided to do not have those overlays. However the issue sometimes still persists and I launched Kstars via terminal so I could see the output which can be seen here:
Do you think it could be related or be the same? I will try later tonight and let you know how it goes. I tried to go through my memories on when these random crashes happened throughout the past month and actually I think the solver was 90% of the time involved.
I tend to get crashes when using internal solver. Try opening the options on the alignment page, and select "Local astrometry" for the solver instead of "internal solver". You may need to run "sudo apt-get install astrometry.net" from a terminal, if it isn't installed already.
It will use the same index files you've already installed.
Thank you Kevin! I'll try that as well indeed. Last night happened again twice while doing load and slew from the alignment panel, same mmap error which leads to SIGSEGV and brutal death of KStars..funny thing is that it always dies on the same file: 4107.fits. I think this is a mere coincidence, but it's something that notheless I've noticed. A friend of mine also suggested to try increasing the swap, which by default is 100Mb, to 2-4Gb or increase the max_map_count value, that is by default 65536, with the command:
sysctl -w vm.max_map_count=131072
I guess I'll try to make changes one by one until I get things stable on my Raspberry. At least now I'm certain that the responsible is the solver and is memory related, I just need to know how to replicate it predictably.
By the way I'm running the latest software from PPA, so I should be all up-to-date.
Thanks again Kevin!
Hey Nou, unfortunately it didn't help..it's the first thing I tried, but surprisingly crashed at the first solve I did :/
I can't seem to be able to replicate it using the simulator, my theory is that the simulator solves immediately without the need to scale down to lower FOVs index files, that would also explain why it always crashes at 4107.fit, which should be 22'x30' of the Thyco Catalog.
Another user seems to have experienced the same issue
, but he wasn't able to fix it.
Thank you guys for trying to help here, beside this issue which can be even dangerous when it's doing the meridian flip and I'm sleeping hoping that everything goes ok, everything else works really well!
Hope to sort it out, would be a shame to not be able to use the Ekos-KStars solution for my astrophotography.
Do you know if you're using a 32bit or 64 bit Linux? I've not kept up to date with Astroberry but I know that I had issues with Astroberry and using a 32 bit o/s. I've got a lot better stability of the system using a 64 bit Linux but I use a my own setup using ArchLinux and not the Astroberry or StellarMate that most people use. However, you can find that most people tend to get better stability if it's a 64bit OS.
RPI 4 B (4Gb) running Manjaro ARM
SkyWatcher Esprit 80ED
ZWO ASI1600MM Pro
PrimaLuceLab Sesto Senso 2
lscpu returns armv7l, so I believe it should be 32bit (I'm running astroberry on a PI4 8Gb and waiting for the 64bit update since Raspbian it's still in beta..)
However I'll post the lines before the system crashed of last night session.
FWIW, I use Raspbian 64-bit, and have better stability than I did on 32-bit. I build 64-bit INDI and KStars from source. There might be 64-bit ARM .deb packages somewhere, I don't know, I haven't looked.
That being said, I still had a crash or two using the internal solver, so I switched to using an external one, and those problems went away.
Yes, when I was preparing the session on the Crescent yesterday and I ran load and slew to recenter the target from the previous night, it crashed during solving.
This is the FIT file
, I attach the
log as well
in case it could be useful.