OpenCPN RC 4.1.1301 Release

[transmitterdan]

Originally Posted by wdkester

Windows 7, and I haven't been rebooting the OS; but when I restart opencpn, it restarts normally. But obviously something isn't normal. Something is being remembered that damages Export.

I agree with you that it's related to some persistent storage somewhere. I suspect it is wx and/or the OS libraries that wx calls but just a wild guess. I tried searching the registry for an obvious entry but could not find any.

[bdbcat]

wdkester...

Do you by chance have Options->UserInterface->EnableTabletScaledGraphicsInterface checked?

Thanks
Dave

[bdbcat]

wdkester...

I built a custom version of OCPN for you to test.

https://www.dropbox.com/s/397gnlh73x...encpn.exe?dl=0

This is just the .exe application, not the full installer. Simply copy the opencpn.exe over the top of your existing one, wherever it is.

This one will open a small text window, and show some output as you try the export function. Pix attached.

Good Luck
Dave

[wdkester]

Originally Posted by bdbcat

wdkester...

Do you by chance have Options->UserInterface->EnableTabletScaledGraphicsInterface checked?

Thanks
Dave

Yes. It must be from some experimenting. This is a 17" laptop. Both sliders are 0.

[bdbcat]

wdkester...

Any difference if you turn off Options->UserInterface->EnableTabletScaledGraphicsInterface?

Dave

[wdkester]

Originally Posted by bdbcat

wdkester...

I built a custom version of OCPN for you to test.

https://www.dropbox.com/s/397gnlh73x...encpn.exe?dl=0

This is just the .exe application, not the full installer. Simply copy the opencpn.exe over the top of your existing one, wherever it is.

This one will open a small text window, and show some output as you try the export function. Pix attached.

Good Luck
Dave

I downloaded your test vers before I saw "try it without EnableTabletScaledGraphicsInterface

Ther new vers works

[bdbcat]

wdkester...

OK, that's great. I think I understand what is going on now.

For everyone else, you may try to export a waypoint with Options->UserInterface->EnableTabletScaledGraphicsInterface set TRUE, and see what happens. Might crash, might not.

Thanks
Dave

[Hakan]

Dave
Win10, yesterdays fetch.
I exported a waypoint with or without checked "EnableTabletScaledGraphicsInterfac.
No difference and thus no crash.
Håkan

[did-g]

hi,

If the chart thumbnail overlaps the selected piano entry then ocpn enters in an endless and unrecoverable loop:
eg
either with :
a small main window < 200
a vertical toolbar on the left
some charts (12372_9.KAP has a 720 / 212 thumbnail!)

- rollover a piano entry in single chart mode
-> display an overlapping thumbnail
-> trigger a mouse leave event.
-> hide thumbnail
-> trigger a mouse enter event,
loop

CPU at 100% and you have to kill ocpn.

[rgleason]

Would like some feedback on abbreviated version. Sections to remove.
Opencpn 4.1.1108 Documentation - Page 11 - Cruisers & Sailing Forums

[bobofthenorth]

Originally Posted by did-g

It's a serial out? Is it configured as out only? What its speed?

If there's no load it's either a timeout or a serialization on a lock.

From my quick reading of the code it could be you're pushing too much to the serial port and via m_outCritical lock your serial port is slowing down OCPN to its speed.
On the other hand it's that or losing sentences.

UPDATE:
This post contained the germ of the idea which fixed the slow behavior which I was seeing. To recap my situation: GPS input from a Garmin mushroom through a prolific USB converter and output to AP through a 2nd prolific converter. I am unable to set the output port to an "only talker" port so I filtered out all input sentences and that fixed the slow behaviour.

The reasons for this happening are WAY beyond my pay grade but it does seem to me that the software should be able to handle this situation. I may be in a small subset of users who currently interface the software to an AP but if that facility is available we should expect it to be used and the software should not appear to hang as soon as the AP is engaged IMHO.

[Littlechay]

Crash:

Just anchored for the evening. Decided to check the forecast; zoomed out and clicked the GRIB plugin button and got a crash.

All that days track disappeared and something strange happened to the logbook Koni data for that day. I can see it in the logbook but it's not there when I export.

I could not find any evidence of the days track in the Navobj.xml files.

I was able to rebuild the track as I have all my NMEA data logged so not a big deal for me, but potentially a PITA.

Nothing in the crashdump, but there is s screen shot. Attached.

Chris

[transmitterdan]

Chris,

Do you have the OpenCPN.log leading up to the crash? If so post it here.

[Littlechay]

Originally Posted by transmitterdan

Chris,

Do you have the OpenCPN.log leading up to the crash? If so post it here.

Here it is.. new via my phone which at the moment is definitely on the edge so I hope that it holds up while it uploads.

If you look in the log at the end of 17th Jan where it goes into 12:07/8 AM on the 18th you'll see where I zoomed out and a larger chart area loaded and then you'll see the restart.

Remove dummy extension and unzip as usual

Cheers

Chris

[jongough]

Chris,
If you haven't restarted after the crash you should find a navobj.xml.changes file in the same directory as navobj.xml and all its backups. The changes file contains all the changed information since the last startup. If OCPN closes down cleanly the navobj.xml file will contain all the information, if not it contains what was in it at the last start.

When OCPN starts up it reads and implements all the information in the navobj.xml file, then it looks for, reads AND deletes the navobj.xml.changes file (so you only get one go at this). Having read the navobj.xml.changes file it then applies all changes found to, effectively, bring OCPN back up to the point it crashed. If you crash now there 'should' be an updated navobj.xml reflecting the old navobj.xml plus the outcome of all the changes.

The issue comes if you crash after the navobj.cml.changes file is read BUT before the new navobj.xml file is created. So, if you have this type of crash it may be worth copying the navobj.xml.changes file BEFORE restarting OCPN, just in case....

Jon