OpenCPN Version 5 Released

[bdbcat]

cagney...


re:
"I did not think that O looked in /usr/local/ when started from /usr/bin/opencpn. Is this new or have I missed something?"


This is somewhat new, at least in O5. I think the idea was to somewhat mimic the action and search order of default linux loader. Has caught me out, as well.


Dave

[cagney]

Dave

Now it works........
I can live with the new way, now that I know.......
Hopefully I don't have to copy a lot of plugins to /usr/local/ anymore when testing o builds from git.

Thanks
Thomas

[Gilletarom]

Hello Dave,


A small problem leads to many identical consequences.

The problem is in the default settings for CM93 charts.
The cursor in the "Options / Charts / Vector chart" is too far left. And if users, new or old, do not push this slider to the right, then text, fire and other display items in the "Chart panel options" have no effect. For example, even by checking the "Show text" box, with the CM93, and with the cursor too far to the left, the texts are not displayed.

As a result, several French users began to criticize the new version negatively.


Gilletarom.

[CarCode]

Originally Posted by Gilletarom

As a result, several French users began to criticize the new version negatively.

So does German users, too many bugs...

[bdbcat]

Gilletarom....


The slider should retain the value from previous OCPN loads. The default value for new installs is 0.


If one installs from absolute zero, is the slider other than 0? If so, then that is a bug.


Dave

[bdbcat]

Gilletarom....


You may try this: Delete or rename OCPN .ini file. Start OCPN. The .ini file is recreated, as though this was an initial install. You will see that all slider default values are "0".


Probably the users have adjusted the sliders, not knowing what they are, and then forgot about it.


Thanks
Dave

[bcn]

Originally Posted by CarCode

So does German users, too many bugs...

Where please Gerhard?

Some hick-ups reported at SegelnForum AND solutions from German users!

[rszemeti]

Originally Posted by bdbcat

rszemeti....


OK, another tack.


Will you run:


$/usr/bin/oeserverd -h


and post results.


Thanks
Dave

I get:

e4:22B34D2C
e4:823DDBD3

[bdbcat]

rszemeti....


One more piece of data required: Your UserKey, please. PM if you like.


But don't worry about security, it is useless to anyone else.


Thanks
Dave

[rszemeti]

Here you go:

lPAr-cAOY-gic+-uDAZ-eM8+-fw

[bdbcat]

rszemeti...
OK, thanks for the info. That all checks out, and so the problem does not relate to fingerprint or UserKey.


I worked with a similar rPI device today, and found that OCPN tends to require a good stable power supply when the CPU is fully loaded, as when reading charts. I tried several from my parts bin. All labeled 2A, but clearly different performance. The inferior ones caused OCPN to crash at odd times, never repeatably. So, that is a possibility you may want to investigate.


Also, I would like to know clearly:
Is your error repeatable? Always does the same thing? If so, can you describe exactly which charts and location you are looking at?
Thanks
Dave

[Moo]

Repeatable crash on W10 caused by the ObjSearch plugin I think. At least when that plugin is disabled the crash doesn't occur.

Right click and change chart group from a raster set to CM93 results in a crash.

Log file attached. Change doc extension to txt or log

Also I think this is a regression but the arrows displayed for wave direction, when proportional arrows are selected, in the GRIB plugin turn into double headed monsters.

[rszemeti]

Originally Posted by bdbcat

rszemeti...
OK, thanks for the info. That all checks out, and so the problem does not relate to fingerprint or UserKey.


I worked with a similar rPI device today, and found that OCPN tends to require a good stable power supply when the CPU is fully loaded, as when reading charts. I tried several from my parts bin. All labeled 2A, but clearly different performance. The inferior ones caused OCPN to crash at odd times, never repeatably. So, that is a possibility you may want to investigate.


Also, I would like to know clearly:
Is your error repeatable? Always does the same thing? If so, can you describe exactly which charts and location you are looking at?
Thanks
Dave

Hi Dave,



So I tried connecting a 2200uF cap across the PSU and no change, I would expect a general kernel fault or somethign a bit more random than a single process crashing from a peak load on the PSU dipping the PSU, I can't see any change on the multimeter worth mentioning, and with the cap, the meter woudl be fast enough to see a drop for sure.



I'm using the UK charts and not looking at anything in particular, it crashes long before they are shown. If I run via GDB, I can repeatedly get the popup message about oeserverd not available at {}. not run via gdb it just crashes with the "bus error" message.


it is very repeatable, in exactly the same way every time. Basic screen, base map displayed, left menu appears, bottom RH menu box appears and then crashes before the chart outlines are shown.


The only non-standard part is I have copied the SG Lock library from /usr/lib/opencpn to /usr/lib so that oeserverd can now find it.

[bdbcat]

rszemeti...
re:

"If I run via GDB, I can repeatedly get the popup message about oeserverd not available at {}."


That is new news to me. If the server won't start, then all sorts of trouble happens downstream.
I would like to see a logfile from a recent run, please.
Thanks
Dave

[bcn]

Originally Posted by rszemeti

I'm using the UK charts and not looking at anything in particular, it crashes long before they are shown.

Can you contact us perhaps at o-charts as well? We would like to crosscheck a detail.

Thanks

Hubert