OpenCPN Beta 5.5.1114 (RC-2) Released

[bdbcat]

OpenCPN Beta 5.5.1114 Released

Here is OpenCPN v5.5.1114 (RC-2)

Windows
https://dl.cloudsmith.io/public/davi...1114_setup.exe

MacOS
https://dl.cloudsmith.io/public/davi....7d8b9f961.pkg

ubuntu/debian linux:
Available now in the OpenCPN Beta Ubuntu Launchpad repository

flatpak:
$flatpak update org.opencpn.OpenCPN//beta
$flatpak run org.opencpn.OpenCPN//beta

Source code
https://github.com/OpenCPN/OpenCPN
branch : master
tag : Beta_5.5.1114


Changelog:

1. Correct "puzzle piece" icon display in plugin manager.
2. Correct debian package dependency on opencpn-data
3. Improve current arrow sizing on HiDPI display, Windows.
4. Disable default Range Rings on measure tool points.
5. Correct fault adding connection, MacOS M1
6. Correct startup frame size logic for hi density displays.


Notes:
1. This is the second Release Candidate. What this means is this: If testing shows no "show-stoppers", then we simply change the Version indicator to "5.6.0", and publish as an official Release.


Good Luck, and Thanks for your help
Dave

[P_Dub]

With Windows 10 pro, it get install correctly, except that the need to switch off the antivirus of windows.
Many thanks.

[Aldebaran17]

I just figured on issue with the above version and Charts on MacOS:

The size of symbols (buoys and light houses) is ultra small using normal settings.


You can adjust that by"Chart Object Scale Factor". You really have to max that slider to get a reasonable size:



Then you start seeing, that the icons are made from bitmaps and look fuzzy.

More important: the top mark is placed with an offset to the corresponding buoy itself. And this is true for cardinal or lateral buoys, even for witties (BTW: Thanks for adding the top mark of the witties, sorry forgot the correct spelling in english of this dutch/german idiosyncrasy) or directional lights.

I just figured, that top marks and buoys are treated as two separate objects, which could be the reason for the offset in display.



Using MacOS 11.5.2 (Big Sur), OpenCPN 5.5.1114+7d8b9f961, oeSENC 4.3.0.0. and the current chart for German waters (Deutsche Gewässer 2021-44)

Best,

Manfred

[bcn]

That's how it looks for me on a macMini M1 (macOS 12.0.1).
What is the resolution of the screen you are using? And gets the screen width detected correctly? Our screen has a resolution of 3840x1600 (37,5").

Would agree that the top marks could go closer to the marker or buoy.

[Aldebaran17]

Originally Posted by bcn

That's how it looks for me on a macMini M1 (macOS 12.0.1).
What is the resolution of the screen you are using? And gets the screen width detected correctly? Our screen has a resolution of 3840x1600 (37,5").

Would agree that the top marks could go closer to the marker or buoy.

The resolution of the screen is 2560 x 1600, the built in screen of the MacBook Air.

I do not know where to check if OpneCPN detects the screen width correctly.

The only buoys with top marks in your screen shot are the whitties and their top mark is set off as well. You may see that more clearly, if you zoom in more.

Manfred

[CarCode]

Showing the top marks is broken since a long time. I see question marks instead.

Obviously other things are more importand then to show correct the charts.

[Karanga]

My system has OpenCPN running on a Windows laptop, plus a larger TV/monitor at the helm via HDMI cable.
I have found that if the monitor is already on when O starts, then the icons, depth figures, ship icons etc are all shrunk very small.
I am sure it has something to do with resolution auto-detection, but my work-around is to make sure the monitor is off when I start O.

[danmancs]

None of the non-standard plugins will run. EG watchdog.

[mgrouch]

There was an issue with OpenCPN plugin manager not being able to download plugins of raspberry pi OS armhf with arm64 kernel. It was erroneously detecting user space as arm64.
I can’t test it with this release because after installing it and updating catalog I see no updates available. Should I see any updates? All plugin versions are showing up as zero.
Many are grayed out.

[rooiedirk]

Using linux the topmarks do have the right position. The question marks are a CM93 thing. But my CM93 charts (Like most others I guess) are illegal cracked one's coming from a Russian hacker.

[verkerkbr]

It works well now on my AMD64 Linux Mint. However it took some time to get the Oesenc charts working.

There was a message that the date of the charts had expired and therefore did not longer work.
Plugin 0.9.042

After several tries, this message was gone and the charts worked.

Flatpak version 1114

Other OpenCPN version version 1115

Tidal info is also working on both OpenCPN versions.

No updates for the RPI systems. Follows later.


Bram

[houlejm]

On Raspberrypi O 5.5.11.15 no additionnal plugins show.
Had to activate settings button.

Active setting (default) was: ubuntu-gtk3-armhf:20.04
Had to change it to: raspbian-armhf:10


jm

[bdbcat]

mgrouch....
re:
"There was an issue with OpenCPN plugin manager not being able to download plugins of raspberry pi OS armhf with arm64 kernel. It was erroneously detecting user space as arm64."


In general, we are not supporting rPi with arm64.

Please try to run OCPN with debug logging.
$ opencpn -l debug.
Post the logfile.
Also, please post contents of /etc/os-release


Thanks
Dave

[bdbcat]

jm...
re:
"Active setting (default) was: ubuntu-gtk3-armhf:20.04
Had to change it to: raspbian-armhf:10"


And did these plugins load and work correctly?


Please post contents of /etc/os-release.


Thanks
Dave

[mgrouch]

Originally Posted by bdbcat

mgrouch....
re:
"There was an issue with OpenCPN plugin manager not being able to download plugins of raspberry pi OS armhf with arm64 kernel. It was erroneously detecting user space as arm64."


In general, we are not supporting rPi with arm64.

Please try to run OCPN with debug logging.
$ opencpn -l debug.
Post the logfile.
Also, please post contents of /etc/os-release


Thanks
Dave

Download manager should check if OpenCPN is compiled as armhf or arm64. If it’s armhf if should look for armhf plugins. If it’s compiled as arm64 it should look for arm64 plugins.
plenty of installations can have arm64 kernel and armhf user space programs.
It should not rely on kernel binary format. It should rely on how OpenCPN was compiled to look for plugins for that OpenCPN.