[kstars] [Bug 479457] Clarify phrase in kstars/ekos/opsekos.ui
https://bugs.kde.org/show_bug.cgi?id=479457 Wolfgang Reissenberger changed: What|Removed |Added CC||wreis...@gmx.de Status|REPORTED|CONFIRMED Ever confirmed|0 |1 --- Comment #1 from Wolfgang Reissenberger --- Changed to <html><head/><body><p>Minimal duration of a meridian flip. Increase this value if Ekos reports that a meridian flip has failed because the pier side did not change. A good estimation for this value is at least 50% of the typical duration of a meridian flip.</p></body></html> Better? -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 471373] EKOS: Mosaic Scheduler and job completion conditions error
https://bugs.kde.org/show_bug.cgi?id=471373 Wolfgang Reissenberger changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #4 from Wolfgang Reissenberger --- The refactoring is still ongoing, and without it we agreed not to touch the scheduler. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 471373] EKOS: Mosaic Scheduler and job completion conditions error
https://bugs.kde.org/show_bug.cgi?id=471373 Wolfgang Reissenberger changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |NOT A BUG --- Comment #3 from Wolfgang Reissenberger --- This behavior makes sense, but the current scheduler has no option to group scheduler jobs and repeat this group. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 465324] KStars 3.6.4 Beta, Focus module - total crash repeatable 4 times
https://bugs.kde.org/show_bug.cgi?id=465324 --- Comment #6 from Wolfgang Reissenberger --- closed -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 465324] KStars 3.6.4 Beta, Focus module - total crash repeatable 4 times
https://bugs.kde.org/show_bug.cgi?id=465324 Wolfgang Reissenberger changed: What|Removed |Added Status|REPORTED|RESOLVED CC||wreis...@gmx.de Resolution|--- |FIXED Version Fixed In||3.6.4 --- Comment #5 from Wolfgang Reissenberger --- Crashing drivers causing KStars crash fixed, see commit dd1ec285bf6aca12281b840945c29b46e0423777 -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 464775] Remote slewing and plate-solving target update problem
https://bugs.kde.org/show_bug.cgi?id=464775 --- Comment #1 from Wolfgang Reissenberger --- There is no stable way to reproduce this issue. I can confirm, I could observe it and that there were situations when the target was not set. But after recompiling everything it *seems* to work - no matter whether the INDI server is local or remote. It looks like a concurrency issue... -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 451687] Attempted Meridian Flip causes great confusion
https://bugs.kde.org/show_bug.cgi?id=451687 Wolfgang Reissenberger changed: What|Removed |Added Resolution|WAITINGFORINFO |FIXED Status|NEEDSINFO |RESOLVED --- Comment #3 from Wolfgang Reissenberger --- Please use the forum and provide your logs, we‘ll help you. I‘m closing the bug, since it’s outdated. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 452794] Saving a schedule does not save the associated fits file
https://bugs.kde.org/show_bug.cgi?id=452794 Wolfgang Reissenberger changed: What|Removed |Added Resolution|--- |NOT A BUG Assignee|mutla...@ikarustech.com |wreis...@gmx.de CC||wreis...@gmx.de Status|REPORTED|RESOLVED --- Comment #1 from Wolfgang Reissenberger --- The scheduler job only saves the file location, not the file itself. As long as you don't move the reference file, the scheduler will work as expected. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 436036] Meridian flip not working consistently
https://bugs.kde.org/show_bug.cgi?id=436036 Wolfgang Reissenberger changed: What|Removed |Added Assignee|mutla...@ikarustech.com |wreis...@gmx.de Status|REPORTED|NEEDSINFO CC||wreis...@gmx.de Resolution|--- |WAITINGFORINFO --- Comment #2 from Wolfgang Reissenberger --- There have been several fixes for the meridian flip. Is the problem still present in the current KStars version? -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 451687] Attempted Meridian Flip causes great confusion
https://bugs.kde.org/show_bug.cgi?id=451687 Wolfgang Reissenberger changed: What|Removed |Added Assignee|mutla...@ikarustech.com |wreis...@gmx.de -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 451532] autofocus filter (1st in sequence) overrides LOCK filter & OFFSETS
https://bugs.kde.org/show_bug.cgi?id=451532 Wolfgang Reissenberger changed: What|Removed |Added CC||wreis...@gmx.de Assignee|mutla...@ikarustech.com |wreis...@gmx.de --- Comment #1 from Wolfgang Reissenberger --- Sorry for the late response, but do you have a log available? If not, could you reproduce it with the current KStars version? -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 451687] Attempted Meridian Flip causes great confusion
https://bugs.kde.org/show_bug.cgi?id=451687 Wolfgang Reissenberger changed: What|Removed |Added Resolution|--- |WAITINGFORINFO CC||wreis...@gmx.de Status|REPORTED|NEEDSINFO --- Comment #1 from Wolfgang Reissenberger --- Sorry for the late response. Do you have the logs available? If not, could you reproduce the same with the latest KStars version? -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 441164] Schedule loading does nothing for some files in Object & Sequence Selection
https://bugs.kde.org/show_bug.cgi?id=441164 Wolfgang Reissenberger changed: What|Removed |Added Resolution|WORKSFORME |FIXED --- Comment #3 from Wolfgang Reissenberger --- Merge request available in master -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 441164] Schedule loading does nothing for some files in Object & Sequence Selection
https://bugs.kde.org/show_bug.cgi?id=441164 Wolfgang Reissenberger changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from Wolfgang Reissenberger --- Fix published as MR!393 (https://invent.kde.org/education/kstars/-/merge_requests/393) -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 441164] Schedule loading does nothing for some files in Object & Sequence Selection
https://bugs.kde.org/show_bug.cgi?id=441164 Wolfgang Reissenberger changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED --- Comment #1 from Wolfgang Reissenberger --- The problem is the "&" in the profile name. If you rename your profile to a name without the ampersand, the Scheduler loads it. Looks like an encoding problem... -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 416173] New: EKOS hangs when an INDI driver crashes
https://bugs.kde.org/show_bug.cgi?id=416173 Bug ID: 416173 Summary: EKOS hangs when an INDI driver crashes Product: kstars Version: 3.3.9 Platform: Debian stable OS: Linux Status: REPORTED Severity: major Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: wreis...@gmx.de Target Milestone: --- SUMMARY When an INDI driver crashes and gets restarted by the indiserver, EKOS does not handle this properly. In these cases, EKOS simply hangs and KStars needs to be killed. STEPS TO REPRODUCE 1. Start KStars and connect to an INDI server 2. kill the process of one of the INDI drivers OBSERVED RESULT On the INDI side, the INDI server restarts the driver. EKOS simply hangs. In the debugger, the problem occurs in INDI::BaseClient::disconnectServer() at line 291: listen_thread->join(); It seems like listen_thread is waiting for something. At least, it does not terminate as expected. EXPECTED RESULT EKOS should handle the driver restart as offered by the INDI server. SOFTWARE/OS VERSIONS Linux: Debian 10, Raspbian 9 and Raspbian 10 show the same behavior. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 409125] Observatory module
https://bugs.kde.org/show_bug.cgi?id=409125 Wolfgang Reissenberger changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #10 from Wolfgang Reissenberger --- Should be in one of the nexts nightly builds. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 409125] Observatory module
https://bugs.kde.org/show_bug.cgi?id=409125 --- Comment #8 from Wolfgang Reissenberger --- Ah, I found the problem. In my simulator setup, I had dome radius etc. all set to 0. When I set the dome radius to 5m, it's working fine. OK, should be ready for testing. I posted a new diff: https://phabricator.kde.org/D4 -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 409125] Observatory module
https://bugs.kde.org/show_bug.cgi?id=409125 --- Comment #4 from Wolfgang Reissenberger --- Jean-Claude, I need you help for testing, since I am not sure whether slaving is working appropriately. Could you please check out the branch observatory_work_motion from my kstars clone: https://github.com/sterne-jaeger/kstars/tree/observatory_work_motion I am testing with dome simulator and telescope simulator. When I turn on slaving, the dome moves to 270° - no matter where the scope is pointing to. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 409125] Observatory module
https://bugs.kde.org/show_bug.cgi?id=409125 --- Comment #2 from Wolfgang Reissenberger --- The buttons for moving the dome and one for abort is more or less straight forward. But what functionality do you expect from the slaving button? For me it looks like it is OK when slaving is set up in the INDI configuration (as well as snoop devices etc). Or do you want to be able enabling and disabling slaving during runtime? -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 409125] Observatory module
https://bugs.kde.org/show_bug.cgi?id=409125 --- Comment #1 from Wolfgang Reissenberger --- OK, I'll do my best. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 405325] Meridian flip if HA>
https://bugs.kde.org/show_bug.cgi?id=405325 Wolfgang Reissenberger changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #19 from Wolfgang Reissenberger --- Yepp, the fix is part of the 3.2.0 release. So maybe you are facing another problem. Please report your problem to the INDI forum https://indilib.org/forum/ - Wolfgang -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 405325] Meridian flip if HA>
https://bugs.kde.org/show_bug.cgi?id=405325 --- Comment #16 from Wolfgang Reissenberger --- Bug fix posted here: https://phabricator.kde.org/D19794 -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 405325] Meridian flip if HA>
https://bugs.kde.org/show_bug.cgi?id=405325 --- Comment #14 from Wolfgang Reissenberger --- While testing the fix to the status message, I found a more severe one: - set "Meridian Flip..." in the mount module NOT ticked - start a capturing session close to the meridian with "Meridian Flip..." NOT ticked in the capture module - wait until the mount passes the meridian - tick ""Meridian Flip..." in the mount module Result: the mount module shows "meridian flip waiting...", but it does not start as soon as the current frame is captured. Instead, capturing new frames continues. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 405325] Meridian flip if HA>
https://bugs.kde.org/show_bug.cgi?id=405325 Wolfgang Reissenberger changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED --- Comment #13 from Wolfgang Reissenberger --- OK, right, I could reproduce it. The meridian flip is executed normally, but the status in the summary tab is not correct. It remains on "Status: Meridian Flip". -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 405325] Meridian flip if HA>
https://bugs.kde.org/show_bug.cgi?id=405325 --- Comment #9 from Wolfgang Reissenberger --- A possible explanation is that the time of your mount and that of the device running Ekos are not in sync. The meridian flip relies on the ability of the mount slewing to a point that is meanwhile beyond the meridian, it changes the pier side. When your mount clock is behind, it might think meridian has not been crossed yet. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 405325] Meridian flip if HA>
https://bugs.kde.org/show_bug.cgi?id=405325 --- Comment #7 from Wolfgang Reissenberger --- Oha, OK, never heard that observatories execute a meridian flip :) I will give it a try with a simulator setup, since I do not have an observatory at hand to test it in real life. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 405325] Meridian flip if HA>
https://bugs.kde.org/show_bug.cgi?id=405325 --- Comment #3 from Wolfgang Reissenberger --- Jean-Claude, could you please be a little more specific, what the problem is? Here some background how it is built: the meridian flip is controlled by the Mount module. At the same time, in a capture schedule considering a meridian flip can be defined. When values are set in a capture schedule, the values are transferred to the Mount tab as soon as the capture plan has been startet - but not immediately when defining the values in the capture schedule. When a capture schedule is executed, the Mount module takes into account whether a capture is running a soon as the meridian flip limit has been reached. If this is the case, it waits until the next frame has been captured - that's why it signals "Meridian flip waiting ..." So in case you see this message, it behaves as planned - as long as a capture is running. Or wasn't this the case? The only thing what seems to be a bug are the different increments in the two models. Wolfgang -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 402709] scheduler does not start a sequence when frames exist although repeat until terminated is selected
https://bugs.kde.org/show_bug.cgi?id=402709 --- Comment #2 from Wolfgang Reissenberger --- The latest commit on the master branch is 2bd1ad0433ce9a0cabce2b693ebc4bc50be6e703 It seems like lightFramesRequired is not used properly, since it does not take into account, whether the image sequence is multiply run. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 402709] scheduler does not start a sequence when frames exist although repeat until terminated is selected
https://bugs.kde.org/show_bug.cgi?id=402709 Wolfgang Reissenberger changed: What|Removed |Added Assignee|mutla...@ikarustech.com |eric.dejouha...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 402709] New: scheduler does not start a sequence when frames exist although repeat until terminated is selected
https://bugs.kde.org/show_bug.cgi?id=402709 Bug ID: 402709 Summary: scheduler does not start a sequence when frames exist although repeat until terminated is selected Product: kstars Version: 3.0.1 Platform: Compiled Sources OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: wreis...@gmx.de Target Milestone: --- SUMMARY A scheduler job where 1. "repeat until terminated" is selected, 2. "remember job progress" is selected and 3. there exist more frames as the single image sequence requires does not slew to its target, but immediately starts capturing. The log shows the following entry: Job 'test' is proceeding directly to capture stage because only calibration frames are pending. I would expect that the scheduler option "repeat until terminated" starts a sequence no matter how many frames have been taken. STEPS TO REPRODUCE 1. Select the Ekos Scheduler option "Remember Job Progress". 2. Open the scheduler tab 3. Select an arbitrary target and an image sequence for light frames 3. Select the job completion option "Repeat until terminated" 4. Create a new job 5. Let the job run for at least one complete loop to create sufficient frames 6. Abort the job 7. Restart the job OBSERVED RESULT The scheduler starts immediately with capturing and issues the message that the job does contain only calibration frames. EXPECTED RESULT Slewing to the target, aligning, ..., and finally looping the capturing until it is terminated manually. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 400265] Schedule with single frame capture does not initiate meridian flip
https://bugs.kde.org/show_bug.cgi?id=400265 Wolfgang Reissenberger changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #8 from Wolfgang Reissenberger --- Fixed with diff #D17159 (see https://phabricator.kde.org/D17159) -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 400265] Schedule with single frame capture does not initiate meridian flip
https://bugs.kde.org/show_bug.cgi?id=400265 --- Comment #7 from Wolfgang Reissenberger --- Bug fix diff submitted: https://phabricator.kde.org/D17159 -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 400265] Schedule with single frame capture does not initiate meridian flip
https://bugs.kde.org/show_bug.cgi?id=400265 --- Comment #6 from Wolfgang Reissenberger --- It looks like the Capture module cannot detect the necessity of a meridian flip upfront. The Capture module records the initial hour angle. If the initial hour angle is already west of the meridian, the Capture module assumes that a meridian flip is no longer necessary. This makes sense when the Capture module is used standalone. In combination with the Scheduler, it gets more complicated. The easiest way I see is to set the initial hour angle from outside. But this needs a change in the interface. Does that make sense? -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 400265] Schedule with single frame capture does not initiate meridian flip
https://bugs.kde.org/show_bug.cgi?id=400265 --- Comment #4 from Wolfgang Reissenberger --- Well, promising that it does not cause any regressions is challenging for the Capture module :-/ But sure, yes, I will give it a try. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 400265] Schedule with single frame capture does not initiate meridian flip
https://bugs.kde.org/show_bug.cgi?id=400265 --- Comment #2 from Wolfgang Reissenberger --- What about shifting (or adding) this check to preparePreCaptureActions()? -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 400265] New: Schedule with single frame capture does not initiate meridian flip
https://bugs.kde.org/show_bug.cgi?id=400265 Bug ID: 400265 Summary: Schedule with single frame capture does not initiate meridian flip Product: kstars Version: 3.0.1 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: wreis...@gmx.de Target Milestone: --- SUMMARY Meridian flips are not initiated if a sequence has only one single frame captured - no matter how often the schedule repeats the sequence. STEPS TO REPRODUCE 1. Create a capture sequence with only one single light frame 2. Create a schedule with this sequence, select a star close before meridian and set the schedule to "repeat until terminated" 3. Start the schedule before the target crosses the meridian. OBSERVED RESULT Even if the target crosses the meridian, a meridian flip is never initiated. EXPECTED RESULT As soon as the star has crossed the meridian, the next new frame capture leads to a meridian flip before the frame capture is started. SOFTWARE VERSIONS 2.9.8 as well as 3.0.0 KDE Frameworks Version: 5.28.0 Qt Version: 5.7.1 ADDITIONAL INFORMATION This happens only for sequences contain one single frame. As soon as the sequence contains more than one single frame (e.g. LRGB), the meridian flip is running fine. The reason behind is, that in processJobCompletion() it is checked if getPendingJobCount() > 0 before checkMeridianFlip() is called. For a single capture this makes sense. In case that a sequence is contained in a schedule that repeats this schedule, this restriction does not make sense. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398466] New: No delay before first image possible
https://bugs.kde.org/show_bug.cgi?id=398466 Bug ID: 398466 Summary: No delay before first image possible Product: kstars Version: 2.9.8 Platform: unspecified OS: All Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: wreis...@gmx.de Target Milestone: --- The capture module has the option to set a delay. But this is only between two consecutive captures in the same sequence job. I would like to have it *before* a capture takes place and not afterwards. For example, if you want to shoot one frame per filter every 1 minute directed by the scheduler, this is not possible. Instead, the capture module shoots as fast as possible. There is another thing not possible: you cannot delay a capture after filter change, because exactly the first one after the change is shot immediately. Or is there another I did not discover yet? -Wolfgang -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398165] [dbus_work] core dump when starting scheduler
https://bugs.kde.org/show_bug.cgi?id=398165 --- Comment #2 from Wolfgang Reissenberger --- Oh, sorry, from the logs it seemed to be ready. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398165] New: [dbus_work] core dump when starting scheduler
https://bugs.kde.org/show_bug.cgi?id=398165 Bug ID: 398165 Summary: [dbus_work] core dump when starting scheduler Product: kstars Version: unspecified Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: wreis...@gmx.de Target Milestone: --- Application: kstars (3.0.0) (Compiled from sources) Qt Version: 5.7.1 Frameworks Version: 5.28.0 Operating System: Linux 4.9.0-8-amd64 x86_64 Distribution: Debian GNU/Linux 9.5 (stretch) -- Information about the crash: - What I was doing when the application crashed: In EKOS starting a schedule. All schedules I testet failed, no matter whether I loaded one from a file or created a new one. The crash can be reproduced every time. -- Backtrace: Application: KStars (kstars), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 [Current thread is 1 (Thread 0x7fc0027dd980 (LWP 2489))] Thread 8 (Thread 0x7fbfd8edd700 (LWP 3045)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7fc00fb2ac6b in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #2 0x7fc00fb23b33 in QSemaphore::acquire(int) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #3 0x7fc00fd2585e in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x564d6a5680d0 in ClientManager::newINDIDevice (this=0x564d6f061120, _t1=0x7fbfc802b350) at /home/wolfgang/sterne-jaeger/build/kstars-master/kstars/KStarsLib_automoc.dir/moc_clientmanager_G3M43BSKBHVHTE.cpp:313 #5 0x564d6a5c3658 in ClientManager::newDevice (this=0x564d6f061120, dp=0x7fbfc802a8d0) at /home/wolfgang/sterne-jaeger/git/kstars-master/kstars/indi/clientmanager.cpp:83 #6 0x564d6ac16eb1 in INDI::BaseClient::addDevice (this=this@entry=0x564d6f061130, dep=dep@entry=0x7fbfc8002e30, errmsg=errmsg@entry=0x7fbfd8ed0430 "Device Telescope Simulator 2 not found") at /home/wolfgang/sterne-jaeger/git/indi/libindi/libs/indibase/baseclient.cpp:629 #7 0x564d6ac17024 in INDI::BaseClient::findDev (this=this@entry=0x564d6f061130, root=root@entry=0x7fbfc8002e30, create=create@entry=1, errmsg=errmsg@entry=0x7fbfd8ed0430 "Device Telescope Simulator 2 not found") at /home/wolfgang/sterne-jaeger/git/indi/libindi/libs/indibase/baseclient.cpp:664 #8 0x564d6ac1783a in INDI::BaseClient::dispatchCommand (this=this@entry=0x564d6f061130, root=root@entry=0x7fbfc8002e30, errmsg=errmsg@entry=0x7fbfd8ed0430 "Device Telescope Simulator 2 not found") at /home/wolfgang/sterne-jaeger/git/indi/libindi/libs/indibase/baseclient.cpp:508 #9 0x564d6ac17e4b in INDI::BaseClient::listenINDI (this=0x564d6f061130) at /home/wolfgang/sterne-jaeger/git/indi/libindi/libs/indibase/baseclient.cpp:469 #10 0x564d6ac17ed5 in INDI::BaseClient::listenHelper (context=) at /home/wolfgang/sterne-jaeger/git/indi/libindi/libs/indibase/baseclient.cpp:358 #11 0x564d6ac1848a in std::_Bind_simple::_M_invoke<0ul>(std::_Index_tuple<0ul>) (this=) at /usr/include/c++/6/functional:1391 #12 std::_Bind_simple::operator()() (this=) at /usr/include/c++/6/functional:1380 #13 std::thread::_State_impl >::_M_run() (this=) at /usr/include/c++/6/thread:197 #14 0x7fc00df82e6f in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #15 0x7fc00edea494 in start_thread (arg=0x7fbfd8edd700) at pthread_create.c:333 #16 0x7fc00d6f7acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 Thread 7 (Thread 0x7fbfd9ede700 (LWP 2535)): #0 0x7fc00d6ee67d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x7fc0098f09f6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7fc0098f0b0c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7fc00fd4e06b in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x7fc00fcf79ca in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7fc00fb250f3 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x7fc0137296a5 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #7 0x7fc00fb29da8 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #8 0x7fc00edea494 in start_thread (arg=0x7fbfd9ede700) at pthread_create.c:333 #9 0x7fc00d6f7acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 Thread 6 (Thread 0x7fbfdb3c2700 (LWP 2526)): [KCrash Handler] #6 0x7fc013693ab2 in QQmlData::isSignalConnected(QAbstractDeclarativeData*, QObject const*, int) () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #7 0x7fc00fd2501
[kstars] [Bug 397650] Flats creation fails
https://bugs.kde.org/show_bug.cgi?id=397650 --- Comment #14 from Wolfgang Reissenberger --- I am still searching for the best way to restructure it. Maybe a very helpful first step is simply changing the method names to be more meaningful: processPreCaptureCalibrationStage() --> prepareEquipment() This method prepares the equipment for capturing the frames. For lights, it opens the dust cap and turns off the light. For others, it closes the dust cap, parks the scope etc. processPostCaptureCalibrationStage() --> verifyCalibration() This method more or less checks for flats, whether the ADU of the current image is in the expected range. If yes, it changes turns the preview mode off and starts the next capture. Otherwise, it determines a new exposure time and generates a new preview. Does this make sense? -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 397650] Flats creation fails
https://bugs.kde.org/show_bug.cgi?id=397650 --- Comment #13 from Wolfgang Reissenberger --- Yepp, parking mount and dome can be controlled through the calibration dialog. Flat field calibration can be fixed with D14977. The only problem is that my posted diff contains more than my correction of capture.cpp. Btw.: is there a calibration for darks and bias frames? Currently, the button is active for all frame types except for light frames. From my perspective, this does not make much sense. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 397650] Flats creation fails
https://bugs.kde.org/show_bug.cgi?id=397650 --- Comment #11 from Wolfgang Reissenberger --- The entire control flow of Capture is very tricky. Here some examples: - Preparing CCD temperature, filter, rotator, gain, ... is controlled by SequenceJob. - Setting up the equipment - dust cap, flat field source, parking mount and dome, ... is controlled by Capture. - CalibrationStage contains both equipment setup states as well as informations about the calibration process. - The calibration process is implicitly contained in the capturing - especially in setCaptureComplete() and processPostCaptureCalibrationStage(). As a first restructuring step, I want to extract the calibration process into dedicated methods. Does that make sense? -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 397650] Flats creation fails
https://bugs.kde.org/show_bug.cgi?id=397650 --- Comment #10 from Wolfgang Reissenberger --- The hotfix based on getCount() solved the problem, but now the preview mode is cycling infinitely. We need a different approach to separate a preview initiated by pressing the "Preview" button from previews created for calibration. Next attempt will be using the calibrationStage attribute. As a hotfix OK, but we need to separate the flats calibration procedure in a better way. Currently, the attribute calibrationStage is also set outside a calibration process. This makes it difficult to understand the code. But it is not so easy... -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 397776] Aborted job with given startup time not restarted
https://bugs.kde.org/show_bug.cgi?id=397776 Wolfgang Reissenberger changed: What|Removed |Added Resolution|--- |WORKSFORME Status|CONFIRMED |RESOLVED --- Comment #2 from Wolfgang Reissenberger --- OK, I see, works as designed, and I fully agree, we should not add more complexity to the current scheduler. Meanwhile, I found a scheduler setup that is more robust and leads to the same capturing behavior. Instead of defining one job with an end time and another one with this time as start time, I use - the first job with a defined end time - a second job with a higher priority value and ASAP as startup time. Since the first has higher priority, it will be executed until it reaches the end time. The second one won't start unless the end time has passed. Both jobs will restart in case that they have been aborted - so we have a more robust job schedule than before. I will set the status to "resolved/worksforme" -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 397776] New: Aborted job with given startup time not restarted
https://bugs.kde.org/show_bug.cgi?id=397776 Bug ID: 397776 Summary: Aborted job with given startup time not restarted Product: kstars Version: 2.9.8 Platform: unspecified OS: unspecified Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: wreis...@gmx.de Target Milestone: --- A SchedulerJob with a given startup-time, that aborts for example because guiding temporarily fails, will be set to "invalid" as soon as the scheduler tries to restart it. It seems like there is a misinterpretation what "start at" means. Currently, it defines a short timeframe of startup time + max 5 min when the job might start. My expectation would be that beginning from the defined time, the job might be executed. Only if the "repeat until" time has expired, it should be set to invalid. The problem is that the job starts correctly within this timeframe, but after running for a while an event happens to abort it. When the scheduler reaches "evaluateJobs()" in an attempt to restart it, the startup time has already passed for a while and leads to the state "invalid". Changing the behavior as described would make such jobs much more robust against temporarily failures. Currently, when an abort happens after the 5 min, the job will never start again. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 397650] Flats creation fails
https://bugs.kde.org/show_bug.cgi?id=397650 --- Comment #8 from Wolfgang Reissenberger --- The hot fix is submitted as #D14977. Further refactoring is not so easy :( There are in essence one where flats handling is extensively intertwined: processPreCaptureCalibrationStage() But I do not dare to modify since I do not have the equipment to test (dust cap, dome, light cap etc). Any thoughts? -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 397650] Flats creation fails
https://bugs.kde.org/show_bug.cgi?id=397650 --- Comment #7 from Wolfgang Reissenberger --- OK, I'll take over. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 397650] Flats creation fails
https://bugs.kde.org/show_bug.cgi?id=397650 --- Comment #5 from Wolfgang Reissenberger --- I could take over this point, sure. Just give me a hint whether you started already. It does not get better when it is done twice :-) -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 397650] Flats creation fails
https://bugs.kde.org/show_bug.cgi?id=397650 --- Comment #2 from Wolfgang Reissenberger --- I would also prefer replacing seqTotalCount by activeJob->getCount(), since caching the value always bears the risk that the value is not up to date. By the way, seqTotalCount is no longer used, only present in capture.h. The algorithm and its state for shooting flats is currently quite spread over the entire class, which is already a huge one. As a first step I would recommend encapsulating it inside capture.cpp. In a future step, it might make more sense having a class FlatSequenceJob derived from SequenceJob holding all the specifics for the different types of images. As a hotfix, I would replace if (activeJob->isPreview()) by if (activeJob->getCount() <= 0) -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 397650] New: Flats creation fails
https://bugs.kde.org/show_bug.cgi?id=397650 Bug ID: 397650 Summary: Flats creation fails Product: kstars Version: 2.9.8 Platform: unspecified OS: Linux Status: UNCONFIRMED Severity: major Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: wreis...@gmx.de Target Milestone: --- With the rework of the Capture module, creating flats no longer works. After creating a first preview, the module simply finishes and does neither a calibration nor does it shoot flats. The reason can be found in Capture::setCaptureComplete(). In the older version, for previews with seqTotalCount (the planned total) <= 0, this method did some cleanup and terminated. For shooting flats, seqTotalCount is set to the amount of flats to be created and is hence > 0. In the new version, simply activeJob->isPreview() is called which is also true for flats. As a result, creating flats terminates immediately after the first preview and does neither a calibration nor does it shoot flats. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 397227] PHD2 stopped guiding not recognized
https://bugs.kde.org/show_bug.cgi?id=397227 --- Comment #2 from Wolfgang Reissenberger --- Tested it on commit 9c7bebf8421ce49194ebed7ecdaa426ac143032d. Looks good! -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 397227] New: PHD2 stopped guiding not recognized
https://bugs.kde.org/show_bug.cgi?id=397227 Bug ID: 397227 Summary: PHD2 stopped guiding not recognized Product: kstars Version: 2.9.7 Platform: Debian stable OS: Linux Status: UNCONFIRMED Severity: major Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: wreis...@gmx.de Target Milestone: --- When guiding with PHD2 fails during a schedule, it causes a capture failure marking the capture as "Aborted". But when the scheduler tries to recover, the PHD2 guide adaptor returns the wrong value: guideInterface->call(QDBus::AutoDetect, "getStatus") returns "no error" despite PHD has stopped guiding. As a consequence, the scheduler simply executes the next capture sequence and does not restarts guiding. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 396742] EKOS | Capture | multiple occurrence of the same sequence job ignored
https://bugs.kde.org/show_bug.cgi?id=396742 --- Comment #12 from Wolfgang Reissenberger --- Yes, Eric made several very good comments. I made all changes he suggested and submitted a new version: https://phabricator.kde.org/D14309 For rebasing: please advise, I do not exactly know what to do. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 396742] EKOS | Capture | multiple occurrence of the same sequence job ignored
https://bugs.kde.org/show_bug.cgi?id=396742 --- Comment #10 from Wolfgang Reissenberger --- Bug fix submitted as https://phabricator.kde.org/D14280 -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 396742] EKOS | Capture | multiple occurrence of the same sequence job ignored
https://bugs.kde.org/show_bug.cgi?id=396742 --- Comment #9 from Wolfgang Reissenberger --- OK, thanks for the hint. I've installed arc and will try to use it. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 396742] EKOS | Capture | multiple occurrence of the same sequence job ignored
https://bugs.kde.org/show_bug.cgi?id=396742 --- Comment #7 from Wolfgang Reissenberger --- OK, I'll take over. I should place the patch through Phabricator, right? -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 396742] EKOS | Capture | multiple occurrence of the same sequence job ignored
https://bugs.kde.org/show_bug.cgi?id=396742 --- Comment #5 from Wolfgang Reissenberger --- Great! If you need bandwidth, I could take over the fix as well. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 396742] EKOS | Capture | multiple occurrence of the same sequence job ignored
https://bugs.kde.org/show_bug.cgi?id=396742 --- Comment #3 from Wolfgang Reissenberger --- I took a closer look into the Capture class. There is an approach counting existing images across all sequences. But there is no counterpart determining the target counts of images spanning the contained sequence jobs. Interestingly, this is fully calculated by the Scheduler - which might be the wrong place... -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 396742] New: EKOS | Capture | multiple occurrence of the same sequence job ignored
https://bugs.kde.org/show_bug.cgi?id=396742 Bug ID: 396742 Summary: EKOS | Capture | multiple occurrence of the same sequence job ignored Product: kstars Version: 2.9.5 Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Severity: major Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: wreis...@gmx.de Target Milestone: --- When an image sequence contains two identical - for example a LRGBLRGB sequence, only the first occurrence leads to a captured image. The second image with the same filter is not created. Test case: take 1x1s_RGBLumRGB.esq from Tests/scheduler in the sources directory of kstars. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 394725] crash while shooting flats
https://bugs.kde.org/show_bug.cgi?id=394725 --- Comment #2 from Wolfgang Reissenberger --- I have resolved it meanwhile. Please see my patch here: https://phabricator.kde.org/D14149 -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 394725] New: crash while shooting flats
https://bugs.kde.org/show_bug.cgi?id=394725 Bug ID: 394725 Summary: crash while shooting flats Product: kstars Version: 2.9.5 Platform: Debian stable OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: normal Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: wreis...@gmx.de Target Milestone: --- Application: kstars (2.9.5) Qt Version: 5.7.1 Frameworks Version: 5.28.0 Operating System: Linux 4.9.0-6-amd64 x86_64 Distribution: Debian GNU/Linux 9.4 (stretch) -- Information about the crash: - What I was doing when the application crashed: I launched a preview of the first sequence. After this was fine, I wanted to start the flat sequence. Surprisingly, the last entry had already started and it was not able to interrupt normally (button did not show running). After several clicks, it stopped. I deleted the last two entries and as I added a new one, kstars crashed (at least that's how I remember it). The crash does not seem to be reproducible. -- Backtrace: Application: KStars (kstars), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7f0877040e00 (LWP 609))] Thread 6 (Thread 0x7f0834d52700 (LWP 1591)): #0 0x7f08674ba7d2 in ?? () from /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-10.0.so #1 0x7f08674babb9 in ?? () from /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-10.0.so #2 0x7f08674bb43a in ?? () from /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-10.0.so #3 0x7f0869f8274c in pa_mainloop_dispatch () from /usr/lib/x86_64-linux-gnu/libpulse.so.0 #4 0x7f0869f82b4c in pa_mainloop_iterate () from /usr/lib/x86_64-linux-gnu/libpulse.so.0 #5 0x7f0869f82bf0 in pa_mainloop_run () from /usr/lib/x86_64-linux-gnu/libpulse.so.0 #6 0x7f0869f90bd9 in ?? () from /usr/lib/x86_64-linux-gnu/libpulse.so.0 #7 0x7f08674cb2c8 in ?? () from /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-10.0.so #8 0x7f0870a9e494 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #9 0x7f086f3abacf in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 5 (Thread 0x7f0837fff700 (LWP 694)): #0 0x7f086f3a267d in poll () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7f086b5a49f6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f086b5a4b0c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f0871a0206b in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x7f08719ab9ca in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7f08717d90f3 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x7f08751bd6a5 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #7 0x7f08717ddda8 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #8 0x7f0870a9e494 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #9 0x7f086f3abacf in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 4 (Thread 0x7f0849f23700 (LWP 628)): #0 0x7f086f3a267d in poll () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7f086b5a49f6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f086b5a4b0c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f0871a0206b in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x7f08719ab9ca in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7f08717d90f3 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x7f08717ddda8 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #7 0x7f0870a9e494 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #8 0x7f086f3abacf in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 3 (Thread 0x7f084bfff700 (LWP 623)): #0 0x7f086f3a267d in poll () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7f086b5a49f6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f086b5a4b0c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f0871a0206b in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x7f08719ab9ca in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7f08717d90f3 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x7f08717ddda8 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #7 0x7f0870a9e494 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #8 0x7f086f3abacf in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 2 (Thread 0x7f085bfff700 (LWP 611)): #0 0x7f086f3a267d in poll () from /lib/x86_64-linux-gnu/libc.so.6 #1
