Will the polar alignment fix be made available in the current stable release or is it advisable to move on to the nightly release?
For me, on a different mount, I need to enable tracking to enable the camera.
Since all the hardware seems to have been replaced it is difficult to understand what might be going on.
If the errors do not seem to be initiated due to application usage patterns then if it were me would try defining a new profile with just your mount and a single camera. Dome, focuser, GPS and so on disconnected. A minimal setup to see if a stable system can be obtained at some point. Then build it back up slowly towards your present configuration working towards the focuser and dome last. See if the problems reappear with a particular device or some number of devices. Testing each configuration to the extent possible. Its a pain but could perhaps expose another viewpoint.
I have been having the same issue getting solver to work and also see the polar alignment disable message.
Bringing up a new configuration having updated to the recent stable release. Redcat 51 scope and ASI294 camera. FOV: 264'x180'
After doing the following two things the solver started working but the polar alignment message was still there.
First I had 6 configurations defined as seen in the telescope indi panel under the options tab and deleted them all except the RedCat one.
Second and this is probably not generally useful. The ASI294 has two modes of operation.
2.32µm 8288x5644 22M (bin1 14K Full Well, 12bit ADC)
4.64µm 4144x2822 11M (bin2 66K Full Well, 14bit ADC)
I had made the mistake of deciding to use bin2 and setting up Ekos using those values. Instead changed all the values to the first mode. Then used the bin setting on the various screens as usual.
After making the changes it solved using the internal guider for the first time various targets with good response times.
Lost the weather at that point so will see if it holds up next time.
Take a look at the WeatherRadio project for a complete project.
Prior to that I used the MLX90614 in a home grown project for the purpose you outlined. Firmata to obtain the sensor data and the existing INDI Weather monitors to decide on warning messages or closing the roof. Attaching As an example, some Arduino Firmata based collection code that sends the data over USB.
I will offer what I experienced this week in case it is related.
For the first time I captured a few narrowband images (M16) and also for the first time tried running WBPP. Took Bias, Darks and Flats to match the Light setting including temp.
Using ASI1600MM up to 5 minute exposures there was a lot of amp glowin the Darks and Lights. The actual signal was weakest using the Sii filter.
I ran WBPP with all the processing steps through integration checked. It chugged along for a while and then terminated processing the Sii filter with a message along the lines of:
"Select background area with a higher level of signal, it could have high level of clipped data."
I did not know what to make of that so went looking for how to run WBPP and came across Adam Blocks tutorial.
One section is on setting a Pedestal value so in WBPP I set the value to 100 and then the WBPP script could run to completion. That is as far as I got yesterday, with 3 master images that sort of seem okay.
In the past I have had version issues but it was due to having done local builds. The library directories involved and their search order were causing a mismatch with the $PATH sequence.
I am also running on x86_64 20.04, KStar 3.5.4 stable and show the same version for those files you list. I do not appear to have the undefined symbol error to which you linked in the logs. Not noticing any current problems, using ZWO camera and filter wheel. Running updates on a weekly basis.
Running KStars 3.4.3 stable, ubuntu 20.04, Intel NUC
It has been happening on my system for a long time.
Sometimes KStars crashes during initial startup it seems happen around the time 6 of the 9 top level Ekos icons have been displayed. Retry a time or two and it will get through the startup and run okay so it has not been a big issue.
Ran it today using ekos-debugger and got the attached files.
It gives a list of what is on hold. I added libindi-*
It used to be that Launchpad would build the packages immediately, or with little delay. But unfortunately, this free service has been degrading as of late. The only way to reliably do this is by a private PPA server, but that would cost quite a bit in terms of setup and maintenance. Perhaps we can come up with a way to cover the costs for such PPA.
If funding a server is needed I'd suggest a new entry to give the issue some visibility. Assuming it goes ahead something prominent on the web page to show progress towards a goal. It does not make sense for a project like this to be struggling for the wont of a server.