Thanks for fixing that “memory leak” bug, Hy and Jasem. I downloaded the latest code today and it is releasing the memory. Now all I need is a clear night and to re-collimate after a particularly chilly night.

Read More...

Thanks, Hy. Don’t get me wrong, i think what you all have been doing with KStars over the past two decades is absolutely fabulous. It is encouraging that people across the planet can cooperate to achieve something so wonderful.

Read More...

Yikes! You are giving me too much credit as this is beyond my capacity. I find it odd that you can’t reproduce the problem. Is this the way we have configured our respective systems? Just you have all the info, I am running Stellarmate from a 1TB SSD that I partitioned 64GB for the OS, and the rest for the Astrometrics folder and Picture Folder. There is about 40GB free on the 64GB partition. I am using a ZWO ASI294MC Binning 1. There is simply no doubt that here the RAM allocation reaches 3100 MB after which performance is severely degraded.

Read More...

Jasem, I’m no C++ programmer but I was browsing the FITSViewer code on GitHub and I might have found something. At line 312 of FITSViewer.cpp you are defining the destructor but there is no code within the following parentheses as there is in the destructor definition in FITSview.cpp.
Mike

Read More...

One more observation. If I do the multiple FITS Viewer window closure routine but do not provoke a crash, after closing all windows except for the main KStars window, the RAM allocation for KStars falls to 782 MB. However, the total RAM used remains at 3100 MB. It does not get released until KStars is closed. I hope all of this is of use to you.

Read More...

I just finished this latest experiment. I set up a profile with my mount and the telescope simulator and did a series of alignments on Vega. As before, the RAM allocation for KStars crept up by about 100 MB per alignment run. However, in this case the maximum RAM allocation was 2300 MB at which point VM swapping seemed to start, dropping the allocation to a steady 2100 MB. I quit the experiment after 20 alignment operations. There was no crash in this experiment and no detectable degradation in performance.

Then I decide to try to provoke a crash by taking images as before and closing the FITS Viewer each time. The RAM allocation mounted to just over 3000 MB. Then I moved back to the alignment module and did a few alignment runs. Eventually the program slowed to a halt, stuck in the alignment module. No crash, but as good as. This is consistent with what I observed the other night in my real imaging run.

Read More...

I’m glad to be of help. The other place where I have experienced a KStars crash is in the alignment module. I can appreciate that this module is very demanding on resources so a crash here is not necessarily related to the module itself, but if KStars has maxed out the RAM allocation and then you try to run Alignment then you could get into trouble. The other night when this was about to happen I noticed that the RAM allocation was at 3000 MB. I had been doing quite a bit of imaging, and as is my habit, closing the FITS Viewer window, plus aligning at several points. So I am not sure exactly sure what caused the crash, just that I was using the Alignment module when it happened. I will devise another experiment using the simulator to see if I can replicate the issue with the Alignment module by itself.

Read More...

It's raining here and I decided to investigate the KStars "memory leak" issue with a stress test. I noticed that if I close the FITS Viewer window during an imaging session the RAM is not released on the RPi4. The result is that the memory allocated to KStars grows. Being bored and retired I decided to take this to the limit. I created a dummy imaging session with 100, 10 s subs and I closed the FITS viewer each time the image downloaded. As I expected, the RAM allocated to KStars grew from 912 MB to about 3000 MB at which time (I assume) swapping into VM starts to occur. I continued this process and observed the RAM allocation staying the same but the allocation of VM continues to grow. The system began to get very sluggish and when the VM allocation reached 6.1 GB, KStars crashed (probably because the RPi is trying to save itself). The control experiment where I don't close the FITS viewer results in a stable system with no memory allocation increase. The obvious solution to this issue is - don't close the FITS viewer window -but maybe this observation can be used to help locate a bug. I am using the latest Stellarmate version 1.8.0.

Read More...

Michael Moir replied to the topic 'VNC connection to Stellarmate' in the forum. 4 months ago

This thread is a bit old, but I will add my 2 cents. The problem has to do with the way in which the remote desktop is executed and how data is sent to the PC. VNC Viewer uses the graphics of the RPi and sends screen images to the PC. This can cause data bottlenecks at the preferred screen resolution of KStars, 1920x1080. Products like TightVNC create a replica of the RPi desktop on the PC. The result of this different encoding of the screen data means that TightVNC (and probably others) gives a snappier response and fewer, if any, dropouts compared with VNC Viewer. VNC Viewer is really intended for remote tech support whereas TightVNC is intended for headless remote operation.

Read More...

Your documentation is very good. Thanks for doing that.

Read More...

I wish there were some documentation on this since virtually everyone has difficulty with plate solving. However, it is worth some time looking at the ToolTips in each of the parameter entry boxes to understand how to optimize the process. There are two steps to plate solving, extracting stars from your image, then matching the extracted stars to the library images. The extraction of stars is done using a program called SExtractor. There is some documentation on SExtractor on the web mostly useful for developers but it is helpful to look at to get a better ideas of what the program is doing. Basically, you select parameters to detect stars above a brightness and size value. You don't want to detect noise as stars nor do you want to select every star in your image, so there are parameters to filter out the dimmer stars and ones that are not round. One SExtractor has done its job you have to prepare the extracted image. For a telescopic image you want to limit the number of stars you pass to the plate solver to 50-100 or so from an initial selection of 500-1000. Too many stars and the plate comparison will take too long, too few and the plate comparison will not yield a result. I think the SmallScaleSolving works pretty well for starters. In my experience it is having too many stars that is the issue rather than not enough, at least for those of us who are working at a FOV of a degree or so.

Read More...

I’ll just echo what others have been saying. Having a stable wifi connection is everything. I don’t rely on the feeble RPi wifi and instead use a wired connection to a third party wireless bridge running at 2.45 GHz that has real antennae. This and setting up the connections at with static IP addresses ensures the most stable connection. A completely wired Ethernet connection would be best but is not always practical.

Read More...

I have had my share of networking issues as well. My recommendation is not to rely on the rather feeble wifi of the RPi and instead use a wired connection to a third party wireless bridge that has proper antennae. Also, you should set up the network connection on the RPi to be a static IP address. Don’t use the 5 GHz wifi band, just use a wireless bridge at 2.45 GHz. You don’t need the extra bandwidth for VNC. All of these ideas will get you a more stable connection.

Read More...