MantisBT - Issues

0002948: Offer to contribute a native macOS (Apple Silicon) port of Virtual Moon Atlas

Wed, 14 Oct 2026 14:26:41 +0200

Hello Patrick,

Thanks for Virtual Moon Atlas. I have completed a native macOS port of VMA (and all the helper apps) based on current git master (commit ba50db0, version 9.1a). It builds with Lazarus/FPC and runs 64-bit ARM native on an Apple M1 (macOS 26.6 build 25G72), no Rosetta, no emulation. The main new piece is a Cocoa OpenGL context backend for the GLScene view; the rest is small platform-guarded build fixes and a script that produces a self-contained .app / .dmg. Linux and Windows builds are unaffected.

Testing so far is limited to my own hardware, but it is stable in normal use.

Would you be interested in bringing this upstream? If so, I am happy to prepare it however suits you, one branch or a series of smaller patches, and to help maintain the macOS side.

Thanks,
William Henderson

0002956: Use-after-free when closing/disconnecting the INDI watchdog or safety monitor

Thu, 08 Oct 2026 13:07:13 +0200

`T_indiwatchdog.Destroy` (src/cu_indiwatchdog.pas, ~line 129-141) and
`T_indisafety.Destroy` (src/cu_indisafety.pas, ~line 120-130) only set
`indiclient.onServerDisconnected := nil` and free their own timers. They
never call `indiclient.Terminate` and never wait for the INDI client thread
to stop.

`indiclient` is a `TIndiBaseClient` (`TThread` with `FreeOnTerminate := True`,
see component/indiclient/indibaseclient.pas:229) whose other callbacks
(`onNewDevice`, `onNewProperty`, `onNewSwitch`, `onNewMessage`, etc.) are
still bound to the watchdog/safety instance being destroyed.

`DestroyDevices` in src/pu_main.pas (~line 2497-2509) calls
`watchdog.Free; safety.Free;` with no prior `Disconnect` call. If the
device is still connected when the app closes (or whenever the monitor is
destroyed while connected), the INDI client thread keeps running in the
background and will invoke a method on the now-freed watchdog/safety object
the next time it receives a message from the INDI server — a classic
use-after-free.

0002961: ASCOM rotator: V3 members used on IRotatorV2 drivers

Thu, 08 Oct 2026 00:37:17 +0200

The PWI4 rotator driver reports InterfaceVersion = 2 and exposes only the IRotatorV2 members, which I verified quickly from PowerShell Get-Member:

Action, CommandBlind, CommandBool, CommandString, Dispose, Equals, GetHashCode, GetType, Halt, Move, MoveAbsolute, SetupDialog, ToString, CanReverse, Connected, Description, DriverInfo, DriverVersion, InterfaceVersion, IsMoving, Name, Position, Reverse, StepSize, SupportedActions, TargetPosition

But, CCDciel 0.9.97-4213 reads MechanicalPosition (IRotatorV3 and later) while the rotator is connected, which produces this error about once a second:

2026-10-05T21:57:59.775 0: ASCOM.PWI4.Rotator: Get position error: Method 'MechanicalPosition' is not supported by automation object

This wasn't the case with 0.9.92-3775, or if it was, it was much more silent about the issue. This isn't PWI4-specific; I think any IRotatorV2 driver should hit it in the same way.

Also: the rotator input text box is difficult to use in practice since it's also updating with the current position. One has to be very quick to change the value, otherwise the new value gets clobbered by the next update! Changing the current position readout to be a text label instead of re-using the text input box would help a lot in practice.

0002952: Code review

Wed, 07 Oct 2026 14:21:12 +0200

I had some spare tokens for Claude.ai and used them to analyse the CCDCiel code. Attached the result.

0002955: Program stops taking imaging after Autoguider: Settling

Wed, 07 Oct 2026 13:16:09 +0200

00:39:14 Saved file C:\astro_files\NGC7822\NGC7822_H-alpha_200s_-15C_20261002_223551.fits.fz
00:39:16 Autofocus due in 0.2 C
00:39:16 Starting Light exposure 28/999 for 200 seconds
00:42:38 Saved file C:\astro_files\NGC7822\NGC7822_H-alpha_200s_-15C_20261002_223916.fits.fz
00:42:40 Dithering…
00:42:40 Autoguider: Settling

0002896: SVBony powerbox switch

Wed, 07 Oct 2026 13:15:44 +0200

I couldn't connect to the SVbony SV241Pro powerbox (https://www.svbony.com/products/sv241-remote-astro-power-controller) using ASCOM. It shows an error: "ASCOM.SVBONY.Switch: Connection error: Method 'Connect' is not supported by automation object"

The ASCOM driver is installed, and I can connect it from Astro Photography Tool (APT). Also, if I use INDI (running on Raspberry Pi), I can connect to it from CCDCiel running on Windows.
But I couldn't change values in the PWM fields in the switch window. They always immediately return to default values. The only option is to set it directly in the INDI server settings.

0002950: Impossible de connecter Cache calibrateur Wanderer

Wed, 07 Oct 2026 13:14:20 +0200

CCDCiel refuse de connecter le Cache Calibrateur WandererCover V4-EC (240mm) de mon setup.

Erreur console:
22:50:05 Connexion de Cache calibrateur ASCOM "ASCOM.WandererCover1.CoverCalibrator" …
22:50:05 ASCOM.WandererCover1.CoverCalibrator: Connection error: Method 'Connect' is not supported by automation object

Les autres équipements du setup se connectent sans problème (ZWO533MM Pro, ZWO174MM mini, ZWO AM7, WandererBox Pro V3, focuser ESATTO 2'', roue à filtre ZWO) à CCD Ciel.

Le setup est contrôlé par un mini-PC GEEKOM sous Win11.
CCDciel
Version beta 0.9.97-4213-be54a24a 2026/07/15 10:43:0

Pour information cet accessoires peut être connecté sans problème sur NINA.

0002960: Options dialog: PHD2/CdC/SMTP port fields accept any text, no numeric validation

Tue, 06 Oct 2026 23:18:33 +0200

In src/pu_options.pas, `PHDport`, `CdCport`, and `smtp_port` are plain
`TEdit` controls (not `TSpinEdit`), and their `.Text` is stored directly
into config (e.g. `config.SetValue('/Autoguider/PHDport', f_option.PHDport.Text)`)
with no `StrToIntDef` or range check anywhere along the way.

A user can type a non-numeric or out-of-range value into any of these
fields with no immediate feedback; the only symptom is an unexplained
connection failure to PHD2 / Cartes du Ciel / the SMTP server much later,
with nothing in the Options dialog pointing back at the invalid field.

0002959: Goto dialog: "Resolve" mode accepts OK without validating coordinates

Tue, 06 Oct 2026 23:18:05 +0200

`Tf_goto.ButtonOKClick` (src/pu_goto.pas, ~line 281-294) only validates
input when `PanelAltAz.Visible` (normal Goto mode). When the same form is
reused to resolve missing FITS coordinates (`PanelPxSz.Visible`, entered
via `CheckImageInfo`), clicking OK just sets `ModalResult := mrOK`
unconditionally, with no validation of the Ra/De/PxSz fields.

Back in `CheckImageInfo` (~line 296-347), `StrToAR`/`StrToDE` safely fall
back to `NullCoord` on unparseable input (they do not raise), and
`StrToFloatDef(PxSz.Text, 0)` falls back to 0 — so leaving the fields
blank does not crash, but it does make `CheckImageInfo` return
`result := true` (success) even though no RA/DEC/SECPIX keywords were
actually written to the FITS header. The caller is told the missing
coordinates were resolved when nothing useful happened.

0002958: Dark Library dialog: controls stay enabled during a run, and Cancel has no confirmation

Tue, 06 Oct 2026 23:17:32 +0200

In src/pu_dark.pas, `btnStartClick` (~line 141-173) sets `Frunning := true`
but never disables `btnStart`, `MaxExposure`, `Stackcount`, or
`cbMultiExp`. This lets the user re-click Start while a capture is already
running (re-entering the method mid-run), or change the exposure/stack
values while the background exposure loop is still using the old ones,
producing an inconsistent stack.

Separately, `btnCancelClick` (~line 293-302) immediately calls
`Fcamera.AbortExposure` and discards the in-progress stack with no
"Abort current dark capture?" confirmation — unlike `fu_sequence.pas`,
which does confirm before aborting a running sequence.

`FormCloseQuery` also silently sets `CanClose := false` while running,
with no message explaining why the window's close button did nothing.

0002957: Race condition on the PHD2 TCP socket in the internal autoguider client

Tue, 06 Oct 2026 23:16:36 +0200

`T_autoguider_phd` (src/cu_autoguider_phd.pas) is itself a `TThread`.
`Execute` (~line 115-157) runs the receive loop and, in its `finally`
block, calls `tcpclient.Disconnect` and `tcpclient.Free` once the thread
terminates.

`Send` (~line 159-172), which is called from the main thread (via
Guide/Pause/Dither/GetLockPosition), only guards access with a
non-atomic check: `(not terminated) and (tcpclient <> nil)`, then calls
`tcpclient.Sock.SendString(...)`. There is no critical section protecting
`tcpclient` between the two methods.

If `Terminate` fires concurrently — e.g. the thread notices a connection
error, or the user disconnects while `WaitBusy`/`WaitGuiding` is pumping
`Application.ProcessMessages` and re-enters — `Execute`'s `finally` block
can free `tcpclient` in the small window right after `Send`'s check
passed, resulting in an access to freed memory.

0002947: Remplacer les espace par _ n'est pas pris en compte

Sat, 03 Oct 2026 10:32:12 +0200

Lorsque je modifie le choix de séparateur pour le nom des objets en passant de - à _ le séparateur ne change pas. Si je passe de - à . cela fonctionne.

0002954: Send image showing saturated stars from CCDciel to Cartes du Ciel to help decide best exposure time

Wed, 30 Sep 2026 12:25:58 +0200

In CCDciel there is an option to send a plate solved image to CDC (right click image, resolve and send to planetarium). If I have the - show highlight and shadow - option enabled for images, it would be helpful to send that image showing the magenta colored saturated objects to CDC, and not the raw image. I could then get an idea of the exposure time that will create saturated stars.

For example, I typically use 180sec or 300sec exposures for my asteroid photometry and in each image some stars are saturated. If I had the image with the magenta color saturated stars sent to CDC it would be easier to get an idea of the magnitude of the faintest saturated star for that exposure time by overlaying the Gaia stars and clicking on the saturated ones, -- a 300sec exposure will saturate stars brighter than about 12.9 mag, or something like that. If my target asteroid is 15.5 mag then i should have enough comparison stars to do photometry. However if a 300 sec exposure will saturate stars brighter than 14.9 mag and my target it 15.5 mag, then I will probably have very few comparison stars to choose an I should use a shorter exposure time. The same reasoning can be used to decide if a longer exposure time might be better.

Right now I flip back and forth between CCDciel and CDC, identifying what I guess is the faintest saturated star in CCDciel (magenta center), then send that image to CDC and find that saturated star (sometimes this is easy, sometimes not so much) Then I make sure the Gaia stars are overlayed, click on the star and see - a 300 sec exposure will saturate every star brighter than 13.2 mag -- all approximations of course, but useful as a guide for deciding on an exposure time. I guess that's all this feature would do - help someone doing photometry get an idea of a good exposure time to use and not saturate too many comparison stars.

0002953: Code review SkyChart

Tue, 29 Sep 2026 18:10:36 +0200

I had some spare tokens for Claude.ai and used them to analyse the SkyChart code. Attached the result as two text files and a zip file with the corrected .pas files. I have not compiled or checked them in detail, but I assume they are helpful. Within the SkyChart_files.zip there are two more text files skychart-fixes.diff and skychart-fixes-README.txt explaining the proposed code modifications in more detail.

0002945: Platesolving of control frame fails because mount is still moving

Tue, 29 Sep 2026 10:03:39 +0200

We got a crazy behavior mostly on large goto slews. CCDCiel is starting the control frame and the platesolving process but the scope is still on its way to target. Therefore platesolve fails.

ccdciel log says got is finished
2026-08-13T22:44:25.265 3: EQMod Mount: Schwenk ist abgeschlossen

but devices log stated it 20s later
2026-08-13T22:44:45.287 EQMod Mount: [INFO] Telescope slew is complete. Tracking TRACK_SIDEREAL...

What can I do?

Mount: Skywatcher EQ8
IndiLib, Indistarter, EQModGui
CCDCiel and Indilib on same pc, therefore timestamps in logs are in sync.

0002949: Cannot Connect to Telescope

Mon, 07 Sep 2026 14:19:14 +0200

I have an EQ6R-Pro, which I run remotely via PC through ASCOM and EQMOD (also installed). Unable to add EQMOD.Telescope to the telescope connection window in Cartes du Ciel. It always defaults to POTH.Telescope under the Telescope connect window. Even if I try to change the telescope, the drop down in the ASCOM telescope chooser window shows nothing. It is literally blank.

I can control the telescope successfully with NINA and Stellarium, and both are working flawlessly with ASCOM and EQMOD. But I want to stop using Stellarium due to its slower-than-molasses performance and permanently switch to Cartes du Ciel. However, I am unable to do so. I am attaching a couple of images to show what is happening. Not sure how to fix it.

0002951: VM 9.1 Coordinate grid tranparent.

Mon, 07 Sep 2026 14:18:27 +0200

Coordinate grid is transparent through to the far side of the Moon confusing when attempting to pick out the correct grid lines.

0002946: Atlun - blank display with QT5

Thu, 03 Sep 2026 09:02:24 +0200

Hello,

First of all, congratulations on Virtualmoonatlas, it's very neat.

There's an Archlinux AUR package that compiles virtualmoonatlas' master branch, and it uses gtk2.
Since gtk2's deprecated and not even in the main Arch repositories anymore, I tried building with LCL_PLATFORM=qt5 make instead.

It built and installed fine, yet when launched, neither the moon nor the black background appeared.
I have attached a screenshot of that. On the otherhand, photlun, for instance, worked fine. With GTK2, there weren't any problems.

I am not sure whether QT5 is actually supported. If not so, I'd be interested in having QT5 support so that I can modernize the Archlinux package. I am no Pascal programmer and hence don't know large an effort that would be, though.

Thanks for your help

0002942: Indi, CCDCiel handling of Indi driver refusal connect

Mon, 17 Aug 2026 17:27:16 +0200

Noted the following:

Indi, CCDCiel handling of Indi driver refusal connect result in this in the log:

026-08-04T22:18:07.201 9: Sky Simulator: Connecting to INDI server "localhost:7624" for device "Sky Simulator"
2026-08-04T22:18:07.216 2: Connecting Mount INDI "Sky Simulator" …
2026-08-04T22:18:07.278 9: Sky Simulator: INDI server send new device: "Sky Simulator"
2026-08-04T22:18:07.278 9: Sky Simulator: Exec: indi_skysimulator, Version: 1.0, Interface: 1
2026-08-04T22:18:08.622 1: Sky Simulator: Server Disconnected
2026-08-04T22:18:09.279 1: Mount connected
2026-08-04T22:18:10.404 3: Sky Simulator: Mount capabilities:
2026-08-04T22:20:47.476 9: Disconnecting devices

A driver that refuses a connection is legal INDI, and the client should say so rather than dropping the server and claiming success.

0002944: CCDCiel opening port 0 for TCP/IP server

Mon, 17 Aug 2026 17:20:03 +0200

Hello,

I've been having a new problem for the past two days: CCDCiel seems to be trying to start the TCP/IP server on port 0, which of course fails. In the settings, the default port is actually set to 3277. Resetting it doesn't change anything. I've already reset the configuration files, but that didn't help.

I tried both the PPA and daily versions of CCDCiel, and both exhibited this behaviour.

CCDCiel log:

[...]

2026-08-13T11:35:41.007 1: TCP/IP server stopped

2026-08-13T11:35:44.059 1: Socket error 9: Bad file number.

2026-08-13T11:35:44.225 1: Socket error 9: Bad file number.

2026-08-13T11:35:44.257 2: TCP/IP server is listening on port: 0

[...]

2026-08-13T11:36:56.642 1: Socket error 9: Bad file number.

2026-08-13T11:36:56.645 1: Socket error 9: Invalid file number.

2026-08-13T11:36:56.656 2: TCP/IP server is listening on port: 0

[...]

0002943: Wrong Moon Rise and Set Times in Ephemeris, and Details

Mon, 10 Aug 2026 19:20:56 +0200

When checking the rise/set times in the Ephemeris Calendar, they are totally wrong when compared to rise/set times from other sources.

For example: https://www.timeanddate.com/moon/canada/toronto

The same error can be found when clicking on the moon, and selecting the object details, at the very bottom:

Rise: Local horizon 03h42m42s Azimuth: [...]
Transit: [...]
Set: Local horizon 14h06m33s Azimuth: [...]

0002941: CCDCiel discovery find only one of two Alpaca servers

Wed, 05 Aug 2026 11:30:12 +0200

My Sky simulator has Alpaca server address 127.0.0.1, port 11111. When I use a com device in Ascom 7 is starts a second Alpaca server 127.0.0.1, port 32323. CCDciel sees the only the Ascom7 server. Fix to discover both servers:

cu_alpacamanagement.pas:

Line 354
- if not f_loopback then Result.Add('127.0.0.1');

+ {A unicast datagram to 127.0.0.1 reaches only ONE of the sockets bound to
the discovery port, so a second Alpaca server on the same machine - ASCOM
7 starts one automatically - is silently invisible. The loopback
broadcast address is delivered to every socket bound with SO_REUSEADDR,
so all local servers answer.}
if not f_loopback then begin
Result.Add('127.255.255.255');
Result.Add('127.0.0.1');
end;

Keeping 127.0.0.1 as well costs one extra datagram and covers any server that binds the loopback address explicitly rather than 0.0.0.0; the duplicate check drops the second reply from a server that answers both.

0002940: Minor tweak in cu_tiff.pas

Wed, 29 Jul 2026 14:55:29 +0200

Minor tweak in cu_tiff.pas, remove the thefile.free in lines 370, 522, 661, 808

try
thefile := tfilestream.Create(filen2, fmcreate);
except
thefile.free; // <-- thefile is garbage here
exit;
end;

or use attached version

0002939: Le driver de Bresser ne veut pas s'installer

Sat, 25 Jul 2026 09:48:39 +0200

C'est un problème avec ASCOM j'aimerai savoir si d'autre ont eu le même problème ?

0002927: Camera cooling not fully stopped

Mon, 20 Jul 2026 22:04:47 +0200

Hello,

when selecting camera warmup as termination command of a planned sequence, CCDCiel just sets the target temperature to 20°C. This is in summer not ideal, since the ambient temperature can go higher. This leads to continued cooling at the end of the session (or during daytime, if CCDCiel not terminated until then).

I see the following as possible solutions:
- Set target temperature to really high values (e.g. 60°C)
- Disable cooling instead of increasing target temperature

Thank you