Help to contribute fixing a possible bug

Wed Apr 1 16:21:18 BST 2026

Thank you for the update Javier. Do you have the complete log that you can
zip and attach?

--
Best Regards,
Jasem Mutlaq

On Wed, Apr 1, 2026 at 4:21 PM Javier Almansa <javieralso at gmail.com> wrote:

> Hi again Jasem,
>
> quick follow up on my previous email. I just noticed that actually the
> second job of my list (Cepheus), seems to have been scheduler an hour in
> the future again (despite the logs). I just attached a screenshot for your
> reference.
>
> The good news is that this would confirm that issue 518015 is actually
> fixed.
>
> [image: image.png]
>
> Cheers,
> Javier
>
> On Wed, 1 Apr 2026 at 14:13, Javier Almansa <javieralso at gmail.com> wrote:
>
>> Hi Jasem,
>>
>> I tried to reproduce my original issue on my build, which seems to be
>> 3.8.2 Stable. I added my findings, including the scheduler logs to the bug
>> I reported (518015). Here is the C&P of the summary:
>>
>> I tried to reproduce this issue with a self-built of 3.8.2 Stable.
>>
>> * Scheduled a job with two targets: Polaris & Cepheus
>> * Issued a weather alert during Polaris job
>>     - Polaris gets interrupted. Soft-shutdown initiated. Pre-shutdown queue executed.
>> * Weather alert lifted before grace period expired:
>>     - Post-startup queue executed as expected. Polaris acquisition resumed as well as expected.
>> * Polaris acquisition finalizes
>>     - Cepheus acquisition is scheduled, however this happens two seconds on the past as per the logs, therefore the jobs keeps waiting in scheduled state. Previous behaviour on v3.8.1: Job gets aborted.
>>     - Pre-shutdown task is executed leaving the observatory in a safe state. Previous behaviour  on v3.8.2: Pre-shutdown task is never executed, leaving the observatory in an unsafe status.
>>
>>
>> So based on that, I would say that the main problem, which to me was the
>> observatory left on an unsafe status after a weather alert because the pre
>> & post-shutdown tasks were never executed, is fixed. There is still the
>> issue of the second job on the list not being executed (looks like it is
>> scheduled in the past), but I think this is more of an inconvenience.
>>
>> Now there is the other issue I talked about on my previous email, which I
>> don't know whether it is a bug or not, but I though it was worth
>> mentioning. Something that I forgot to mention in my email before is that I
>> built with QT6 in case that makes any difference. Here are the startup logs
>> in case they are useful to you (they seem to contain logs related to
>> timezones so I thought they might come handy if there is actually a
>> problem):
>>
>> :~/devel/projects/astro/kstars/kstars/build$ kstars
>> kf.i18n: KCatalog being used without a Q*Application instance. Some
>> translations won't work
>> Call to writableLocation without an application-based location.
>> org.kde.kstars: "Welcome to KStars" 3.8.2 Stable
>> org.kde.kstars: Build: 2026-04-01T08:19:07Z
>> org.kde.kstars: OS: "opensuse-tumbleweed"
>> org.kde.kstars: API: "x86_64-little_endian-lp64"
>> org.kde.kstars: Arch: "x86_64"
>> org.kde.kstars: Kernel Type: "linux"
>> org.kde.kstars: Kernel Version: "6.8.0-106-generic"
>> org.kde.kstars: Qt Version: 6.10.2
>> org.kde.kstars: Processing  "unnamedstars.dat" , HTMesh Level 3
>> org.kde.kstars:   Sky Mesh Size:  512
>> org.kde.kstars: Loaded DSO catalog file:  "unnamedstars.dat"
>> org.kde.kstars: "Star HD20,794 not found."
>> org.kde.kstars: "Star HD98,230 not found."
>> org.kde.kstars: Loaded DSO catalogs.
>> org.kde.kstars: Loading comets
>> QLayout: Attempting to add QLayout "" to MinimizeWidget
>> "altitudeGraphMinimizeWidget", which already has a layout
>> QLayout: Attempting to add QLayout "" to MinimizeWidget
>> "astrobinSearchMinimizeWidget", which already has a layout
>> QLayout: Attempting to add QLayout "" to MinimizeWidget
>> "filtersMinimizeWidget", which already has a layout
>> QLayout: Attempting to add QLayout "" to MinimizeWidget
>> "imageFrameMinimizeWidget", which already has a layout
>> QDateTime::setTimeSpec: Pass a QTimeZone instead of Qt::TimeZone.
>> org.kde.kstars: Current icon theme is "Adwaita" (fallback "gnome" )
>> org.kde.kstars: Warning: icon theme "breeze-dark" not found, keeping
>> original "Adwaita" .
>> qt.core.qobject.connect: QObject::connect(Ekos::OpsWeatherSettings,
>> Unknown): invalid nullptr parameter
>> qt.core.qobject.connect: QObject::connect(QAction, Ekos::Scheduler):
>> invalid nullptr parameter
>> QDateTime::setTimeSpec: Pass a QTimeZone instead of Qt::TimeZone.
>> QDateTime::setTimeSpec: Pass a QTimeZone instead of Qt::TimeZone.
>> QDateTime::setTimeSpec: Pass a QTimeZone instead of Qt::TimeZone.
>> QDateTime::setTimeSpec: Pass a QTimeZone instead of Qt::TimeZone.
>> org.kde.kstars.ekos.scheduler: "Turning off astronomical twilight check
>> may cause the observatory to run during daylight. This can cause
>> irreversible damage to your equipment!"
>> kf.configwidgets: A widget named "kcfg_SaveFocusImages" was found but
>> there is no setting named "SaveFocusImages"
>> QDateTime::setTimeSpec: Pass a QTimeZone instead of Qt::TimeZone.
>> QDateTime::setTimeSpec: Pass a QTimeZone instead of Qt::TimeZone.
>> org.kde.kstars: Current icon theme is "Adwaita" (fallback "gnome" )
>>
>> Thanks,
>> Javier
>>
>> On Wed, 1 Apr 2026 at 12:37, Javier Almansa <javieralso at gmail.com> wrote:
>>
>>> Hi Jasem,
>>>
>>> Thanks for the quick reply.
>>>
>>> Actually, first thing that I tried after building kstars from master
>>> branch (pulled last night BST) was to reproduce the issue, however I ran
>>> into something else which I don't know if it is another bug or a
>>> misconfiguration issue on my side (but definitely didn't see it on the
>>> previous stable version shipped with stellarmate):
>>>
>>> * I setup a profile with the simulators, create a capture sequence and
>>> then a job with a couple of targets to try to reproduce the original issue.
>>> For the job I choose targets that are close to polaris so to ensure they
>>> are always over the horizon, then I disable all constrains (twilight,
>>> altitude, etc).  Set the job to be scheduled ASAP, greedy scheduler, etc...)
>>> * when I start the job, the scheduler schedules the jobs exactly one
>>> hour after I hit start.
>>> * I checked the geographical settings, time zones, time configuration,
>>> etc and I couldn't find anything.
>>>
>>> As an example, I got the following logs:
>>>
>>> 2026-03-31T22:41:49 Sleeping until observation job CEPHEUS is ready at
>>> Tue Mar 31 23:41:48 2026
>>> 2026-03-31T22:41:48 Scheduler plan for the next 48 hours starting Tue
>>> Mar 31 22:41:48 2026 (0.009)s:
>>> 2026-03-31T22:41:48 CEPHEUS 03/31 22:41 --> 22:44 job completion
>>> 2026-03-31T22:41:48 M 45 03/31 22:45 --> 22:48 job completion
>>> 2026-03-31T22:41:47 Scheduler started.
>>> 2026-03-31T22:41:47 Scheduler is awake.
>>>
>>> There you can see that CEPHEUS is scheduled to start at 22:41 but then
>>> the scheduler is sleeping until 23:41 (exactly one hour after).
>>>
>>> I wanted to do a bit more of research once I was more rested (yesterday
>>> was a long day :)) to see if this was a misconfiguration on my side or a
>>> real bug before reporting, and then, try to reproduce my original issue
>>> again.
>>>
>>> But as per your email, I'll try to reproduce the original issue right
>>> now and let you know ASAP.
>>>
>>> Cheers,
>>> Javier
>>>
>>> On Wed, 1 Apr 2026 at 12:22, Jasem Mutlaq <mutlaqja at ikarustech.com>
>>> wrote:
>>>
>>>> Hello Javier,
>>>>
>>>> KStars 3.8.2 (due for release today or tomorrow) includes many fixes
>>>> for the task queue. If the issue is reproducible, please try the latest
>>>> code to see if you can reproduce it. I'll hold off the KStars release until
>>>> tomorrow, pending your response regarding this.
>>>>
>>>> --
>>>> Best Regards,
>>>> Jasem Mutlaq
>>>>
>>>>
>>>>
>>>> On Wed, Apr 1, 2026 at 2:18 PM Javier Almansa <javieralso at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Couple of days ago I raised what I think it is a bug on the scheduler (
>>>>> https://bugs.kde.org/show_bug.cgi?id=518015). This allegedly bug
>>>>> leaves my observatory on an unsafe state so I would like it to be fixed as
>>>>> soon as possible.
>>>>>
>>>>> Since I understand that developers/contributors might be busy and this
>>>>> might take time to get fixed, I have decided to give it a try and fix it
>>>>> myself. I have downloaded the sources and already built kstars from master
>>>>> branch to start with :)
>>>>>
>>>>> However, before I dive into the code, could someone kindly confirm
>>>>> whether the bug I reported is an actual bug and not just a configuration
>>>>> issue or similar? Once the bug is confirmed, I will start taking a look at
>>>>> it.
>>>>>
>>>>> Thanks,
>>>>> Javier
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20260401/2c4bbc0e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 269729 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20260401/2c4bbc0e/attachment-0001.png>