AvNav - navigation in the browser

[ekoleponen]

Glad to be able help the community!!

So far no "AssembleLineGeometry"-entries at all.

[wellenvogel02]

If everything was running now without problems it would be helpful to see if there was only one problem with the strange corrupted chart - or if you also encountered the problems I have seen on my side (the ones I made the first correction for).
So if you are still motivated to test:
(1) remove the file /home/pi/Charts/oeuSENC-FI/OC-358-AJIAP4.oesu (or just move it to a directory outside /home/pi/Charts)
(2) revert the lib back to the original version
(3) restart AvNav and make some change in the o-charts setting to retrigger the prefill process
(4) watch for segmentation faults
If no seg faults occur we know that it was only the one chart.
If there are seg faults, try again with the first corrected library (sub folder bullseye-arm64) and check if this passes.

[ekoleponen]

OK, started the process

[ekoleponen]

Tests failed.

What I did:
1. moved the file /home/pi/Charts/oeuSENC-FI/OC-358-AJIAP4.oesu away
2. put the original libo-charts_pi.so to work
3. restarted avnav
4. Estonia ok, Finland generated segmentation fault (see attatchments)
5. downloaded the patched libo from subfolder bullseye-arm64
6. put the patched libo to work
7. restarted avnav
8. Estonia ok, Finland chokes the RPi totally when the cache is about 8000 kB:s
(see attatchments, hope these give some info)

By choking I mean no mouse, keyboard or ssh, just brutal poweroff to recover, then after poweron/rebooting about 30 seconds to do something...I stopped avnav (sudo systemctl stop avnav).

Not looking very good...

[wellenvogel02]

Unfortunately the logs do not really give us a lot of information.
Espcially it's hard to relate which log refers to which problem.
In the provider.log it seems that the system cannot really decrypt the charts any more. But we need a provider.log that contains the start up.
So you need to add the other logs with the timestamps.

If you would repeat it would make a lot of sense to stop AvNav, move all the logs (avnav/data/log, avnav/data/ocharts) into a separate directory for each step and then start AvNav.
This way we can easily relate the logs to the problems.

You could try again with the diag lib (not diag20!) - this could give us some more hints.

But at least first conclusion:
It's not only the the one chart that is potentially corrupted - there are more issues.

Which way do you connect to your system?
If you have the desktop running (even if with VNC) you maybe should reduce the memory settings for the avnav o-charts plugin again to it's default.
Such a blocking of the Pi could easily be caused by exhausted memory.
A "top" command could give you some hints (even if it takes minutes to start...).

[ekoleponen]

I am running a desktop, vnc and ssh are enabled.

What I will do next is that I am going to make a new clean install via the op3/64bit image,
install the programs I need and then download and install the charts.

Let's then see where we are, and if necessary test from there.

Will get back!

[ekoleponen]

Ok, back in business


Did a fresh install of the OP3, and downloaded the ocharts via Ocpn.


Have not yest installed AvNav going to do it via OP3.
I guess the preFill starts, when the Provider is defined to use the Ocpn charts.


Any instructions ?

[wellenvogel02]

Do the charts work with OpenCPN.
Otherwise just use them like the last time.
Unfortunately the simple "use OpenCPN charts" in the plugin config does not work.
As a last resort just download them agsin from the store ans upload to AvNav.

[ekoleponen]

Ok, thanks for the help.

[wellenvogel02]

Any new results?

[wellenvogel02]

I've got an info from o-charts that the chart set with the corrupt chart should have been corrected - so maybe an update of the set should solve at least parts of the problems.

[ekoleponen]

What I have done:
- clean OP3 install
- downloaded the charts (FI, EE, PL) for Opencpn
- checked they worked, Opencpn crashed once (which is why I got interested in AvNav in the first place)

- installed AvNav via OP3
- changed the memory allocation to 20%
- did NOT change the configuration to use Opencpn-charts
- downloaded today (18.8) the FI-charts from Ocharts, uploaded them to AvNav
- AvNav started to work with the chart files, after 4 hours it was done, no catastrophic error messages ( if I understand correctly), only in the attached picture contains an error of "invalid chart type".

- downloaded and uploaded the EE- and PL-charts without problems, and AvNav made the prefills succesfully.

So at the moment things look good !

[wellenvogel02]

Ok, thanks for testing again...
So my understanding:
(1) With the corrected FI set things are working without issues with the original software without any corrections.
(2) the other sets are working anyway
The "invalid chart type" is no real problem as charts of this type are not used at all.
There are still some minor errors but I guess we can ignore them.

[ekoleponen]

(1) That is correct
(2) That is correct

One anomality:
after the completion of the preFill of the FI-charts, I have noticed that every time I have started the RPi, the preFill-process starts for about 2 minutes to prefill the FI-preFilled filecache. The timestamp of the FI-preFilled filecache changes, the size stays the same.
Other two chartsets remain stable along with their timestamps.

[wellenvogel02]

Do you see the errors again on each start up?
It could happen that AvNav assumes that it should create some missing tiles - but finally it is not able to do this.
But I guess this should not really be a problem at all.
Once you start using the charts the cache files will grow anyway as there will be additional charts that will get rendered and cached...