[kstars] [Bug 398745] Crash when not closing warning pop-up on invalid sequence file
https://bugs.kde.org/show_bug.cgi?id=398745 --- Comment #6 from TallFurryMan --- Making the KSNotification::sorry auto-close would probably not fix the problem, e.g. when multiple consecutive ESL files contain invalid sequence files. Making the error blocking, and eventually auto-close to bypass the current item, is probably a good solution. A better solution would probably be to warn about the problem in the table directly before starting the Scheduler, say with an icon. That check could be done while evaluating, I believe there is a place we could do that when Scheduler computes the item duration. Although I think we don't necessarily evaluate before trying to open the sequence file, we would not in this case display any warning pop-up while running. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398635] When capture suspends because of guiding deviation, and capture is stopped, UI is in invalid state
https://bugs.kde.org/show_bug.cgi?id=398635 --- Comment #5 from TallFurryMan --- Capture has changed so much that the description doesn't match anymore. I think this should remain closed now. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398745] Crash when not closing warning pop-up on invalid sequence file
https://bugs.kde.org/show_bug.cgi?id=398745
TallFurryMan changed:
What|Removed |Added
Ever confirmed|0 |1
Resolution|WORKSFORME |---
Status|RESOLVED|REOPENED
--- Comment #4 from TallFurryMan ---
Seems this is still possible:
bool Capture::loadSequenceQueue(const QString )
{
QFile sFile(fileURL);
if (!sFile.open(QIODevice::ReadOnly))
{
QString message = i18n("Unable to open file %1", fileURL);
KSNotification::sorry(message, i18n("Could Not Open File"));
return false;
}
(...)
--
You are receiving this mail because:
You are watching all bug changes.
[kstars] [Bug 398302] Mount cannot unpark after executing parking of shutdown procedure manually
https://bugs.kde.org/show_bug.cgi?id=398302 TallFurryMan changed: What|Removed |Added Resolution|WORKSFORME |FIXED -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 397969] Scheduler Unpark Dome/Mount/Cap are unclear and dangerous
https://bugs.kde.org/show_bug.cgi?id=397969 --- Comment #7 from TallFurryMan --- Yeah good idea, I'll open a new issue for this. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398194] Warning on Scheduler job looping indefinitely visible with only one job in the list
https://bugs.kde.org/show_bug.cgi?id=398194 --- Comment #3 from TallFurryMan --- No update yet. There are now tests for the Scheduler, but they aren't stable enough and don't cover enough cases to safely work on this. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 395232] Streaks and losanges on sky chart
https://bugs.kde.org/show_bug.cgi?id=395232 TallFurryMan changed: What|Removed |Added Resolution|--- |NOT A BUG CC||eric.dejouha...@gmail.com Status|REPORTED|RESOLVED --- Comment #1 from TallFurryMan --- The streaks are present in the original HiPS data. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 382434] CCD Simulator does not provide the correct image if Telescope Simulator is moved by West/East/North/South controls
https://bugs.kde.org/show_bug.cgi?id=382434 TallFurryMan changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED CC||eric.dejouha...@gmail.com --- Comment #12 from TallFurryMan --- This scenario appears fixed in 3.4.0. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 108772] professional star chart printing wish
https://bugs.kde.org/show_bug.cgi?id=108772 TallFurryMan changed: What|Removed |Added CC||eric.dejouha...@gmail.com --- Comment #2 from TallFurryMan --- Should we consider closing this, as Cartes du Ciel does that feature beautifully? -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 396182] manual filter wheel or filter drawer option
https://bugs.kde.org/show_bug.cgi?id=396182 TallFurryMan changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|REMIND |--- --- Comment #13 from TallFurryMan --- Keeping reported, I didn't have bandwidth to check. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398301] Once "Wall" mode is used, all frame types use the "Wall" coordinates
https://bugs.kde.org/show_bug.cgi?id=398301 --- Comment #2 from TallFurryMan --- Will be verified with Capture tests. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 397970] Yet another regression on Scheduler capture count
https://bugs.kde.org/show_bug.cgi?id=397970 --- Comment #5 from TallFurryMan --- Will verify this issue with Capture tests soon. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 396182] manual filter wheel or filter drawer option
https://bugs.kde.org/show_bug.cgi?id=396182 TallFurryMan changed: What|Removed |Added Resolution|--- |REMIND Status|REPORTED|NEEDSINFO --- Comment #11 from TallFurryMan --- I am under the impression that this issue is still current. There is a workaround that consists in adding a Filter Wheel Simulator with enough movement time to allow manual intervention. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 422939] EKOS - If PHD2 connects first, driver configuration is not loaded
https://bugs.kde.org/show_bug.cgi?id=422939 TallFurryMan changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 --- Comment #1 from TallFurryMan --- There's nothing much we can do. If connected through Ekos, the Mount Driver will already be connected when PHD2 is asked to connect. If not, then it is up to the end-user to load the configuration properly. It is sufficient to load the configuration once at the beginning of the lifecycle of the mount driver. The remaining issue related to this problem is that Ekos will not close the connection properly when (1) crashing and (2) KStars exiting with Ekos still running. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 422941] EKOS - PHD2 losing connection makes guider module unrecoverable
https://bugs.kde.org/show_bug.cgi?id=422941 TallFurryMan changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 423012] EKOS - PHD2 sometimes does not see the camera
https://bugs.kde.org/show_bug.cgi?id=423012 TallFurryMan changed: What|Removed |Added Version Fixed In||v3.4.3 Status|REPORTED|RESOLVED Latest Commit||https://invent.kde.org/educ ||ation/kstars/-/commit/11130 ||020b83497e98efaf5ace4fc8922 ||83abf652 Resolution|--- |FIXED --- Comment #1 from TallFurryMan --- This is worked around by https://invent.kde.org/education/kstars/-/commit/11130020b83497e98efaf5ace4fc892283abf652. If PHD2 fails connecting to the guide camera at first, it will often succeed at the second attempt. Test test_ekos_guide waits long enough to accept one failing attempt, although it is unclear what makes PHD2 fail to connect. There are very rare cases where PHD2 fails to connect twice, and test fails. In a real-life situation, there is nothing much Ekos can do about a failing guide camera, as most of the time the INDI Profile will *not* contain that sensor. If the camera is working properly, PHD2 will successfully connect at some point. If the Guide Module is used independently, failure to connect will cause the module to remain unconnected (in terms of devices, not in terms of PHD2 connection). If the Guide Module is used through the Scheduler Module, Scheduler will attempt to connect multiple times, increasing the chance PHD2 connects. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 422941] EKOS - PHD2 losing connection makes guider module unrecoverable
https://bugs.kde.org/show_bug.cgi?id=422941 TallFurryMan changed: What|Removed |Added Latest Commit||https://invent.kde.org/educ ||ation/kstars/-/commit/11130 ||020b83497e98efaf5ace4fc8922 ||83abf652 Version Fixed In||v3.4.3 --- Comment #1 from TallFurryMan --- This is fixed by https://invent.kde.org/education/kstars/-/commit/11130020b83497e98efaf5ace4fc892283abf652. Device connection/disconnection is handled both ways. The end-user can disconnect devices from Ekos or PHD2, state will be handled properly. Connecting and disconnecting from Ekos side (repeatedly) is tested by test_ekos_guide. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 422940] EKOS - PHD2 may fail calibration without notice
https://bugs.kde.org/show_bug.cgi?id=422940 TallFurryMan changed: What|Removed |Added Latest Commit|https://invent.kde.org/educ |https://invent.kde.org/educ |ation/kstars/-/commit/f5af9 |ation/kstars/-/commit/11130 |81af460960b55bb5796d81dffbc |020b83497e98efaf5ace4fc8922 |9697b215|83abf652 -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 422940] EKOS - PHD2 may fail calibration without notice
https://bugs.kde.org/show_bug.cgi?id=422940 TallFurryMan changed: What|Removed |Added Status|REPORTED|RESOLVED Latest Commit||https://invent.kde.org/educ ||ation/kstars/-/commit/f5af9 ||81af460960b55bb5796d81dffbc ||9697b215 Resolution|--- |FIXED Version Fixed In||v3.4.3 --- Comment #2 from TallFurryMan --- This is fixed by 11130020, using the calibration timeout. This behaviour is tested in test_ekos_guide, using Simulators and Polaris as guide star. The Simulator does not move Polaris far enough for PHD2 to detect a movement, and PHD2 switches from calibrating to looping without sending a notification (failed guarantee). The calibration timeout of the Guide Module catches this situation. Note the workaround also works for guide stars that are hot pixels. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398437] Job approaching dawn is always rescheduled, preventing observatory shutdown
https://bugs.kde.org/show_bug.cgi?id=398437 --- Comment #1 from TallFurryMan --- The situation now is different. The Observatory does shut down, but a new job is started between the pre-dawn margin and the actual dawn limit. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 423012] New: EKOS - PHD2 sometimes does not see the camera
https://bugs.kde.org/show_bug.cgi?id=423012 Bug ID: 423012 Summary: EKOS - PHD2 sometimes does not see the camera Product: kstars Version: git Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: eric.dejouha...@gmail.com Target Milestone: --- SUMMARY STEPS TO REPRODUCE 1. Launch PHD2, do not connect equipment 2. Launch Ekos, Telescope and CCD Simulator, PHD2 guider 3. Check whether PHD2 connected the equipment OBSERVED RESULT 3-5% of the attempts, Ekos cannot connect to the camera. This is possibly due to the fact that Ekos asks PHD2 to connect *before* the CCD Simulator is completely connected. Not seen with telescope, maybe because the Telescope is connected prior to Camera? EXPECTED RESULT Ekos should make sure devices are fully connected before asking PHD2 to connect the equipment. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Lubuntu 18.04 (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: 5.14.1 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 422941] New: EKOS - PHD2 losing connection makes guider module unrecoverable
https://bugs.kde.org/show_bug.cgi?id=422941 Bug ID: 422941 Summary: EKOS - PHD2 losing connection makes guider module unrecoverable Product: kstars Version: git Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: eric.dejouha...@gmail.com Target Milestone: --- SUMMARY STEPS TO REPRODUCE 1. Launch PHD2, no equipment connected 2. Launch Ekos with Telescope and CCD Simulators, PHD2 guider 3. Disconnect and reconnect the Telescope simulated device OBSERVED RESULT PHD2 connects devices at step 2, and notifies the loss of the mount at step 3. Ekos is not able to start guiding as equipment is not connected anymore. It requires a manual disconnect/reconnect in the guider module to restore functionality. This may also happen when PHD2, for an unknown reason, cannot connect succsesfully to the driver at first (but will at a second attempt). EXPECTED RESULT Ekos should be able to detect the equipment loss, and attempt to reconnect. It is possible that the equipment is not connected to Ekos at all, so Ekos cannot rely on its own view of the INDI drivers (probably not the case for the mount, but is for camera). SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Ubuntu 18.04 (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: 5.12.5 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 422940] New: EKOS - PHD2 may fail calibration without notice
https://bugs.kde.org/show_bug.cgi?id=422940 Bug ID: 422940 Summary: EKOS - PHD2 may fail calibration without notice Product: kstars Version: git Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: eric.dejouha...@gmail.com Target Milestone: --- SUMMARY STEPS TO REPRODUCE 1. Launch PHD2, no equipment connection 2. Launch Ekos with Telescope and CCD Simulators, PHD2 guider 3. Remain on NCP, start guiding OBSERVED RESULT Guiding at NCP fails because PHD2 doesn't see the guide star move enough. If the guide star doesn't move at all (0 pixel offset), PHD2 will abort calibration without sending a message. In that situation, Ekos remains waiting for the end of the procedure. PHD2 is in looping mode when it abandons calibration without notice. Therefore Ekos cannot resume guiding anymore because guiding frames are being received. The UI prevents stopping because guiding is not actually active. The state machine is lost and situation cannot be recovered, even with a disconnect/reconnect. This issue, while very specific, shows that there are holes in the guiding faut tolerance. EXPECTED RESULT There should be a timeout to waiting for the calibration procedure to end. By default, not considering frame download, it takes PHD2/Simulators ~25s to calibrate when everything works, and ~75s to fail if the star doesn't move enough (there is no failure if the star doesn't move at all). Ekos should poll for PHD2 state and execute proper state machine recovery. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Ubuntu 18.04 (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: 5.12.5 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 422939] New: EKOS - If PHD2 connects first, driver configuration is not loaded
https://bugs.kde.org/show_bug.cgi?id=422939 Bug ID: 422939 Summary: EKOS - If PHD2 connects first, driver configuration is not loaded Product: kstars Version: git Platform: Compiled Sources OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: eric.dejouha...@gmail.com Target Milestone: --- SUMMARY STEPS TO REPRODUCE 1. Launch indiserver with Telescope and CCD Simulator, PHD2 guider 2. Launch PHD2, connect to devices 3. Start Ekos, connect to indiserver OBSERVED RESULT PHD2 connects before Ekos at step 2. Configuration for the mount is not loaded, specifically geographical location. When Ekos connects, it also connects to PHD2 and asks for equipment to be connected. Device configuration is not loaded, geographical location remains unconfigured, and horizon safety limits are broken as geographical location is on the equator, and park position at NCP is now at altitude zero. EXPECTED RESULT Not sure. Obviously configuration should be loaded when the first client connects. But Ekos could override and force-load configuration? In that case, PHD2 should NOT be connected before Ekos, which means it should probably be Ekos which launches PHD2 by itself. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Ubuntu 18.04 i386 (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: 5.12.5 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 414216] constellation names and boundaries move in respect to constellations for dates centuries ago
https://bugs.kde.org/show_bug.cgi?id=414216 TallFurryMan changed: What|Removed |Added Version|3.1.0 |3.4.1 -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 414216] constellation names and boundaries move in respect to constellations for dates centuries ago
https://bugs.kde.org/show_bug.cgi?id=414216 TallFurryMan changed: What|Removed |Added Status|REPORTED|CONFIRMED CC||eric.dejouha...@gmail.com Ever confirmed|0 |1 --- Comment #1 from TallFurryMan --- Constellations are located with a RA/DEC mid-point that is unrelated to stars actually. That mid-point is used to render the constellation art in the sky representation. SkyQPainter::drawConstellationArtImage only uses EquatorialToHorizontal to compute the position of the image, thus locate the drawing in J2000. So, yes, bug confirmed for me. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398192] In Ekos, stopping INDI immediately after disconnecting devices hangs KStars
https://bugs.kde.org/show_bug.cgi?id=398192 --- Comment #14 from TallFurryMan --- Jasem, could you confirm you adjusted the relevant test to verify your change? Tests/kstars_ui/test_ekos.cpp, in TestEkos::testSimulatorProfile, line 134. I don't see this in your changelog. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398192] In Ekos, stopping INDI immediately after disconnecting devices hangs KStars
https://bugs.kde.org/show_bug.cgi?id=398192 TallFurryMan changed: What|Removed |Added Version|2.9.8 |3.4.0 --- Comment #12 from TallFurryMan --- Updated version affected to 3.4.0. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398192] In Ekos, stopping INDI immediately after disconnecting devices hangs KStars
https://bugs.kde.org/show_bug.cgi?id=398192 --- Comment #11 from TallFurryMan --- Reproduced on my live (not current) system, confirming test is OK: ^C[Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". 0xb7f5bd09 in __kernel_vsyscall () (gdb) bt #0 0xb7f5bd09 in __kernel_vsyscall () #1 0xb522a7fe in __GI___pthread_timedjoin_ex (threadid=2750102336, thread_return=0x0, abstime=0x0, block=true) at pthread_join_common.c:89 #2 0xb522a604 in __pthread_join (threadid=2750102336, thread_return=0x0) at pthread_join.c:24 #3 0xb4f0e7b5 in std::thread::join() () at /usr/lib/i386-linux-gnu/libstdc++.so.6 #4 0x00c6d1bf in INDI::BaseClient::disconnectServer() (this=0x5de1f68) at /home/tallfurryman/dev/indinew/libs/indibase/baseclient.cpp:291 #5 0x0072121b in DriverManager::stopDevices(QList const&) (this=0x5679ba0, dList=...) at /home/tallfurryman/dev/kstars/kstars/indi/drivermanager.cpp:464 #6 0x007b51ab in Ekos::Manager::cleanDevices(bool) (this=0x2e879b0, stopDrivers=true) at /home/tallfurryman/dev/kstars/kstars/ekos/manager.cpp:1017 #7 0x007b525a in Ekos::Manager::stop() (this=0x2e879b0) at /home/tallfurryman/dev/kstars/kstars/ekos/manager.cpp:498 #8 0x00c19160 in EkosAdaptor::stop() (this=0x55b9530) at /home/tallfurryman/dev/kstars_build/kstars/ekosadaptor.cpp:111 #9 0x00c19160 in EkosAdaptor::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (_o=0x55b9530, _c=QMetaObject::InvokeMetaMethod, _id=13, _a=0xbfb29484) at /home/tallfurryman/dev/kstars_build/kstars/ekosadaptor.moc:210 #10 0x00c19614 in EkosAdaptor::qt_metacall(QMetaObject::Call, int, void**) (this=0x55b9530, _c=QMetaObject::InvokeMetaMethod, _id=13, _a=0xbfb29484) at /home/tallfurryman/dev/kstars_build/kstars/ekosadaptor.moc:314 #11 0xb5ca850c in () at /usr/lib/i386-linux-gnu/libQt5DBus.so.5 #12 0xb5cad87a in () at /usr/lib/i386-linux-gnu/libQt5DBus.so.5 #13 0xb5caddd8 in () at /usr/lib/i386-linux-gnu/libQt5DBus.so.5 #14 0xb5caea06 in () at /usr/lib/i386-linux-gnu/libQt5DBus.so.5 -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398192] In Ekos, stopping INDI immediately after disconnecting devices hangs KStars
https://bugs.kde.org/show_bug.cgi?id=398192 --- Comment #10 from TallFurryMan --- When the issue is reproduced, this is the stack from the event clicking the "stop" button: 1 __GI___pthread_timedjoin_ex pthread_join_common.c 142 0x751e3cd7 2 std::thread::join() 0x74e721d7 3 INDI::BaseClient::disconnectServer baseclient.cpp291 0x5611fe0c 4 DriverManager::stopDevices drivermanager.cpp 464 0x55e08b07 5 Ekos::Manager::cleanDevices manager.cpp 1087 0x55657e19 6 Ekos::Manager::stop manager.cpp 532 0x55653d89 7 Ekos::Manager::processINDI manager.cpp 527 0x55653d41 8 QtPrivate::FunctorCall, QtPrivate::List<>, void, void (Ekos::Manager:: *)()>::call(void (Ekos::Manager:: *)(), Ekos::Manager *, void * *) qobjectdefs_impl.h152 0x556934b6 9 QtPrivate::FunctionPointer::call, void>(void (Ekos::Manager:: *)(), Ekos::Manager *, void * *) qobjectdefs_impl.h185 0x5568e89f 10 QtPrivate::QSlotObject, void>::impl(int, QtPrivate::QSlotObjectBase *, QObject *, void * *, bool *) qobjectdefs_impl.h414 0x55686354 11 QMetaObject::activate(QObject *, int, int, void * *) 0x757295c8 12 QAbstractButton::clicked(bool) 0x7632e236 13 ?? 0x7632e45e 14 ?? 0x7632f8a3 15 QAbstractButton::mouseReleaseEvent(QMouseEvent *) 0x7632fa65 16 QWidget::event(QEvent *) 0x7627c04e 17 QApplicationPrivate::notify_helper(QObject *, QEvent *) 0x76239a86 18 QApplication::notify(QObject *, QEvent *) 0x76243053 19 QTest::mouseEvent qtestmouse.h 242 0x5562bd74 20 QTest::mouseEvent qtestmouse.h 206 0x5562b87c ... This is the stack from the INDI client thread: 1 syscall syscall.S 38 0x74b5a94d 2 QSemaphore::acquire(int) 0x755390b1 3 QMetaObject::activate(QObject *, int, int, void * *) 0x757298e5 4 ClientManager::removeINDIProperty moc_clientmanag
[kstars] [Bug 398192] In Ekos, stopping INDI immediately after disconnecting devices hangs KStars
https://bugs.kde.org/show_bug.cgi?id=398192 --- Comment #9 from TallFurryMan --- Refining the test, it appears the issue may source from the intrication of signals between gadgets. The code is re-entring the event loop at various places, and if the INDI server is still busy deleting properties, the code locks up in QMetaObject::Activate. Originally I thought it was the way QTest is implemented, which requires lots of deferred calls to manipulate the UI, but it seems I got the test right in the end. Jasem, I pushed D27593 with the test showing the issue. Remove the delay as specified in the differential to reproduce. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398192] In Ekos, stopping INDI immediately after disconnecting devices hangs KStars
https://bugs.kde.org/show_bug.cgi?id=398192 --- Comment #7 from TallFurryMan --- In my test, INDI client is still creating properties after 20 seconds, so I'll investigate further before calling the test proper: 1 syscall syscall.S 38 0x74b5a94d 2 QSemaphore::acquire(int) 0x755390b1 3 QMetaObject::activate(QObject *, int, int, void * *) 0x757298e5 4 ClientManager::newINDIProperty moc_clientmanager.cpp 346 0x55db7dc0 5 ClientManager::newProperty clientmanager.cpp 92 0x55e18d20 6 INDI::BaseDevice::buildProp basedevice.cpp682 0x5611822d 7 INDI::BaseClient::dispatchCommand baseclient.cpp584 0x56120c0c 8 INDI::BaseClient::listenINDI baseclient.cpp505 0x561203a1 9 INDI::BaseClient::listenHelper baseclient.cpp374 0x5611fa9d 10 std::__invoke_impl invoke.h 60 0x5612d55a 11 std::__invoke invoke.h 95 0x5612d3fd 12 std::thread::_Invoker>::_M_invoke<0ul, 1ul> thread244 0x5612d2cd 13 std::thread::_Invoker>::operator() thread251 0x5612d259 14 std::thread::_State_impl>>::_M_run thread195 0x5612d217 15 ?? 0x74e71f74 16 start_thread pthread_create.c 479 0x751e2669 17 clone clone.S 95 0x74b61323 -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398192] In Ekos, stopping INDI immediately after disconnecting devices hangs KStars
https://bugs.kde.org/show_bug.cgi?id=398192 --- Comment #6 from TallFurryMan --- I need to make very sure the test is spotting the right problem. I'll then push a differential with said test for reference. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398192] In Ekos, stopping INDI immediately after disconnecting devices hangs KStars
https://bugs.kde.org/show_bug.cgi?id=398192 --- Comment #5 from TallFurryMan --- Reproduced using indi 1.7.9, and indi git tip. Call is stuck with the following stack: 1 __GI___pthread_timedjoin_ex pthread_join_common.c 142 0x751e3cd7 2 std::thread::join() 0x74e721d7 3 INDI::BaseClient::disconnectServer baseclient.cpp291 0x5611f6a6 4 DriverManager::stopDevices drivermanager.cpp 464 0x55e083a1 5 Ekos::Manager::cleanDevices manager.cpp 1087 0x5565716b 6 Ekos::Manager::stop manager.cpp 532 0x556530db 7 Ekos::Manager::processINDI manager.cpp 527 0x55653093 8 QtPrivate::FunctorCall, QtPrivate::List<>, void, void (Ekos::Manager:: *)()>::call(void (Ekos::Manager:: *)(), Ekos::Manager *, void * *) qobjectdefs_impl.h152 0x55692808 9 QtPrivate::FunctionPointer::call, void>(void (Ekos::Manager:: *)(), Ekos::Manager *, void * *) qobjectdefs_impl.h185 0x5568dbf1 10 QtPrivate::QSlotObject, void>::impl(int, QtPrivate::QSlotObjectBase *, QObject *, void * *, bool *) qobjectdefs_impl.h414 0x556856a6 11 QMetaObject::activate(QObject *, int, int, void * *) 0x757295c8 12 QAbstractButton::clicked(bool) 0x7632e236 13 ?? 0x7632e45e 14 ?? 0x7632f8a3 15 QAbstractButton::mouseReleaseEvent(QMouseEvent *) 0x7632fa65 16 QWidget::event(QEvent *) 0x7627c04e 17 QApplicationPrivate::notify_helper(QObject *, QEvent *) 0x76239a86 18 QApplication::notify(QObject *, QEvent *) 0x76243053 19 QTest::mouseEvent qtestmouse.h 242 0x5562bd4a 20 QTest::mouseEvent qtestmouse.h 206 0x5562b852 ... -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398192] In Ekos, stopping INDI immediately after disconnecting devices hangs KStars
https://bugs.kde.org/show_bug.cgi?id=398192 --- Comment #3 from TallFurryMan --- Yes, confirmed again. I just wrote a test to validate this and can reliably reproduce the issue. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398192] In Ekos, stopping INDI immediately after disconnecting devices hangs KStars
https://bugs.kde.org/show_bug.cgi?id=398192 TallFurryMan 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 404868] Scheduler delays subsequent jobs when hitting a restriction violation
https://bugs.kde.org/show_bug.cgi?id=404868 TallFurryMan changed: What|Removed |Added Assignee|mutla...@ikarustech.com |eric.dejouha...@gmail.com --- Comment #1 from TallFurryMan --- Will take over this one. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 404868] New: Scheduler delays subsequent jobs when hitting a restriction violation
https://bugs.kde.org/show_bug.cgi?id=404868 Bug ID: 404868 Summary: Scheduler delays subsequent jobs when hitting a restriction violation Product: kstars Version: 3.0.1 Platform: Compiled Sources OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: eric.dejouha...@gmail.com Target Milestone: --- SUMMARY Scheduler properly reschedules a job that crossed its altitude limit to the next acceptable startup time and waits for its rescheduled startup time. However, this prevents further jobs in the list from executing at that moment: following the ordering rule, they are rescheduled after the restricted job. This can be worked around by automatically reordering jobs each time the list is evaluated, but that feature is often disregarded because it doesn't (yet) address obstructed horizon. STEPS TO REPRODUCE 1. Schedule two asap jobs, first of which has an altitude restriction, second of which has none (warning: there is a minimal altitude limit hard-coded whatever the value of the restriction box). 2. Execute the plan so that while running, the first job violates the altitude restriction, but not the second job. 3. Observe behavior OBSERVED RESULT First job is aborted, and rescheduled hours later when the altitude restriction can be complied with. Second job is shifted to start after first job, often on the next night and doesn't execute right now although no restriction would prevent that. If happening on the beginning of the night, this wastes the whole night. EXPECTED RESULT The behavior is compliant with the algorithm. However, it would seem more natural that the violating job is aborted, and the next is processed. SOFTWARE/OS VERSIONS Windows: MacOS: Linux/KDE Plasma: Ubuntu 18.04 - KStars 2019-02-21T21:29:33Z built from git state ~3h before that time. (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION This is not a bug, this is how the algorithm was designed. Changing the behavior to address this issue would be an improvement. First, if currently running, Scheduler could avoid updating the current schedule of subsequent jobs after such violation, unless there are no jobs left to run. Scheduler would then continue with the next job that is ready to run. What is the job that is ready to run? Restriction violations are detected while scheduling and marked with a warning icon in the list, so the end-user is aware of possible issues in that case. Violations may also appear because of a runtime delay (customizing how long accessory steps take is not implemented as of now). Well, in order to manage those two situations, when running, Scheduler should decide to abort subsequent jobs that are too late based on their startup time (this is already in the code), without changing the schedule (this is not). To relax the situation (but this is a further improvement, not needed right now) and avoid delaying the whole schedule too much, Scheduler could abort jobs which have less than 50% of their duration remaining based on their startup time. -- 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 #1 from TallFurryMan --- Version? There was a regression with a hotfix for that specific issue: https://github.com/KDE/kstars/commit/a3e3b2c7c42d64548bb2052700e8aa5998261b37 I assume the problem is still here somehow. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 381543] Mount slewing during exposure
https://bugs.kde.org/show_bug.cgi?id=381543 --- Comment #7 from TallFurryMan --- Probably not. I'll test this during January if weather agrees. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 400580] Detail window has incorrect transit time
https://bugs.kde.org/show_bug.cgi?id=400580 --- Comment #6 from TallFurryMan --- *being at the meridian at that moment on the chart that is drawn on the screen. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 400580] Detail window has incorrect transit time
https://bugs.kde.org/show_bug.cgi?id=400580 --- Comment #5 from TallFurryMan --- Sure. I was only referring to the 4 minute offset. Actually I do not compare softwares to prove which is right and which is wrong: this is bug is only about the fact that the transit time presented in the dialog doesn't result in the object being at the meridian at that moment. D16429 has an algorithm for culmination that is compatible with what is drawn by KStars, so we could use that to debug the dialog code and see at which point the execution diverges. Now, which computation is the correct one is another story. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 400580] Detail window has incorrect transit time
https://bugs.kde.org/show_bug.cgi?id=400580 --- Comment #3 from TallFurryMan --- No yet. Preliminary guess is that while calculating, the algorithm incorrectly moves to a different day, which offsets the transit time by 4 minutes. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 400580] Detail window has incorrect transit time
https://bugs.kde.org/show_bug.cgi?id=400580 --- Comment #1 from TallFurryMan --- I found this while rewriting the planning algorithm of the Scheduler. #267265 is similar, but fixes an issue deeper in the calculations. Calculating transit time with KNumbers gives proper results. The issue seems to be in the way the details pop-up consolidates the target coordinates. The call to updateCoords is dubious. Tested with Stellarium supports the issue claim, as in the same geographic and time conditions transit time is 02:20 there too. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 400580] New: Detail window has incorrect transit time
https://bugs.kde.org/show_bug.cgi?id=400580 Bug ID: 400580 Summary: Detail window has incorrect transit time Product: kstars Version: git Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: eric.dejouha...@gmail.com Target Milestone: --- Detail window has incorrect transit time STEPS TO REPRODUCE 1. Stop simulation, set geographic location to 48°13/-1°42, time and date to 2018/11/02 02:16am 2. Check south, locate Zaurak in Eridanus, open details for this object 3. Open position tab in the detail pop-up OBSERVED RESULT Transit time is indicated at 02:16am, but Zaurak Hour Angle is 4'52 minutes east of local meridian at that moment. EXPECTED RESULT Transit time indicated at 02:20am. SOFTWARE VERSIONS (available in About System) KDE Plasma Version: - KDE Frameworks Version: 5.38.0 Qt Version: 5.9.1 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398405] Session planner copies RA/DEC to Scheduler without fractional part
https://bugs.kde.org/show_bug.cgi?id=398405 TallFurryMan changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #16 from TallFurryMan --- Scheduler fixes are in https://phabricator.kde.org/D15865 -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398415] Repeated Scheduler jobs are aborted before they actually repeat
https://bugs.kde.org/show_bug.cgi?id=398415 TallFurryMan changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398757] Scheduler target name not taken into account by Capture module
https://bugs.kde.org/show_bug.cgi?id=398757 --- Comment #5 from TallFurryMan --- Found it! There is a syntax error in the dome XML, just after the declaration of "isMoving"! When qdbusxml2cpp generates the MOC, it doesn't report the error, but simply stops reading the XML file... Therefore, no definition after "isMoving" is taken into account. Wow. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398757] Scheduler target name not taken into account by Capture module
https://bugs.kde.org/show_bug.cgi?id=398757 --- Comment #4 from TallFurryMan --- Well, this is how the adaptor is created: " [ 13%] Generating domeadaptor.cpp, domeadaptor.h cd /home/tallfurryman/dev/kstars_build/kstars && /usr/lib/x86_64-linux-gnu/qt5/bin/qdbusxml2cpp -m -a domeadaptor -i ekos/auxiliary/dome.h -l Ekos::Dome /home/tallfurryman/dev/kstars/kstars/org.kde.kstars.Ekos.Dome.xml " So it's definitely taking "org.kde.kstars.Ekos.Dome.xml" as input. If I check this file, I can see ". When I look at "domeadaptor.h" in the build output, "Q_CLASS_INFO" for "D-Bus Introspection" doesn't have that string. That file is rebuilt properly because it doesn't exist beforehand after a "make clean". None of my changes to the XML source are reflected in the output. Note that I'm searching for a reason for the situation I'm in and why it doesn't work as I expect, not for a solution to this problem :) Sounds like ccache could get in the way there. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398757] Scheduler target name not taken into account by Capture module
https://bugs.kde.org/show_bug.cgi?id=398757 --- Comment #3 from TallFurryMan --- I think we should resolve this one now that clearSequence is removed. The issue was due to targetName being executed *before* clearSequence although the property setter was requested *after* clearSequence. I will remove most of the Q_NO_REPLY because there's no guarantee on the order they will execute. Our source is not prepared for this type of async calls. If you agree, of course. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 381543] Mount slewing during exposure
https://bugs.kde.org/show_bug.cgi?id=381543 TallFurryMan changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #5 from TallFurryMan --- Considering reported, to be kept. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 396182] manual filter wheel or filter drawer option
https://bugs.kde.org/show_bug.cgi?id=396182 TallFurryMan changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #9 from TallFurryMan --- Marking reported, so that the ticket doesn't go away. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 396182] manual filter wheel or filter drawer option
https://bugs.kde.org/show_bug.cgi?id=396182 --- Comment #8 from TallFurryMan --- Indeed it does depend on the free time of the handful of developers :) We need to prioritize, and currently most of the work is fixing side-effects following the D-Bus changes. We won't introduce new features until the most serious ones are patched. But we will gladly review implementation patches. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 381545] Mount not requested to do meridian flip
https://bugs.kde.org/show_bug.cgi?id=381545 TallFurryMan changed: What|Removed |Added Ever confirmed|0 |1 Status|NEEDSINFO |CONFIRMED Resolution|WAITINGFORINFO |--- --- Comment #5 from TallFurryMan --- Recently seen again. Issue seems related to the time kstars/indi-eqmod has been running. On the third subsequent night of use, indi-eqmod will point an object that is 40' west of the meridian using the west side of the pier, scope pointing east. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398744] Possible leak in file descriptors
https://bugs.kde.org/show_bug.cgi?id=398744 --- Comment #3 from TallFurryMan --- I propose to use the OSS services of Synopsys Coverity to get a static code analysis of KStars. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398757] Scheduler target name not taken into account by Capture module
https://bugs.kde.org/show_bug.cgi?id=398757 TallFurryMan changed: What|Removed |Added CC||mutla...@ikarustech.com Assignee|mutla...@ikarustech.com |eric.dejouha...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398757] Scheduler target name not taken into account by Capture module
https://bugs.kde.org/show_bug.cgi?id=398757 --- Comment #1 from TallFurryMan --- Setting target name using member property targetName and method setProperty is failing. Something is wrong with the way of calling this. Investigating. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398757] New: Scheduler target name not taken into account by Capture module
https://bugs.kde.org/show_bug.cgi?id=398757 Bug ID: 398757 Summary: Scheduler target name not taken into account by Capture module Product: kstars Version: git Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: eric.dejouha...@gmail.com Target Milestone: --- When Scheduler configures Capture, it sets the target name as part of the folder to which to store captured frames. Following the D-Bus rework, target name is not part of that path. Reason is that the method setting the target name was replaced by a property, and Scheduler code requires update to accommodate that. However, this situation could be an opportunity to rewrite that feature, which is scattered over many places in capture.cpp. The location where Capture stores frames is given by the concatenation of: - Local directory, - Directory postfix, itself a concatenation of: -- Target name, if set, -- Frame type, -- Filter name, if any is used, and if frame is light or flat. The file name under which Capture stores frames is given by the concatenation of: - Explicit prefix, if set, - Frame type, - Filter name, if required, if any is used, and if frame is light or flat, - Exposure duration, if required, as integer if exposure has no fractional part, or decimal if it has, - Timestamp, if required, - Integer index. I observe that Capture UI indicates "Target" as default value of the prefix, as a watermark proposal. But there is no code managing that hint, and prefix never equals the target name. Target name is only used when set programmatically, and only in the folder path. All this is makes code complex, and creates a discrepancy between two use cases: - When used alone, Capture does not insert any object name as target name. -- "///_.fits". - When used with the Scheduler, Capture inserts the name of the object that is the target of the Scheduler's observation job. -- "_.fits". There are few possibilities: - Make Capture fetch the target name from the last track request in KStars (but that may mean finding an object from RA/DEC? EmptySky?) - Add an explicit field (but that means a sequence can't be generic to multiple targets) This could also be a good opportunity to create a storage module, which would centralize and organize frames. We could imagine a separate tab in Ekos, with its own D-Bus interface, and showing the contents of the disk and allowing quick access to FITS files and headers (currently, checking the results of a night requires opening single files in FITSViewer). That module could then be extended with features to manipulate images, even make use of plugins, eventually jupyter notebooks or social features. But let's not get carried away. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398745] New: Crash when not closing warning pop-up on invalid sequence file
https://bugs.kde.org/show_bug.cgi?id=398745 Bug ID: 398745 Summary: Crash when not closing warning pop-up on invalid sequence file Product: kstars Version: 2.9.8 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: eric.dejouha...@gmail.com Target Milestone: --- When a scheduler job list is loaded, and contains a non-existent or invalid sequence file, a warning is displayed. If that warning is not dismissed, and another scheduler job list is loaded, dismissing the warning afterwards crashes kstars. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398744] Possible leak in file descriptors
https://bugs.kde.org/show_bug.cgi?id=398744 --- Comment #1 from TallFurryMan --- This particular situation on the shutdown script made Ekos unable to finish the shutdown process, and state SHUTDOWN_SCRIPT never completed. Another timeout safeguard to be implemented here. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398744] New: Possible leak in file descriptors
https://bugs.kde.org/show_bug.cgi?id=398744 Bug ID: 398744 Summary: Possible leak in file descriptors Product: kstars Version: 2.9.8 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: eric.dejouha...@gmail.com Target Milestone: --- After 96h+ up and whole nights imaging without interruption, kstars sometimes crashes out of file descriptors. Last occurrence happened during execution of shutdown process, which could not execute. Executing script /home/tallfurryman/Documents/EkosShutdown.sh QProcessPrivate::createPipe: Cannot create pipe 0x4c676c0: Too many open files It is obviously relatively difficult to track descriptor leaks for end-users, so perhaps an instrumented run will be necessary. Or a periodic lsof, which will provide name associations. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398504] Ekos: plate solving never gets closer to target
https://bugs.kde.org/show_bug.cgi?id=398504 --- Comment #4 from TallFurryMan --- Thanks Jasem! Cedric, getting this to work under a short amount of time would require you to extract the code tree in the pre-merge state and cherry-pick Jasem's change. So it depends whether you are willing to wait 2-3 weeks for the dust to settle on kstars-bleeding... -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398503] Ekos: Mount control doesn't see the mount move
https://bugs.kde.org/show_bug.cgi?id=398503 --- Comment #8 from TallFurryMan --- That's what I thought: Scheduler is not seeing the mount slew, and request the slew operation again: "Warning: job 'Deneb' found not slewing, restarting.". You don't get the same behavior with kstars because it is not checking whether the request is actually operated. Now we must find why the status returned by the mount interface is not the right state. This is probably in the wINDI interface, or the mount interface talking with wINDI. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398635] New: When capture suspends because of guiding deviation, and capture is stopped, UI is in invalid state
https://bugs.kde.org/show_bug.cgi?id=398635 Bug ID: 398635 Summary: When capture suspends because of guiding deviation, and capture is stopped, UI is in invalid state Product: kstars Version: git Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: eric.dejouha...@gmail.com Target Milestone: --- When capturing a target, it may happen than guiding deviation suspends the capture until the guide star is repositioned to the lock position. If the Capture module is stopped by the Scheduler at that moment (programmatically as opposed to through the UI), the Capture module enters a weird state where the start/stop icon expectedly displays as a "start", but where it is not possible to load a new sequence or request a preview. Clicking the "start" button at that moment reveals that the state of the module is actually still "capturing" although no capture is taking place or can take place anymore. After clicking, the "start" button remains in state "start", but suddenly features are working again. This seems to be a side-effect or regression of the introduction of the suspend state. Stopping the capture programmatically doesn't restore the initial configuration. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398503] Ekos: Mount control doesn't see the mount move
https://bugs.kde.org/show_bug.cgi?id=398503 --- Comment #3 from TallFurryMan --- Do you have logs for this? -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398415] Repeated Scheduler jobs are aborted before they actually repeat
https://bugs.kde.org/show_bug.cgi?id=398415 TallFurryMan changed: What|Removed |Added Status|UNCONFIRMED |CONFIRMED Ever confirmed|0 |1 --- Comment #1 from TallFurryMan --- Should be fixed by https://phabricator.kde.org/D15388 -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398503] Ekos: Mount control doesn't see the mount move
https://bugs.kde.org/show_bug.cgi?id=398503 TallFurryMan changed: What|Removed |Added CC||eric.dejouha...@gmail.com --- Comment #1 from TallFurryMan --- This might be a good candidate for a bug investigation in wIndi too. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398504] Ekos: plate solving never gets closer to target
https://bugs.kde.org/show_bug.cgi?id=398504 TallFurryMan changed: What|Removed |Added CC||eric.dejouha...@gmail.com --- Comment #1 from TallFurryMan --- Complementary information from the forum thread indicates that you (not sure I can match usernames, sorry if it's not you!) used the Windows port of astrometry.net "ansvr", and that this plate-solver provides an additional field named "epoch". In any case, is this description correct? In your situation, "epoch" has value "JNow", which indeed is causing an issue in the solver analyzer in ekos/align/onlineastrometry.cpp, which doesn't check that json field and bluntly considers all result coordinates to be J2000. We could either stick to the original astrometry.net API, which doesn't include that field, or honor that field when it is present. First solution is the simplest for us :) Second solution can be done too relatievly easy. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398405] Session planner copies RA/DEC to Scheduler without fractional part
https://bugs.kde.org/show_bug.cgi?id=398405 --- Comment #15 from TallFurryMan --- One first step towards fixing this is in https://phabricator.kde.org/D15492 -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 397562] Sequence job CCD specification is not served
https://bugs.kde.org/show_bug.cgi?id=397562 TallFurryMan changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |CONFIRMED --- Comment #2 from TallFurryMan --- Should be fixed by https://phabricator.kde.org/D15492 -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398405] Session planner copies RA/DEC to Scheduler without fractional part
https://bugs.kde.org/show_bug.cgi?id=398405 --- Comment #14 from TallFurryMan --- Preliminary work in the Capture module at https://github.com/TallFurryMan/kstars, branch improve__support_decimal_locales. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398405] Session planner copies RA/DEC to Scheduler without fractional part
https://bugs.kde.org/show_bug.cgi?id=398405 --- Comment #12 from TallFurryMan --- I'm planning to: - replace atof calls used to read XML numbers, which use the system locale, with QLocale::C string-to-type functions. - make sure QString calls used to write XML numbers use the QLocale::C serialization. Side not-so-related question: XML serialization is using the lilXML library, any plan to use QXMLStreamReader and QXMLStreamWriter at some point? This is compatible back to Qt4.3 and could possibly simplify some serialization code. In any case I think saving/loading configurations should be moved out of their related modules first. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398405] Session planner copies RA/DEC to Scheduler without fractional part
https://bugs.kde.org/show_bug.cgi?id=398405 --- Comment #11 from TallFurryMan --- XML files are saved with the system locale, and loaded with no locale. This issue is in Scheduler and Capture modules. Besides, all control texts need rework to take locale into account properly. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398405] Session planner copies RA/DEC to Scheduler without fractional part
https://bugs.kde.org/show_bug.cgi?id=398405 TallFurryMan changed: What|Removed |Added CC||mutla...@ikarustech.com -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398405] Session planner copies RA/DEC to Scheduler without fractional part
https://bugs.kde.org/show_bug.cgi?id=398405 TallFurryMan 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 398405] Session planner copies RA/DEC to Scheduler without fractional part
https://bugs.kde.org/show_bug.cgi?id=398405 --- Comment #10 from TallFurryMan --- I think the issue has been there for a long time actually. Besides, it might evantually relate to the issue forum user alacant had. Tested with target "NGC 281", created a scheduler job, saved, loaded XML file, coordinates are wrong and, while easy to overlook, the nature of the problem is relatively obvious. NGC 281 has a fractional part for the seconds value. The resulting coordinates are not too far, but still completely wrong. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398405] Session planner copies RA/DEC to Scheduler without fractional part
https://bugs.kde.org/show_bug.cgi?id=398405
--- Comment #9 from TallFurryMan ---
On my system, QString("%L1").arg(float_var) with float_var does produce "1,2",
while QString("%1").arg(float_var) does produces "1.2".
I'm checking where all this should be used. I'll try to use the english locale
when reading and writing XML files so we keep portability. We'll have
interesting issues, as for instance with the float representing exposure
duration that is used in capture file names.
--
You are receiving this mail because:
You are watching all bug changes.
[kstars] [Bug 398405] Session planner copies RA/DEC to Scheduler without fractional part
https://bugs.kde.org/show_bug.cgi?id=398405 --- Comment #7 from TallFurryMan --- Read some Qt docs, and found the problem: all of our arg() and number() calls basically ignore locale. To properly support that, we can use "%L1" instead of "%1" for a float number for instance, or use toString(), which uses the current locale but is not very flexible. That also raises the problem of portable XML files, in which we should better choose the right QLocale before reading and writing. Plenty of changes everywhere, apparently. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398405] Session planner copies RA/DEC to Scheduler without fractional part
https://bugs.kde.org/show_bug.cgi?id=398405 --- Comment #5 from TallFurryMan --- Coordinates end up "HH MM SS.SS" after conversion instead of "HHh MM' SS,SS"" in the RA/DEC boxes, and the "." character is not recognized properly, leading to offset'd positioning afterwards. With my locale, "." should be "," for the conversion to be successful. Current code tree thus has loading of scheduler files broken. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398405] Session planner copies RA/DEC to Scheduler without fractional part
https://bugs.kde.org/show_bug.cgi?id=398405 --- Comment #4 from TallFurryMan --- I reproduced the issue is more serious than I thought. The bug appears (also?) in the .esl load procedure! Could this be a regression introduced by the copy of coordinates? This was working properly during August. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398405] Session planner copies RA/DEC to Scheduler without fractional part
https://bugs.kde.org/show_bug.cgi?id=398405 --- Comment #3 from TallFurryMan --- Issue might be related to QString::toDouble in dms::setFromString. Documentation in Qt11 doesn't mention any locale issue, so perhaps this is a version compatibility problem? -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398405] Session planner copies RA/DEC to Scheduler without fractional part
https://bugs.kde.org/show_bug.cgi?id=398405 --- Comment #2 from TallFurryMan --- This seems proper indeed. Issue must be elsewhere, let me provide a scenario. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398437] Job approaching dawn is always rescheduled, preventing observatory shutdown
https://bugs.kde.org/show_bug.cgi?id=398437 TallFurryMan 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 398437] New: Job approaching dawn is always rescheduled, preventing observatory shutdown
https://bugs.kde.org/show_bug.cgi?id=398437 Bug ID: 398437 Summary: Job approaching dawn is always rescheduled, preventing observatory shutdown Product: kstars Version: git Platform: Other OS: Linux Status: UNCONFIRMED Severity: major Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: eric.dejouha...@gmail.com Target Milestone: --- Scheduler jobs with twilight restriction are properly aborted when dawn approaches, but are re-evaluated and re-scheduled with no regard for said dawn, preventing the observatory from shutting down properly. This is a regression introduced by "1e299fdf5 - Fix parking engine, and make observatory startup job-centric". -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398415] New: Repeated Scheduler jobs are aborted before they actually repeat
https://bugs.kde.org/show_bug.cgi?id=398415 Bug ID: 398415 Summary: Repeated Scheduler jobs are aborted before they actually repeat Product: kstars Version: git Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: eric.dejouha...@gmail.com Target Milestone: --- When a repeated Scheduler job finishes a batch, it shifts to aborted state before effectively repeating. Steps to reproduce: - Create a Scheduler job that has repeats, and starts now, - Run the Scheduler, - Observe as job finishes a batch, aborts indicating its startup time is in the past, then restart for the next batch. This situation is triggered by the startup time which is calculated at the first batch, and is re-considered when checking for the new batch. START_ASAP jobs get configured as START_AT when they are evaluated. When a batch finishes, jobs go through state COMPLETE so that they re-evaluate before being repeated, and the re-evaluation doesn't consider the original startup configuration. The same situation occurs with real START_AT jobs, but those by design need to really start at the time they are planned, not at another time. Thus in order to avoid regressions, this issue should probably not be fixed by considering START_AT/START_ASAP original startup configurations, but by checking if a repeat is remaining when finding a job that was configured to start too far in the past. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398405] New: Session planner copies RA/DEC to Scheduler without fractional part
https://bugs.kde.org/show_bug.cgi?id=398405 Bug ID: 398405 Summary: Session planner copies RA/DEC to Scheduler without fractional part Product: kstars Version: git Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: eric.dejouha...@gmail.com Target Milestone: --- System is configured in French nimbers, dates and currency amounts. This means the fractional separator is ',' and not '.'. When using the Session Planner to copy objects to the Scheduler plan, RA/DEC coordinates are copied without the fractional part, and thus are wrong. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398388] No failure in Scheduler when Focus module fails to find a star
https://bugs.kde.org/show_bug.cgi?id=398388 --- Comment #4 from TallFurryMan --- For this particular issue, there *is* a timeout in the Focus module, set to 45 seconds. But it is used to allow the user to pick a star, as the message suggests. I'll add a branch considering inAutoFocus, and capturing again instead of waiting for the user. Let's consider no stars mean clouds when auto-focusing. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398388] No failure in Scheduler when Focus module fails to find a star
https://bugs.kde.org/show_bug.cgi?id=398388 --- Comment #3 from TallFurryMan --- Two things I need to fix before introducing additional timers in the Scheduler: minimal workaround for the capture storage cache count (fits analysis later on) and removal of the lock-up related to the manual scheduled auto-focus. For timers, I need to go in multiple steps, as it is related to imaging duration estimation. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398388] No failure in Scheduler when Focus module fails to find a star
https://bugs.kde.org/show_bug.cgi?id=398388 --- Comment #1 from TallFurryMan --- Jasem, this is one of the issues that impact the d-bus rework you are currently doing. I'm worried that fixing those issues will create conflicts in your branch, but I'm also worried that such issues would better be fixed *before* your rework is complete, in order to avoid regressions. Opinion? -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398388] New: No failure in Scheduler when Focus module fails to find a star
https://bugs.kde.org/show_bug.cgi?id=398388 Bug ID: 398388 Summary: No failure in Scheduler when Focus module fails to find a star Product: kstars Version: 2.9.8 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: eric.dejouha...@gmail.com Target Milestone: --- When Focus module fails to find a star, when clouds are passing by for instance, it waits for input with "Failed to automatically select a star. Please select a star manually.", and emits a signal notifying it is waiting. Scheduler is not listening to that event, and hangs waiting indefinitely. Scheduler should handle that situation, or Focus should make this situation a failure situation. Focus could for instance consider that no star found on frame will doom the focus procedure. It is to be noted that when the optical train is too defocused, Focus is unable to recover and find any star. But this is another talk. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398301] Once "Wall" mode is used, all frame types use the "Wall" coordinates
https://bugs.kde.org/show_bug.cgi?id=398301 --- Comment #1 from TallFurryMan --- Additional (really funny) note: the calibration options are part of the sequence file, so any sequence file saved after "Wall" mode is configured will make the Capture module slew to the wall source position. This can quickly become very confusing for the end-user! Besides, when "Wall" mode is used, Scheduler module is not notified with the end of the capture. This cause the scheduler job to remain hung at the wall source position forever. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398302] New: Mount cannot unpark after executing parking of shutdown procedure manually
https://bugs.kde.org/show_bug.cgi?id=398302 Bug ID: 398302 Summary: Mount cannot unpark after executing parking of shutdown procedure manually Product: kstars Version: 2.9.8 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: eric.dejouha...@gmail.com Target Milestone: --- After slewing to any location, execution of a shutdown procedure having the mount parking step enabled prevents the mount from being unparked automatically when the Scheduler is started. Steps to reproduce (because the sentence is long): - Create a Scheduler job at any location - Check "Park mount" in "Observatory Shutdown Procedure" - Execute the Scheduler, and abort it after slewing to target - Execute the shutdown procedure manually - Re-execute the Scheduler with the same (aborted) set of jobs This issue is due to the reset of the parking engine state to PARKWAIT_IDLE when stopping the Scheduler. The parking engine is then unable to unpark the mount properly. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398301] Once "Wall" mode is used, all frame types use the "Wall" coordinates
https://bugs.kde.org/show_bug.cgi?id=398301 TallFurryMan changed: What|Removed |Added Summary|Once "Wall" mode is used, |Once "Wall" mode is used, |all frames type use the |all frame types use the |"Wall" coordinates |"Wall" coordinates -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398301] New: Once "Wall" mode is used, all frames type use the "Wall" coordinates
https://bugs.kde.org/show_bug.cgi?id=398301 Bug ID: 398301 Summary: Once "Wall" mode is used, all frames type use the "Wall" coordinates Product: kstars Version: 2.9.8 Platform: Other OS: Linux Status: UNCONFIRMED Severity: major Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: eric.dejouha...@gmail.com Target Milestone: --- When capturing flats using the "Wall" mode, any subsequent capture, flat or not, will first slew to the "Wall" coordinates before capturing. The problem is immediately obvious with the message "Mount slewing to wall position", and because of the abnormal additional slew, but because the "Light" frame type disables access to the "Calibration" pop-up window, the situation is confusing. It is not possible to keep the "Wall" mode active and successfully capture a "Light" frame. If the "Wall" mode is disabled, for instance by selecting "Manual" as a flat source, coordinates of the wall source are lost after validating changes in the calibration pop-up. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 396182] manual filter wheel or filter drawer option
https://bugs.kde.org/show_bug.cgi?id=396182 --- Comment #4 from TallFurryMan --- No, no yet. That feature is properly specified, but we are busy fixing issues in the Scheduler. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398198] Mount tracking while taking flats in "Wall" mode
https://bugs.kde.org/show_bug.cgi?id=398198 --- Comment #2 from TallFurryMan --- Agreed, this ticket only applies to the "Wall" mode. Thinking about it, I even wonder if tracking would actually improve the flat quality. But, well capturing something static is better done without moving I suppose. About dawn/dusk frames, if the ADU calibration curve is added to a simple linear function with a customizable slope to cater for the decreasing or increasing luminosity, and tracking is stopped too, we get our dawn/dusk flat capture feature. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398198] New: Mount tracking while taking flats in "Wall" mode
https://bugs.kde.org/show_bug.cgi?id=398198 Bug ID: 398198 Summary: Mount tracking while taking flats in "Wall" mode Product: kstars Version: 2.9.8 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: eric.dejouha...@gmail.com Target Milestone: --- When capturing flats in "Wall" mode with AltAz coordinates, mount is left to track after slewing. Mount must not track while taking flats. In the case of a real flat panel hanging on a wall, the mount may not have the time to drift away by the time flat frames are taken. In this (intended) use case, the problem is there but the symptom doesn't appear. However while option "Dawn/Dusk" is not currently implemented in Ekos, it is nonetheless possible to take dawn/dusk flats in "Wall" mode and use a particular area of the sky as light source. Because the mount is tracking while in this mode, stars that may appear during capture will remain at the same place on the frame, defeating the purpose of the flat. Side note about the current implementation of exposure calibration in the "Wall" mode: at a certain point in the dawn/dusk transition interval, the ADU calculation is not able to follow the speed at which the sky luminosity changes. Exposure adjustment is indeed calibrated for a static light source. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398194] Warning on Scheduler job looping indefinitely visible with only one job in the list
https://bugs.kde.org/show_bug.cgi?id=398194 --- Comment #1 from TallFurryMan --- Own plans include a feature that will update the priority of repeating Scheduler jobs, so that even in LOOP_INFINITE or LOOP_UNTIL state, other jobs may schedule in-between when their target can be observed. This ticket may be easily corrected while working on that feature. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398194] New: Warning on Scheduler job looping indefinitely visible with only one job in the list
https://bugs.kde.org/show_bug.cgi?id=398194 Bug ID: 398194 Summary: Warning on Scheduler job looping indefinitely visible with only one job in the list Product: kstars Version: 2.9.8 Platform: Other OS: Linux Status: UNCONFIRMED Severity: minor Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: eric.dejouha...@gmail.com Target Milestone: --- When setting a Scheduler job to repeat indefinitely, a warning message appears in the console, stating that one of the job of the Scheduler list will be repeating indefinitely. This is proper, but also appears when there is only one job in the list. That message should appear only if multiple jobs are in the Scheduler list, as a warning that one of them may leave no imaging time for any other. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 398193] New: Repeating Scheduler job marked aborted by past startup before actually repeating
https://bugs.kde.org/show_bug.cgi?id=398193 Bug ID: 398193 Summary: Repeating Scheduler job marked aborted by past startup before actually repeating Product: kstars Version: 2.9.8 Platform: Other OS: Linux Status: UNCONFIRMED Severity: minor Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: eric.dejouha...@gmail.com Target Milestone: --- When a Scheduler job configured for repeat actually repeats, a warning message appears in the console log of the Scheduler, stating that said job was supposed to start in the past, and marking said job aborted. The job is then repeated without issue. The timestamp object of complaint by the Scheduler is the actual time at which the previous repeat started. This is probably an innocuous side-effect of https://phabricator.kde.org/D15073. Message must be fixed, though. -- You are receiving this mail because: You are watching all bug changes.
