Ever 10 frames in a series of 30 subs. There was a previous run of 10 subs so I'm already starting with a bit of memory load.
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.
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.
knro wrote: I would like to know how I can replicate this.. I took 500 images on StellarMate a couple of weeks ago and I couldn't detect any memory leak. Was HIPS overlay enabled? I'd like to replicate exact conditions.
If HIPS overlay is enabled by default then yes, it is. My objective is to be able to pack the whole imaging train minus the mount into a suitcase, preferably carry-on sized bag. Resolving this is very important to me since I'm trying to avoid taking a full computer into the field. Full control and imaging from a RPi opens SO many possibilities that I really want to explore.
I'm experiencing the same behavior on the current version running on a RPi 4.