I upgraded to Kstars 3.6.9 stable and am testing different cameras.
I noticed that when I take a frame with my ZWO 294MCPro the Bitpix flips from 16bit to 8 bit !
Screen shots attached.
This never used to happen.
Before exposure:

After 1sec exposure:

Hi Nick,

I updated to today's Indi and KStars (git) and tried to reproduce with my ASI294MC-Pro. After a 1s exposure, the FORMAT remained at Raw 16 Bit.

Did you update Indi and Indi-3rdparty, too?
I don't know whether this would have any effect but did you re-try "SAVE" in Indi control panel / Options?

Currently my settings look like this:

One thing I noted in your settings is "high speed mode = 1". I'm not sure but this mode could limit the bit depth of the cam thus the 8bit mode after the first exposure.
What happens if you set "high speed mode" to 0? IMO the only use case that may profit from hsm=1 is lunar/planetary imaging that requires very high frame rates.
For deep sky imaging I would leave it at 0.

Hi Alfred. I have never used HishSpeed mode setting on this camera, I was just messing around to see if that would fix it.
I've set it back to 0 as it always has been for the last 4 years.

Did an apt upgrade on server and client, but they are both already fully up to date.
Same issue.
The problem seems to start when the drivers load. If I edit my camera profile: 'ZWO CCD ASI294MC Pro_config.xml'
and manually set 8 bit off and 16 bit on, then when I start up, the camera immediately switches to 8 bit mode.

My server is Armbian arm64 Jammy 22.04 (ie Ubuntu 22.04)
kstars-bleeding-data/jammy,now 6:3.6.9+202402010456~ubuntu22.04.1 all [installed,automatic
My client is Linux Miint 21.2 (Ubuntu 22.04)
kstars-bleeding-dbg/jammy,now 6:3.6.9+202402010456~ubuntu22.04.1 amd64 [installed,automatic]
Looks like 01 Feb release everywhere.

I am not using nightly versions and don't want to go down that rabbit hole.
Looks like your patch level doesn't have this issue
I guess I might have to wait. I'll use a previous working version until then.

Thanks for testing.
Nick

Hi, Maybe the problem is that a pre-release/nightly version of 3.6.9 has been put into the release binary repository ?
I see 3.6.9 isn't due for release until 01 April ?
This is not such a great idea if so.
Nick

Ok I just tested the same setup with kstars 3.6.8 and the ASI294MCPro camera works fine.
It starts on 16 bit and stays there.

I would say there is some sort of bug in the binary version of kstars 3.6.9 that I have.
It was installed from the ppa
deb ppa.launchpad.net/mutlaqja/ppa/ubuntu jammy main
so not a nightly build, but the stable release.
Client x64 Linux mint 21.2 (ubuntu 22.04 base)
Server arm64 Armbian (ubuntu 22.04 base).
kstars runs on the client so not an issue with the server.
Nick

Ok tried 3.6.8 and 3.6.9 09 fec 2024 build and both work.
Now I try the 3.6.9 01 Feb release it now works.
Looking at the .xml profile 'ZWO CCD ASI294MC Pro_config.xml' I see it is now much bigger and has been re-ordered.
I suspect the old one was somehow incompatible with the new version.
When I ran 3.6.8 or 3.6.9-09 Feb it saved a new version on exit.
Just guessing.
Nick

Excellent news, problem solved! Let's hope future upgrades are not affected by such teething problems.

I think the moral of this story is that you need to re-generate a device profile when upgrading kstars.
I had the profile from an older release (3.5.x I think) as I hadn't used this camera for a while as it had been on another system not using kstars.

I've had similar issues with other hardware in the past. Although it doesn't sound reasonable at first, clicking "SAVE Configuration" in the Indi / Options TAB can make a difference. However, I don't know whether or not this would have fixed the xml profile in this case.

No. In this case I set the correct bit size and saved many times. The problem is that save worked but did not turn a corrupt file in to one that the
new version of ekos could understand. Maybe because the format of the original was just too out of date. I've had a similar problem years ago
but I had forgotten. It is only later when 3.6.9 started magically working and I looked at the difference between the new file and old one i realised
that new one was very different.

This begs the question why does the transition work flawlessly with some setups but not with others. My probably naive expectation would be that a click at "SAVE" would trigger the config file being written in the then-current format, overwrite older versions and make the program work as expected. Obviously this was not the case here.

At some point my system must have made the necessary changes without my intervention.