OpenCPN Freezing

[NahanniV]

Or, possibly MBtiles is not respecting the MEMCacheLimit

That would be a question for
@bdbcat

[geoffr]

JM,

I think it's all correct:

=============
pi@openplotter:~/.opencpn $ cat opencpn.conf | head
[Settings]
LastAppliedTemplate=
ConfigVersionString=5.0.0
MEMCacheLimit=200
CmdSoundString=
NavMessageShown=1
InlandEcdis=0
DarkDecorations=0
UIexpert=0
SpaceDropMark=0
pi@openplotter:~/.opencpn $ uname -r
4.19.69-v7+
pi@openplotter:~/.opencpn $
=============

[NahanniV]

Seems like MBtiles is using too much memory.

The same thing was happening with raster and vector charts until I updated my system and added the MEMCacheLimit=200.

Hopefully someone here can help with this issue.

Can you easily reproduce the "Freeze" ?

Posting the simplest instructions to cause the freeze would be helpful.

[geoffr]

JM,

It's very easy to reproduce on my system. I have the settings as you outlined above. I then do the following:

0. I have two chart groups - KAP and MBTiles

1. Login via VNC (it will also happen if using the monitor/mouse.. perhaps not as often)

2. Using the KAP group scroll around the chart - should be fine

3. Switch to the MBTiles group and scroll around and it will freeze/loose the connection.

[NahanniV]

I downloaded an MBtile.

It seemed to work at first, but after about 30 seconds of constant scrolling back and forth it failed in the way you described.
The failure looks very similar to what I was seeing.

Hopefully @bdbcat will have a look at this.

[geoffr]

JM,

Thanks for taking the effort to reproduce!

Yes, hopefully @bdcat will take a look.

[geoffr]

Added to flyspray:

https://opencpn.org/flyspray/index.p...s&task_id=2614

[pinguino]

It's been almost two years, since the first alpha versions of opencpn with support for MBTiles, that I'm working with them. First with the Rpi 3+ and today with the Rpi 4.

With the Rpi 4 and 2 GB of RAM the problems disappear completely, but with the Rpi 3 it is crucial to use MbTiles created correctly so as not to exceed the graphic and memory capacities of the Rpi 3+. It is necessary to make MBTiles of smaller areas and less number of layers. For example, a small area would be the whole of Ibiza and formentera with zoom levels of z11,z13,z15,z17. Even so from time to time opencpn is closed but very occasionally. If we use the large MBTiles with many layers and high zoom levels the problems in the Rpi 3 are assured.

[transmitterdan]

Another thing that slows down the RPi is huge track files. I created a track file with 500K lines of XML. The RPi slows to a crawl because of the SD card access. It does not use a lot of CPU. It’s just waiting all the time for disk access to complete.

[hoolie]

Perhaps using an SSD as primary memory would help? Probably much more reliable too

[geoffr]

Pinguino,

Thanks for the comment.. you have confirmed my fears... Guess I'll be upgrading the pi

I can't remake the MBtiles as I'm traveling every day right now.. so will use the KAPs (which aren't as good).

thanks.

Originally Posted by pinguino

It's been almost two years, since the first alpha versions of opencpn with support for MBTiles, that I'm working with them. First with the Rpi 3+ and today with the Rpi 4.

With the Rpi 4 and 2 GB of RAM the problems disappear completely, but with the Rpi 3 it is crucial to use MbTiles created correctly so as not to exceed the graphic and memory capacities of the Rpi 3+. It is necessary to make MBTiles of smaller areas and less number of layers. For example, a small area would be the whole of Ibiza and formentera with zoom levels of z11,z13,z15,z17. Even so from time to time opencpn is closed but very occasionally. If we use the large MBTiles with many layers and high zoom levels the problems in the Rpi 3 are assured.

[transmitterdan]

So i think I may have a solution for this. I have been experimenting with an RPi 3. It’s an older generation with 4 cores and 1GB ram. SD card access isn’t the fastest. It blows up X11 for some reason that isn’t clear.

So I changed the main chart redraw loop to 2 seconds instead of 1 second and now no more lockups. I suspect that the issue is the multiplexer is driving several instruments with each NMEA message. These messages cause plugins to do stuff and draw on the screen. All of these are streaming into the X11 system and it just gets overloaded. On my system the X11 modules just die and the screen is stuck on whatever was displayed at that time.

Maybe on the lightweight platforms like this we should not have the canvas redraw loop be run on a continuous timer. Rather we should use a delay timer that gets started at the end of a redraw loop. That way we always give up drawing for a certain period to allow the other widgets and threads to flush out what they need.

I am not an X11 expert but it seems the lesser RPi platform can only pile up so many draw messages before it gives up. But that doesn’t mean they are no good. For me the 2 second redraw is just fine. And it’s stable apparently. I can view with multiple VNC viewers in headless mode and it’s actually quite nice to have my iPad or iPhone showing OpenCPN all over the boat.

[geoffr]

transmitterdan - do you have a build or instructions on how I can try your changes to see if it helps...

[transmitterdan]

Originally Posted by geoffr

transmitterdan - do you have a build or instructions on how I can try your changes to see if it helps...

I am not at the computer right now but in include file chart1.h should be a line that #defines a constant to 999. I think it is the only line with that number. Change it to 1999 and rebuild.

[transmitterdan]

Originally Posted by geoffr

transmitterdan - do you have a build or instructions on how I can try your changes to see if it helps...

Tonight I did rpi-update and things seem much improved. Maybe there is some kind of issue with previous OpenGL subsystem. In /boot/config.txt I am using the lines:

dtoverlay=vc4-kms-v3d
gpu_mem=64

This is the “real” kms driver not the fake one.

These rpi-update cycles are kind of hit and miss. Once in a while you get one that kills performance and then you get one that really helps. Wish they had this more well controlled.