Help to contribute fixing a possible bug

Wed Apr 1 14:21:43 BST 2026

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/3f76f9a3/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/3f76f9a3/attachment-0001.png>