OpenCPN Beta test 4.1.1108 Release

[transmitterdan]

Originally Posted by rgleason

Just to be sure, I uninstalled Opencpn v4.1.1108 and reinstalled it (the one TDan provided) with a fresh install (not parallel).
Tested and it failed again!
Then to be doubly sure I disconnected from the internet. Disabled Norton Firewall and Antivirus and tried it again. It failed three times.

To be perfectly clear, I am using Win7 on a Dell Inspiron 15 XPS Laptop L502 and it is nothing unusual. I don't know why it would not work on my machine and work on others.

I am going back to the sandbox to play in a stable environment.

Rick,

You have lots of plugins. I'm guessing one of them is responsible. It could also be the OpenGL drivers. But the base install with the in-built plugins works for me without any issues.

[rgleason]

In VDR_pi thread I just saw that Pavel uses the branch "Packaging" to compile the lastest VDR. Changed to that branch and compiled with opencpn.lib dated Nov 20,2015.
Then installed that VDR_pi into the TDan version of Opencpn [very current].

Then tried to run Harmut merkermeer ... [a big file] and nmea works! --Along the way I also rebuilt the charts and deleted the Opengl cache which was small. It is currently using Opengl.

Now I don't know why TDan python Nmea Server did not work earlier, but I will give that a try next.

Grr 1.5 days and diverted others too. Sorry, if I had only remembered that Pavel used "packaging" branch for VDR_pi!

Maybe I won't go back to the sandbox...yet.

PS: I would really like a slider in VDR, so that we can fast forward or select where to play. It would be more useful for testing.

[rgleason]

Ok TDan's Nmea Server:
"python VDRServer1.py Harmut-Netherlands-Markermeer-Wind-AIS.txt 127.0.0.1 2947 .033"
works.

I am going to upload to Opencpn Beta File Thingie, the new compile of VDR_pi in case someone else has a problem. {No not anymore]
I believe that was my problem with running nmea, but I can't understand why TDan's server is working now....and not before.

.. Just downloaded and installed the beta vdr_pi-0.4-win32 from opencpn.org and ran it. Now it works! What was the problem? Is there a cache that needs to be cleared somewhere? This is ridiculous. I don't think it was the charts, or opengl...???

[NahanniV]

Originally Posted by NahanniV

I have not been building on ARM for a while.

Tonight I built the latest and there was one big problem:

With OpenGL and texture compression caching turned on.

Raster charts are initially displayed OK, but then they are progressively blurred in rectangular sections until the whole chart is blurry.

Here is a video that illustrates the problem.
Sorry, the whole thing is a bit blurry, but I think you get the picture.

Cheers,
JM.

[Hakan]

Originally Posted by transmitterdan

Håkan,

I have tried to duplicate this issue but cannot. The memory usage fluctuates up and down based on the displayed chart region and scale but never "runs away". I even wrote a VDR player that outputs the west coast of Sweden VDR file via UDP. What type of data are you receiving by UDP? Can you make a VDR file that I can test with? Perhaps it is data specific.

Dan..
I've one instance of OCPN, portable, playing the VDR and transmit that out to network as UDP. The standard OCPN instance is the UDP receiver and it's at the receiver memory is built up, not the sender.
The VDR file is not important, my refereed example was using the Hakefjord.txt.
So; sender use UDP output by 192.168.x.x port 10110 (No input!)
receiver use UDP input by 192.168.x.x port 10110(No output!, no filter)
May I guess some UDP multiplexer built up????

Håkan

[rgleason]

Hakan, just a stab at it... Was "Accept only sentences" for input or "Transmit only sentences" checked for output? You had no filters? Control checksum was on of course.

[Hakan]

Rick..
Yes! to all. See my connection settings here: http://www.cruisersforum.com/forums/...ml#post1966789
Håkan

[Ptizef]

Hi All

Testing the very last Git

- The "grey zone" or "no chart displayed zone" with CM93 is fixed . Thanks

- I get now a crash when moving ( dragging) CM93

Process : Zoom out to a large scale then move the chart quickly
This is easily reproducible with Vista and W10.
Find attached the crash's call stacks


Jean Pierre

[transmitterdan]

Originally Posted by Hakan

Dan..
I've one instance of OCPN, portable, playing the VDR and transmit that out to network as UDP. The standard OCPN instance is the UDP receiver and it's at the receiver memory is built up, not the sender.
The VDR file is not important, my refereed example was using the Hakefjord.txt.
So; sender use UDP output by 192.168.x.x port 10110 (No input!)
receiver use UDP input by 192.168.x.x port 10110(No output!, no filter)
May I guess some UDP multiplexer built up????

Håkan

Håkan,

If you slow down the VDR by the slider does that change anything?

I don't think it is a UDP multiplexer problem. I have tried to really abuse the multiplexer with both TCP and UDP streams that send data many times faster than "real time" but it hasn't broken yet. Maybe VDR is a lot faster than what I am testing so you might try slowing down the data to see if that changes the problem.

[transmitterdan]

Originally Posted by Ptizef

Hi All

Testing the very last Git

- The "grey zone" or "no chart displayed zone" with CM93 is fixed . Thanks

- I get now a crash when moving ( dragging) CM93

Glad someone else found this too. It is in GL tesselation system where it hits a null pointer. Haven't been able to locate it exactly yet but this one should be easily fixable.

[rgleason]

Jean Pierre, attachments?

Process : Zoom out to a large scale then move the chart quickly
This is easily reproducible with Vista and W10.
Find attached the crash's call stacks

[bdbcat]

Dan/JP...

Regarding cm93 crash on dragging...

I find that it crashes most repeatably when you encounter the IDL, Lon 180. From either direction.

Turns out not to be a trivial problem. The MESA GLU library is more tolerant of self-intersecting region contours than the MSW GLU library. In fact, the MSW library crashes internally, and there is not much we can do about that.

Solution: We will need to port the Mesa GLU library to MSW and include it in our source tree. Not the best use of resources, but we really have no choice.

We already have a subset of Mesa GLU in our tree for Arm builds, so we will not be starting from scratch, anyway....

Working on that now.

Thanks
Dave

[Hakan]

Originally Posted by transmitterdan

Håkan,

If you slow down the VDR by the slider does that change anything?

Dan
I use to have the VDR slider on ~15-20%, that equals around 700 B/s.
Any other test you imagine I could do?
Thanks
Håkan

[did-g]

Originally Posted by bdbcat

Dan/JP...

Regarding cm93 crash on dragging...

I find that it crashes most repeatably when you encounter the IDL, Lon 180. From either direction.

Turns out not to be a trivial problem. The MESA GLU library is more tolerant of self-intersecting region contours than the MSW GLU library. In fact, the MSW library crashes internally, and there is not much we can do about that.

Solution: We will need to port the Mesa GLU library to MSW and include it in our source tree. Not the best use of resources, but we really have no choice.

We already have a subset of Mesa GLU in our tree for Arm builds, so we will not be starting from scratch, anyway....

Working on that now.

Thanks
Dave

Hi,
Have you looked at https://github.com/memononen/libtess2 ?

[seandepagnier]

Originally Posted by bdbcat

Turns out not to be a trivial problem. The MESA GLU library is more tolerant of self-intersecting region contours than the MSW GLU library. In fact, the MSW library crashes internally, and there is not much we can do about that.

The output of the tesselator seems to include these self-intersecting contours. In theory it should not, so I will try to investigate closely.

Solution: We will need to port the Mesa GLU library to MSW and include it in our source tree. Not the best use of resources, but we really have no choice.

If the results are different on different platforms, then we need this anyway to ensure the same results. This includes for vector charts and ghhs.

Originally Posted by did-g

Hi,
Have you looked at https://github.com/memononen/libtess2 ?

I took a quick look... and it seems very interesting. I wanted to do something about the dynamic memory allocation since it kills performance. If it really is 15-20 faster as it claims, then we should definitely be using it.