Beta Test / Technical

[Per Appel]

Hi.

I just installed ver. 3.3.1117. Great feature to request grib files directly from the program But.
when I try to open the grib file, the program crash.
I am running Win8 pro.
Best regards
Per

[rgleason]

Try several freshly downloaded grib files. Use different types of files too. Saildocs should work, I've not had a problem with fresh gribs, but you can also try old ones in your file.

[kirribilli47]

Hello
I run beta 3.3.1117 on ubuntu 13.10/64 and have a graphic issue. Evertime I open settings meny, the menu on screen grows a little bigger. It seems a litte strage at bottom of screen also but it dont change in size.

I have also noticed if you start opencpn in fullscreen, sometimes status bar is invicible.

Maybe it is some bug and can help you in testing.

Magnus

[cagney]

Originally Posted by kirribilli47

Hello
I run beta 3.3.1117 on ubuntu 13.10/64 and have a graphic issue. Evertime I open settings meny, the menu on screen grows a little bigger. It seems a litte strage at bottom of screen also but it dont change in size.

I have also noticed if you start opencpn in fullscreen, sometimes status bar is invicible.

Maybe it is some bug and can help you in testing.

Magnus

I think this is a problem with the "Unity" desktop in Ubuntu. I'm running the same setup as you, but using KDE, and have never had this problem.

Thomas

[Neddy]

Hi Would like to use Open CPN for a electronic cruising guide. Have been looking for the folder that contain text I write in dialog box when entering a mark on the chart but have had no luck so far. Any change you can give a link to it.

[nohal]

Neddy...
Is there anything preventing you from just exporting the data from the Route manager? The internal format used to store the waypoints/routes/tracks is also GPX, so the difference if you use that file (RTFM looking for navobj.xml) or export the objects to a file is none.
BTW, if you missed the 3.2 release, it's probably time to upgrade

Pavel

[muttnik]

Hello,

Apparent bug. (Testing with the latest git).

If you edit a network datastream and change its address or port, a new datastream is created with the new parameters but the old one isn't shut down. For example:
* Create an input nmea datastream (from something you actually have data coming from)
* Create a UDP datastream and click "output on this port"
* Open the NMEA debug window
If all is well you should see the green input data and blue lines showing the data being output over UDP

Now open the connections window again and change the address (and/or port) of the UDP connection and hit apply. There is no mention of the old address (and/or port) now. However, you now see data being sent out to both the old *and* new address (/port). If you now remove this connection entirely, data will continue to be sent to the original address (/port). This is not a problem if you remove then add a connection, only if you edit the address or port of an existing connection.

I think this may be down to the way you test whether something is a new connection or an existing one. Specifically in options.cpp:
DataStream *pds_existing = g_pMUX->FindStream( cp->GetDSPort() );
if(pds_existing)
g_pMUX->StopAndRemoveStream( pds_existing );

GetDSPort returns the tuple proto/address/port which obviously won't exist in the list if you've just changed one of those things, so you never stop and remove the existing datastream.

Of course I could be completely wrong about that because I only bluff C++ and it's all quite a lot of code to take in and TBH I've just latched onto the first thing which seemed obvious :-)

[Hakan]

Originally Posted by muttnik

Hello,

Apparent bug. (Testing with the latest git).

If you edit a network datastream and change its address or port, a new datastream is created with the new parameters but the old one isn't shut down...............

Hi, just to confirm muttnik's experience. I've once seen the same thing while editing an existing port. Shut down O and run again of course solved it but it was a coincident that I saw it. I happened to have the NMEA window open and saw the traffic increase.

[muttnik]

Just to add that this isn't a problem for me and I doubt that many people regularly change data addresses in such a way that this will cause noticeable problems: Just thought I'd mention it as it cropped up when testing some other code changes. I should probably have used flyspray shouldn't I? hmm...I'm still learning this stuff.

Edit: Done. FS#1281. Sorry: will try not to clutter this list like this again :-)

[muttnik]

Can anyone think of a good reason why you wouldn't want to disable nagle algorithm on an outgoing OpenCPN TCP data connection? Should be a trivial change (which I'm happy to do) and remove ack delay from sentence delivery to clients.

[rgleason]

I wish I was able to respond to Muttnik intelligently... reason for this post is the new behavior of OpenCPN 3.3.1303 finding all plugins in subdirectories under the plugin directory! I had been storing older plugins in a subdirectory without Opencpn recognizing them, now I have many historic plugins loading from that directory.
Is there a way to change this behavior or must I change how I work?

Thanks.

[rgleason]

Cleaned up my mess and put *.doc on unused.

[muttnik]

Originally Posted by rgleason

I wish I was able to respond to Muttnik intelligently.

Heh. No need. Did some timing tests. In practical terms the current set-up isn't a problem anyone will care about. The worst case is really where you've got a fast data rate and the *receiving* system for an OpenCPN tcp datastream is windows Your data may be delayed up to about 200ms unless we disable the Nagle Algorithm (which is a method of conserving network bandwidth by bunching up small writes) on the outgoing socket. The problem is less obvious with MacOS or Linux receivers, not because they're better than windows: actually it's because their network stacks seem to be a little less bandwidth-conservative.

Patch now submitted to (hopefully) smooth things out, not that anyone will notice a difference :-)

[rgleason]

Thanks for your contributions and expertize!

[bdbcat]

rgleason...

Sorry for failing to document the new (3.3.1303) PlugIn finder algorithm. This came to pass as part of the preparation for S63 chart support. I have not heard that anyone else has noticed, except you.

What we are trying to do is have a place for an executable "helper" application to live, alongside the PlugIn in its own subdirectory. So the S63 PlugIn dir structure will look like this:

Plugins/s63_pi (directory)
Plugins/s63_pi/s63_pi.dll
Plugins/s63_pi/OCPNsenc.exe (new helper app)

This structure obtains only on Windows and Mac. In linux, we put the helper OCPNsenc in /usr/local/bin like any other application binary.

I wonder if we should change that algorithm again to do this:
1. Start looking/loading PlugIns for {}/Plugins. Load all found.
2. Then look deeper, into subdirectories of {}/PlugIns. Do not load any duplicates, that is, PlugIns with the same base name as one already loaded.

Can anyone think of a reason why this would
a. be better, or
b. not work in their installation?

Thanks
Dave