AvNav - navigation in the browser

[wellenvogel02]

[ekoleponen]

HW: RPi4 2G, openplotter3-64bit-starting, burned the image on 16G SD.

I have been testing AvNav and have liked a lot what I have seen.
I installed it via OP3-Settings 3.4.4 and AvNav Installer 3.0.6-beta.

My problem concerns the ocharts-maps.
Before I installed AvNav I used Opencpn 5.6.2 to purchase and download the charts using the ocharts-dongle. Got sets Poland, Estonia and Finland.
As far as I can judge the installation in Oc5.6.2 ended with success with all the 3 sets.

Now I have been doing the format change procedure with Ocharts-plugin running on the RPi4. Ocharts-plugin is configured to use directly the Oc5.6.2-directory.

Sets of Estonia and Poland seem to work ok, I assume the conversion process is over and zooming to for example level 15.7 is not a problem.
The problem is the Finland-set, to me it seems that it is not advancing.
The "htop"-command shows that one processor core is reserved for the conversion process, but so far RPi4 has been doing the conversion for almost 10 hours and the file "CS_home_pi_Charts_oeuSENC-FI.avcache" has been of the same size the same size for 2hours. Also zooming to levels greater than 10.7 is not working.

The AvNAv-manual states that the conversion process is over when the core is freed up.
AvNavOchartProvider status indicates that CachePrefill is going on as there is a yellow status circle.

I am pretty sure that I have seen also a message "Failed to fetch".

Is there a way to check what is going on?

with best regard and big thanks for the work you have already done!!

[wellenvogel02]

You may always check the log of the ocharts plugin.
It's at /home/pi/avnav/data/ocharts.
Named provider.log.
Additionally you can search in the AvNav log files for lines with the string
PROVIDEROUT
This could give us some hints if the provider is potentially restarting due to some crashes in the ocharts-plugin.

Basically the prefill process is not really necessary (it's just speeding up navigation on lower zoom levels as the tiles are already there).

But potentially there is a problem with one of the charts and it will potentially crash when trying to render this chart.
Hopefully the logs will give us some hints.

[ekoleponen]

Checked the log files.
There is one "provider.log" which is updated continuosly and 20 files named as "provider.log.YYYY-MM-DD-hh-mm-ss".

The "provider.log" has no entry of "PROVIDEROUT", few "ERROR" markings though (see the attachment)

Any ideas ?

[wellenvogel02]

Could you attach the complete provider.log here?
And the latest with the date extension.
And the PROVIDEROUT will be in the avnav log ( you can download it from the status page).
We can already see that it has some difficulties with one of the charts...
Maybe it is about the 64Bit system - most probably the OpenCPN plugin (that AvNav is using) is not that much tested on 64 Bit arm...

[ekoleponen]

Here are the files you requested. Avnav.log is from the directory avnav/data/log as I did not find the download action in the Server/Status or Ocharts/Status pages.

Had to change the extensions from log to doc to be able to upload them to the Forum...

[wellenvogel02]

Unfortunately as expected:
2022-08-04 14:37:15,794-559-915-Thread-10-INFO-PROVIDEROUT: Segmentation fault

So the ocharts stuff is crashing.
I will try to get a bit closer to the problem.

[wellenvogel02]

What you could try to do:
Give the ocharts stuff a bit more memory.
On the server/status page go to plugin handler and click on the edit button at ocharts.
There you can give the memory % it should take at most. Maybe try 25 or even a bit more (would be around 500MB on your system). Currently it limits to app. 230MB.
This restricts to only 3 open charts - will do a frequent opening and closing of charts what really could make such issues more likely.
If it would crash from time to time (seldom) you most probably would not really notice this...
Anyway 2GB is really at the low end for OpenPlotter.
All the local graphics stuff needs a lot of memory.

[ekoleponen]

Changed the "system-ocharts provider/memProcent"-line to 30. The line was empty before I changed it.
Dropped also the "Raspberry Pi Configuration/Performance/GPU Memory"-value from 128 to 96.

Observations after the changes:
- the zoom level is now a total integer, previously it was 10.7, 11.7 and so on.
- "zooming in" sometimes freezes the chart view (quite often actually), "zooming out" helps, sometimes it takes 20 to 25 seconds to the chart view to be drawn again (at the out zoomed level).

Questions:
- can I leave the Rpi to crunch the charts alone, without any other app to run, or does it need that the chart view is sometimes altered ?
- what is the correct way to exit AvNav ? The chromium "X" at the upper right corner or the power button in the "Server Status"-page ?? That button makes total system shutdown.

[wellenvogel02]

Trying some answers...
(1) delay on zooming: we should check if we still see those segmentation faults in the avnav.log.
20 seconds is to much...
But if you try again it should be much faster as now the tiles are in the cache
(2) zoom level int or not simply depends on how you zoom. With 2 finger zoom you can easily get decimals, the buttons always add/subtract 1.
Anyway on the server the zoom is always an integer, the rest is simply enlarging/shrinking in the browser
(3) It's perfectly fine to leave the pi alone for doing the prefill. The server anyway does not depend on any client.
(4) Normally there is no need to somehow shut down/exit AvNav. If you don't need the display - just close your browser window at any time. If you really would like to stop the server you can do this from the installer. But as said - there should be no need...

[ekoleponen]

I left the RPi alone (not even AvNav on) to do the prefill, checked that the provider is running via htop-command.

After 2 hours checked the situation:
- the file "CS_home_pi_Charts_oeuSENC-FI.avcache" had not grown at all
- avnav/data/ocharts-directory was filled with files (about 140) "chartinfocache123456", 123456-being random mix of numbers and letters.

Started the AvNav and did some zooming and moving around, the result was that the file "CS_home_pi_Charts_oeuSENC-FI.avcache" started to grow.

avnav.log is full of "PROVIDEROUT:segmentation fault"-messages.

At the moment the chart material is useless.

[wellenvogel02]

Ok.
Could you check the status of the filler?
Was it already working at the Finnland charts?

Would you be willing to help to go more into detail with the cores? Will require some command line actions...

In the moment I cannot really set up a new system to try to reproduce your problem as I'm on a sailing trip...
I know that there also had been cores with swedish charts. Just trying out a new version of the OpenCPN plugin - not sure if this will do any better.

But it would be helpful to understand if the cores on your system are the same...

If you would be willing:
(1) edit the file /usr/lib/avnav/plugins/ocharts/provider.sh, remove the comment at line 9 (need sudo to do this)
(2) execute:
sudo -i
echo 'core%p' > /proc/sys/kernel/core_pattern
exit
(3) restart AvNav

Now wait for some file corexxxx to occur in /home/pi/avnav/data/ocharts
Now revert the change from (1) to prevent further core files.

Analyse the core file:
gdb /usr/lib/avnav/plugins/ocharts/AvnavOchartsProvider /home/pi/avnav/data/ocharts/corexxx
where
^D
And provide the output together with some provider.log-xxx - preferrable from the same time.

[ekoleponen]

The status of the filler was "FILLING" and the chart set was the Finnish charts.


Followed the stops (1) -(3) and got 3 corexxx-files, reverted the step (1).

Also got the provider.log-xxx files covering the test period.



Need help with gdb though, I understood the sequence being:
gdb <ENTER>
/path1/.../ <ENTER>
/path2/.../ <ENTER>


but that was clearly not the case, so need a bit more detailed instructions. GDB started though, but refused to take any paths as argument. So at this moment I have no analyzed data.



I am glad that I made a backup-SD before poking with the RPi, as the situation now is as follows:
-AvNav first declared that no charts are available
-Ocharts plugin had disappeared
-also the was an "unhappy paper"-image telling that localhost refuses to connect
- the load of the all 4 cores is skyrocketing thanks to "oexserverd"


Just barely were able to copy the files on USB-stick before shutting the RPi down.


So new instructions would surely be appreciated.

[wellenvogel02]

Ok, thanks for following the hard trail...
I'm trying to reproduce something in parallel (have also cores on pi...).
The gdb command is as I wrote:
gdb <pathname_of_executable> <pathname_of_corefile>
so
gdb /usr/lib/avnav/plugins/ocharts/AvnavOchartsProvider /home/pi/avnav/data/ocharts/corexxx
Just replace corexxx with the real name of the core file
It will start up, showing you a lengthy list (potentially you need to press enter once) and afterwards waits for your commands.
We just need
where
quit
Where will give us the stack trace.

Not sure what happened with oexserverd.
The only issue is that writing the cores takes time.
Btw: Do you have OpenCPN running in parallel? (should work - but just to be sure...)

[ekoleponen]

Is it possible to redirect for example gdb ..../ocharts/corexxx > testdata.txt. ?



Do I have to use the poked Sd-card ?
There is a risk that it is unusable due to the load problem...