CapnRon wrote: I have not experienced the memory link and have not had clear skies to try my cameras (SBIG 8300M and SX Lodestar) other than test shots. But I applied the two settings recommended above and then the issue is that you have no star image in the focus routing. you can pull it up in the fits viewer, but you cannot select stars there.
I am hoping this is not an issue with my setup and have gone back to the 'normal' settings.
I experienced this recently, it’s unrelated. But it seems that drivers for cameras got reset to default values with one of the latest updates. Make sure your camera is set to 16-bit raw. Mine reset to 8-bit and no guide stars showed up.
This overall program is 'extremely' complicated and I find I have to test everything I want to use before hand; otherwise I am sure to have a problem (mostly of my understanding of available options) when I go to actually use a module.
thanks for all the hard work.
hy wrote: I'm curious if there's a common thread among the people who experience this leak (e.g. I still can't replicate it, and as of recently, I don't believe Jasem could either--I know he's hard at work looking into it). For instance, are you all DSLR users? RGB camera users with debayering, etc?
If you experience this leak, could you please post more details about the minimum configuration you use that will trigger this leak.
camera model and type, e.g. Canon DSLR with resolution WxH, ZWO 1600 monochome resolution WxH, ...
fits, raw, ???
Running fitsviewer while you capture?
Processor (e.g. RPi4) on what OS (Raspbian? Ubuntu 18.04? Stellarmate?)
How did you install KStars (Stellarmate, AstroPi3, AstroBerry, ...)
What release are you using when you observed the leak? (released 3.3.9, nightly at what date),
Also, can you tell how much is leaked per image? (e.g. by running the linux command 'ps aux | grep kstars" after every 5th or 10th image for as long as makes sense) and how that relates to the size of the image your camera captures
I'm on a 4GB RPi4 running StellarmateOS, updated via internet between tests. I haven't got a record of the versions that I experienced this issue with since I've upgraded Stellarmate since then. It would have been what ever packages were published when I started this thread.
Camera I was using here is a QHY168C, consuming about 300MB per frame, filling 4GB of RAM in less than 15 frames. Shooting FITS and debayered. I will test again tonight.
stellarmate@stellarmate:~$ ps auxww | grep kstars Start: stellar+ 1301 1.0 36.9 2959744 1372704 ? SLl 11:20 6:49 /usr/bin/kstars --paused 10 subs: stellar+ 1301 1.1 45.5 3280028 1691824 ? SLl 11:20 7:18 /usr/bin/kstars --paused 20 subs: stellar+ 1301 1.2 54.1 3600308 2012224 ? SLl 11:20 7:43 /usr/bin/kstars --paused 30 subs: stellar+ 1301 1.2 62.4 3920592 2317312 ? SLl 11:20 8:07 /usr/bin/kstars --paused stellarmate@stellarmate:~$ sudo dpkg --list | grep kstars ii kstars-bleeding 6:3.3.9+202001011609~ubuntu18.04.1 arm64 desktop planetarium for KDE ii kstars-bleeding-data 6:3.3.9+202001011609~ubuntu18.04.1 all data files for KStars desktop planetarium ii kstars-bleeding-dbg 6:3.3.9+202001011609~ubuntu18.04.1 arm64 debug information for the desktop planetarium for KDE stellarmate@stellarmate:~$ sudo dpkg --list | grep qhy ii indi-qhy 2.6~202001021211~ubuntu18.04.1 arm64 INDI QHY Driver. This driver is compatible with any INDI client such as KStars or Xephem. ii libqhy 6.0.5+unstable~201912300954~ubuntu18.04.1 arm64 libqhy provide libraries to access and control QHY CCDs and Filter Wheels.
Disconnecting the gear and stopping the server made no difference of course. Memory is freed immediately upon kstars exiting. 30-ish subs are about all I can get before exhausting the 4GB RPi4.
I also have these repeated and absolutely unpredictable crashes, but only on my Pi4. Never on my mini-PC, so I suspect this is something inherent to the Pi4 firmware or the architecture.
1) I think you hit an important point with the 'exposure delay' . Adding 5 s between exposures has reduced crashes for me.
2) I have FAR fewer crashes (but not 0) when I run the Pi4 from an SSD with Swap enabled instead of from an SD card. The SD card is S-L-O-W and probably aggravates the data congestion the Pi4 can't handle.
3) FITS viewer on or off makes no difference for me.
So, is you're suspicion that it has to do with the saving of the file?
Are you talking about a fits camera, or a DSLR? A mono camera or an RGB camera?
I can't recognize a pattern. In fact, the same setup, no change in hardware or software updates, would run flawlessly through the night yesterday and record 500 frames, only to crash after 100 frames today.
And that only happens on the Pi4, my mini-PC (also with only 4GB RAM) runs just fine through the night.
Definitely Pi4 specific.
But I concur with the rest of your description: Kstars and Ekos windows are gone, only the desktop is visible.
I have not extended the delay beyond 5s, perhaps that increases stability further? I am using the 183MM Pro, so basically same camera, same file size. Also happens with the ASI1600MM, which writes slightly smaller files (32 MB).