Thanks! I just came across this problem after a recent indi update.
I think your original problem before it got worse was the exact same one I had
Solved by reinstalling kstars and removing libstellarsolver.
Ran the following 3 commands and all ok now
sudo apt-get remove kstars-bleeding
sudp apt-get remove libstellarsolver
sudo apt-get install kstars-bleeding
I've seen similar problems posted previously but don't see a solution.
I just updated my OS from ubuntu 18.04 to 20.04 and since doing this. Kstars crashes just after capturing an image in the align (solver).
Possible some conflicting versions of libraries that do source extraction.
Back trace pasted below. Would anyone know what I've done wrong? thanks
#0 0x00007ffff4f9ef26 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#1 0x00007ffff68282eb in InternalExtractorSolver::runSEPExtractor() () from /usr/lib/x86_64-linux-gnu/libstellarsolver.so.2
#2 0x00007ffff6834968 in ExternalExtractorSolver::extract() () from /usr/lib/x86_64-linux-gnu/libstellarsolver.so.2
#3 0x00007ffff683b39c in ExternalExtractorSolver::run() () from /usr/lib/x86_64-linux-gnu/libstellarsolver.so.2
#4 0x00007ffff4f9e9d2 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5 0x00007ffff6b0b609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#6 0x00007ffff4869133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thanks for the explanation Wolfgang. Yes I understand about not adding features until refactoring. Makes sense.
Thanks Wolfgang, that makes sense for the first target. But I think there is still a problem. All subsequent targets (which are far from the moon) get pushed out to the next night. Even though they can be observed this same night.
For example, above, KR_Aur is too close to the moon and is invalid. However the second entry (CH UMa) is actually in a good position (far from moon and 54 deg altitude). The problem is this target gets pushed to the next night.
I would expect the scheduler to skip the invalid entry for KR_Aur and start observing CH_Uma next but it will not.
If I delete KR_Aur, then then CH UMA will flip back to tonight and can be scheduled as expected.
I think I'm able to reproduce with that file
I manually set the time in Kstars to Jan 16th 22:15 and loaded it. (my location set to Cork, Munster, Ireland)
The first job is scheduled for the next day (17th) but if I delete the first row and click the 'reset and reevaluate' button they all get corrected to the 16th
Thanks, here's a zip of the schedule from screenshot 1 above. I just tried loading it now (5:20PM local time) and its actually fine..... Will try play with date-time settings to try to reproduce.
That is strange alright. The only other suggestion I have is to clean the USB cable connectors with contact cleaner. If you live in a humid climate. I have had some strange things happen USB cables. Its rare but does happen.
If you can open a terminal and run dmesg you might see some log messages relating to serial/USB cable problems
What baud-rate have you selected in the INDI connection settings? Could be worth changing it to test it out
I've seen this behaviour a few times. I think I've found a clue as to what causes it.
Probably affects me more than most people as I regularly load the scheduler with 30 or 40 short jobs for a single night.
The behaviour I see is that some 'valid' jobs get pushed out to the next night. Even though they could/should be scheduled right now.
I have 2 screenshots which explain the problem and also show how I work around it.
Screen shot 1:
This screenshot was taken on the night of Jan 16. However some jobs (example rows 2 & 3) are at a good elevation and moon distance right now but get pushed out to tomorrow (17th Jan)
NOTE: Take note of the first row with a <0 score. Deleting this job and clicking the refresh/reschedule button fixes it (see screenshot2)