AvNav - navigation in the browser

[wellenvogel02]

Just change some settings to let the prefill run again.
And yes, if you move around in the Finnish charts this triggers the problem (potentially).
You will always see which charts are currently handled (i.e. opened) in the provider.log.

So what I often do (assuming to be in /home/pi/avnav/data/ocharts):

tail --follow=name provider.log

That will show you the ongoing stuff.

[ekoleponen]

Ok, gdb did complain about a file...
Got more corexxxx-files if needed.

[wellenvogel02]

Many thanks.
The complain from gdb is ok, don't worry...
Funny enough it crashes more or less at the same place.
So I will create a new lib with a lot of debug output tomorrow.
If you want to play a bit it would behelpful to find out whether the problem occurs at some particular charts or just at arbitrary ones.
Typically the problematic chart is the last one in a log when a crash occurs.

[ekoleponen]

Happy to help !!

I wonder, could it be a corrupted SD-memory cell?

[wellenvogel02]

At the end everything is possible. Sure.
But on the other hand it's somehow predictable where it cores...
Let me build some debug stuff into the lib and let's try again.

[wellenvogel02]

Ok now I created a new lib with a lot of debug output stuff.
It's on the same dropbox folder, subfolder bullseye-arm64-diag.
Could you copy this one to your system and restart?
Potentially there will not be cores any more (but the charts are potentially somehow corrupt).
You could search for lines with:
INFO-AssembleLineGeometries invalid result (index 1 != 0, list==NULL)
in the provider.log and provide some of them (but especially need the lines before this message and potentially after a block of such messages).
Some lines are potentially rather long as they give us the list of all records that has been read for this chart.
So the provider.log file could quickly fill up and skip to the next one.

[ekoleponen]

Can not send you the provider.log file because it is much too large, even though I shrunk it.

The file which the photo decribes is 6 MiB!!

[wellenvogel02]

Ok, I received the log.
The interesting part is:
2022/08/09-14:38:42.844-0x7fb81257c0-INFO-Ingest200: record to large: /home/pi/Charts/oeuSENC-FI/OC-358-AJIAP4.oesu
2022/08/09-14:38:42.845-0x7fb81257c0-INFO-ERROR: ingest200 finished (2) with record 96, len 9084026, totalBytes 35530888, lastRead 6 /home/pi/Charts/oeuSENC-FI/OC-358-AJIAP4.oesu

The record type 96 is really the one containing all the infos that later the "AssembleLineGeometry" is missing.

Btw: Do you still see segmentation faults? I would suspect not...

[wellenvogel02]

Ok, I just created a patched lib again that changes the record size limit to 20000000 bytes.
So at least for the chart we saw in the last log it should solve the problem.
And I removed the very large log line.
Could you try again - sub folder: bullseye-arm64-diag20

We need to check again the logs for AssembleLineGeometry....

[ekoleponen]

No segmentation errors, will try the new lib and report back.

Only "PROVIDEROUT"-messages attached after 10 minutes of using.

[wellenvogel02]

Ok, good news - so we are investigating at the right place ;-)

[ekoleponen]

provider.log attached, no "AssembleLineGeometries"-entries.

AvNav was used about 5 minutes.

[wellenvogel02]

Ok, cool.
So it seems that at least this chart is somehow special - i.e. having a lot of points - this way really having some large records that the plugin code did not expect.
The render timeouts around this chart also support this hypothesis - rendering of a tile seems to take really long.
Could you now just again make a change in the settings so that the prefill is starting over?
Will run for many hours and give us a clear picture if we still have problems at other places.
I'm already discussing the problem with the OpenCPN plugin development and the o-charts guys...

[ekoleponen]

RPi has done the preFill now for 9 hours.
I have watched and used only the OchartsProvider-page.

The preFill started with Estonian maps and they were ready after one hour, no "ERROR-render timeout"-messages. And the numbers/sizes advanced on a steady pace in the OchartsProvider-page.

With the Finnish maps it has now worked for 8 hours.
Been watching now and then what is going on via the "tail --follow=name provider.log" command.
Many times when there are "ERROR-render timeout"-messages there is a halt for 2 -6 minutes, during that time no number/size changes in the OchartsProvider-page. The longest waits I think come when there are two "ERROR-render timeout"-messages one after the other.

Planning to leave RPi on for the night and check in the morning if it has advanced to the Polish charts...

[wellenvogel02]

Many thanks for doing all the investigations.
Most probably there was really at least one corrupted chart.
Investigation on this is ongoing...
Did you still see some "AssembleLineGeometry..." log entries?