OpenCPN RC(2) 4.1.1317 Release

[Hakan]

More Grib_icons:
The Grib bar is not affected by "F5" night mode. This is just an observation, I'm not sure if it's practical at all to use Grips when on night mode?
Håkan

[Gilletarom]

Hello Dave,

Lenovo U41, W 8.1, O 411317 Jonough compiled yesterday

A surprising phenomenon. I un-installed carefully beta versions and version OpenCPN 0 1411317 that was installed instead of the stable version. (There is no stable version in my PC)
I cleaned everything with CCleaner.
I checked the OpenCPN folder in data, was gone.
I looked in the OpenCPN folder in the installation, it just remained 4 files detailed basemap.
I installed the latest version of OpenCPN 411,317, compiled yesterday by Jongough.

RUN O.
I go directly into the "Options / Plugins". There are only four original supplied plugins. It's normal.

BUT: The WMM and Chardonwloader plugins are already activated? I notice that the icon of WMM is not displayed in the toolbar. you must check the box in the preferences of WMM.

Is voluntary on your part? (Unless this is a compilation error Jongough?)

[CarCode]

Originally Posted by bdbcat

All...

re:
*Alarm sounds does not work, incl. AIS & anchor watch.
(Luckily very few targets to consider , though.)

Anyone else having trouble with alarm sounds?

You may test easily by setting an anchor watch with GPS input disabled. Alarm should sound, independent of ownship position relative to anchor watch point. Thus the anchor watch function acts as a GPS validity alarm as well.

Turn on the GPS, move the watch point close to the ship, and the alarm should stop.

Thanks
Dave

Mac OS X El Capitan (10.11.3), OpenCPN 4.1.1317
Go to Options->Ships->AIS Targets
Below to CPA/TCPA Alerts click onto "Test Alert Sound" --> Crash:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libwx_osx_cocoau_adv-3.0.0.3.0.dylib 0x0000000103e95a1d wxOSXAudioToolboxSoundData::SoundCompleted() + 25
1 libwx_osx_cocoau_adv-3.0.0.3.0.dylib 0x0000000103e959a8 wxOSXAudioToolboxSoundData::CompletionCallback(uns igned int, void*) + 20
2 com.apple.CoreFoundation 0x00007fff9001e4ac __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 12
3 com.apple.CoreFoundation 0x00007fff90010165 __CFRunLoopDoBlocks + 341
4 com.apple.CoreFoundation 0x00007fff9000f92e __CFRunLoopRun + 910
5 com.apple.CoreFoundation 0x00007fff9000f338 CFRunLoopRunSpecific + 296
6 com.apple.HIToolbox 0x00007fff8c225935 RunCurrentEventLoopInMode + 235
7 com.apple.HIToolbox 0x00007fff8c225677 ReceiveNextEventCommon + 184
8 com.apple.HIToolbox 0x00007fff8c2255af _BlockUntilNextEventMatchingListInModeWithFilter + 71
9 com.apple.AppKit 0x00007fff930120ee _DPSNextEvent + 1067
10 com.apple.AppKit 0x00007fff933de943 -[NSApplication _nextEventMatchingEventMask:untilDate:inMode:deque ue:] + 454
11 com.apple.AppKit 0x00007fff931c6d22 -[NSApplication _realDoModalLoopeek:] + 653
12 com.apple.AppKit 0x00007fff933ddde2 -[NSApplication runModalSession:] + 71
13 libwx_osx_cocoau_core-3.0.0.3.0.dylib 0x0000000104127ea4 wxGUIEventLoop:oDispatchTimeout(unsigned long) + 66
14 libwx_baseu-3.0.0.3.0.dylib 0x0000000104742541 wxCFEventLoop:ispatchTimeout(unsigned long) + 37
15 libwx_baseu-3.0.0.3.0.dylib 0x000000010474259f wxCFEventLoop::OSXDoRun() + 65
16 libwx_osx_cocoau_core-3.0.0.3.0.dylib 0x0000000104127ce5 wxModalEventLoop::OSXDoRun() + 189
17 libwx_baseu-3.0.0.3.0.dylib 0x0000000104742c44 wxCFEventLoop:oRun() + 50
18 libwx_baseu-3.0.0.3.0.dylib 0x00000001046bd7b1 wxEventLoopBase::Run() + 83
19 libwx_osx_cocoau_core-3.0.0.3.0.dylib 0x0000000104093955 wxDialog::ShowModal() + 93
20 org.opencpn 0x00000001031e1530 MyFrame:oOptionsDialog() + 1584
21 org.opencpn 0x00000001031da53a MyFrame:oSettings() + 26
22 org.opencpn 0x00000001031bf6b3 MyFrame::OnToolLeftClick(wxCommandEvent&) + 195

BTW same with wxWidgets version 3.1.0

Gerhard

[CarCode]

Originally Posted by Gilletarom

BUT: The WMM and Chardonwloader plugins are already activated? I notice that the icon of WMM is not displayed in the toolbar. you must check the box in the preferences of WMM.

Is voluntary on your part? (Unless this is a compilation error Jongough?)

See http://www.cruisersforum.com/forums/...ml#post2021683
The same problem but was fixed meanwhile.

Gerhard

[LeaseOnLife]

Originally Posted by bdbcat

@alexej-osm...

re:
Crashes on OSM maps with O4.1.1317

I downloaded and tested a map bundle, and found that OCPN did, indeed, crash often. The responsibility is shared.

...snip...

I have corrected OCPN 4.1 to allow for this situation. And now the maps display fine without trouble. I note that starting the line offset table at line 1 will probably introduce a one-pixel error in latitude georeferencing for these maps at native scale. So you may wish to modify your .KAP generation code.

Thanks for the charts.
Dave

Thanks to both ! I do like the OSM maps, not necessarily for nav on water, but planning, and I do like the extra detail on land.

One issue I have:
When I only have the OSM Carib bundle in a separate folder and chart group, I can see all charts in that bundle, shown as outlines in screenshot 1. When I add the Western Med, some of the charts of the Carib have disappeared, see screenshot 2. It gets worse when adding the Channel (screenshot 3), or all bundles, screenshot 4.

Dirk

[BlueShip]

@LeaseOnLife

I have the same problem with the bundles of OSM and also with own bundles. I thought the problem was solved by a clean install from scratch. But it is not.

Regards
Martin

[bdbcat]

@Blueship/LeaseOnLife....

I have only one OSM bundle downloaded, and stuck on low bandwidth right now.

However, I suspect the problem is chart naming collision. During chart importation, O will discard older charts with the same name as a newer version.

As a test, please try to put each bundle into a separate directory, and see how that goes.

Thanks
Dave

[ChuckSK]

The grib particle map causes frequent crashes.



chuck

[BlueShip]

@Dave

Each bundle was in a separate folder for the test.

Regards
Martin

[LeaseOnLife]

Originally Posted by bdbcat

@Blueship/LeaseOnLife....

I have only one OSM bundle downloaded, and stuck on low bandwidth right now.

However, I suspect the problem is chart naming collision. During chart importation, O will discard older charts with the same name as a newer version.

As a test, please try to put each bundle into a separate directory, and see how that goes.

Thanks
Dave

Dave

each bundle was/is in a separate sub-directory. The chart group contains all OSM sub-dirs. Your idea with naming collisions makes sense but there is an issue: files with same filename from other directories being expunged.

I 'fixed' it differently: I batch-renamed each kap file with a prefix (used the sub-dir name), then it works. (OCPN doesn't use the bsb files which now contain an invalid reference, I deleted all OSM bsb files.)

@alexej-osm... This should be fixed during packaging the chart bundles.

Dirk

[rgleason]

ChuckSK

The grib particle map causes frequent crashes.

Chuck I thought you were the one who fixed that problem about 3-4 months ago?
Maybe it was Sean... In any case we know that on low powered machines you cannot run grib particle map, it is cpu intensive. In VS it appears to be a problem too. There was excellent progress made some time ago, to remove the hangups, and it works much better than before, but perhaps there is more work to do. Perhaps you can find & solve more problems. Previous work made my laptop play particles very well, but slower machines it still overwhelmed...
PS: Particle maps still works well on the same laptop.

[ChuckSK]

Originally Posted by ChuckSK

The grib particle map causes frequent crashes.

chuck

This appears to be an IDL problem.

[bdbcat]

Chuck...

What is an "IDL problem" ?

Can you post a GRIB file that causes particle crashes?

Thanks
Dave

[ChuckSK]

Originally Posted by bdbcat

Chuck...

What is an "IDL problem" ?

Can you post a GRIB file that causes particle crashes?

Thanks
Dave

Dave

IDL == International Date Line.

I saw some crashes that did not involve the IDL, so I'm not sure about that connection. GRIBs that cross the IDL do seem to crash sooner.

The actual grib file is too large to post so here is the zyGrib request and a screen shot of the particle map that crashed.





chuck

[seandepagnier]

chuck,

Does the grib have to be so large to cause a crash?