OpenCPN Version 4.0 Released

[nohal]

Pjotr...
This really is a non issue. How much time do you think it deserves? Isn't that time better spent elsewhere? And yes, we can implement files storing the pid, check them, check if the process still runs and behave better.
Send a pull request implementing it and I will be happy to merge it.

Pavel


Sent from my iPhone using Cruisers Sailing Forum

[RhythmDoctor]

Originally Posted by PjotrC

...I often run one instance underway, and a separate one for planning, not to interfere with track recording, AIS watch etc. So, with 4.0 I start the regular, and then a portable for planning. If, God forbid, the regular crashes, I cannot restart it, without closing down first the portable.

The workaround is SO SIMPLE. Just keep and run two separate portable instances. Then you can restart the two instances in any order if one crashes. To save space, put your charts in a single directory and point both instances to that directory. In the most recent version, I also put my SENC files in a single directory and modify the .ini file to point to that. Using a unified SENC directory greatly reduces the delays in building those files.

We can create endless complexity asking Dave to anticipate every single way we abuse the program. If he wants to change this, fine. But when there's such a simple workaround, why bother?

Back in the days of 2.5, I used to also run the same .exe twice. I had a batch file that copied different versions of the .ini file to the master directory so each instance would start up with different parameters. I thought it was a kludge, and was glad to set up two portable directories when portable mode was made available.

Originally Posted by PjotrC

So, with 4.0 I start the regular, and then a portable for planning....But, I mostly use 2.5 for planning, which has no portable mode...

Is there a reason you can't do planning in portable mode with a more recent version? And how do you use 2.5 for planning in portable mode?

[PjotrC]

Originally Posted by RhythmDoctor

We can create endless complexity asking Dave to anticipate every single way we abuse the program. If he wants to change this, fine. But when there's such a simple workaround, why bother?

I will manage, no problem, and no need to raise alarms or take quick action.

But I still think the mechanism used to prevent data corruption here is perhaps not the best, as it prevents people from doing things which are perfectly safe, still allowing to act erroneously. Not simple to document for the casual user, either.

Just a thing to note, I or someone else will perhaps see to it one day... not a major issue.

Originally Posted by RhythmDoctor

Is there a reason you can't do planning in portable mode with a more recent version

Yes, I often use a custom version of 2.5.1318 for route-synchronized grib viewing. Not in portable mode.

My original post was not a request for a change that I need now, but just an expression of a certain concern...

Fair winds to all

[bdbcat]

Wrong....

Back to the chroot linux environment:

LinuxDeploy is VERY fragile. Broken installs leave a lot of cruft to be cleaned up manually, which requires a complete restart of the install scripts. Total download required to build O natively is about 2 GB.
Best used on a hardline connection.

And rooting a tablet is really still not for the faint of heart. I demured trying it on my main book reader tablet, since it has no recovery image loaded, and I would not like it bricked while cruising in the Bahamas as I am now. So I rooted an older generic tablet after many different methods tried.

But whatever...

After 3 days of downloading on a soft Wifi connection, I have...

1. Run LinuxDeploy.
2. Got bVNCFree from the Play store.
3. Got a nice linux tablet running. So far so good.

3. Built OCPN 4 from scratch on the target. No issues.

4. Run OCPN4 from the bVNC Viewer, and remotely using xtightvncviewer.

5. And (Tada!) it runs just fine in no-OpenGL mode. With a network UDP connection for NMEA data, ownship shows up just fine. Zoom, pan, AIS, dialogs, whatever. All works fine.

So, I guess you will have to tell us all again (in simple words, please) what your observed problem is with O4 in chroot environment.

Thanks
Dave

[Wrong]

Originally Posted by bdbcat

Wrong....

Back to the chroot linux environment:

LinuxDeploy is VERY fragile. Broken installs leave a lot of cruft to be cleaned up manually, which requires a complete restart of the install scripts. Total download required to build O natively is about 2 GB.
Best used on a hardline connection.

And rooting a tablet is really still not for the faint of heart. I demured trying it on my main book reader tablet, since it has no recovery image loaded, and I would not like it bricked while cruising in the Bahamas as I am now. So I rooted an older generic tablet after many different methods tried.

But whatever...

After 3 days of downloading on a soft Wifi connection, I have...

1. Run LinuxDeploy.
2. Got bVNCFree from the Play store.
3. Got a nice linux tablet running. So far so good.

3. Built OCPN 4 from scratch on the target. No issues.

4. Run OCPN4 from the bVNC Viewer, and remotely using xtightvncviewer.

5. And (Tada!) it runs just fine in no-OpenGL mode. With a network UDP connection for NMEA data, ownship shows up just fine. Zoom, pan, AIS, dialogs, whatever. All works fine.

So, I guess you will have to tell us all again (in simple words, please) what your observed problem is with O4 in chroot environment.

Thanks
Dave

Gee. I guess locating a rooting method for any old 'generic' android tablet could be a tall order indeed. So, the lesson here may be for folks to buy new or good used, name brand android tablets likely to have rooting methods on XDA Developers.

Anyway, glad you got it going in spite of a 'soft' internet connection. Doing anything over one of those can induce at least a mild case of insanity. Thanks for persisting.

Before I go to the trouble of removing 3.6.1618, compiling and installing O4.

1.) Did you import a .gpx into O?
2.) Did you immediately enable OpenGL?
3.) Did you use the swx file I mentioned, or did OpenGL work with the standard dependencies?
4.) What happens if you disable OpenGL? Do you still see the ownship, waypoints and marks?
5.) What if you stop & restart O in the different modes after changing from one to the other?
5.) With text enabled in non-OpenGL mode, do you still see text in OpenGL mode after it's enabled? If not, this is why I question the reliability of what is and may not appear in OpenGL mode.

Just noticed you have only run O in 'non-OpenGL' mode.

Does glxgears run in a terminal with O installed with standard dependencies? If not, to have OpenGL in android install libgl1-mesa-swx11 using aptitude and answer yes to the proposed solution.

Then try the steps I've enumerated above.

Hope you're having fun in the Bahamas.

[bdbcat]

Wrong...

I'm done with experimenting.
Please tell me an exact recipe that does not work for you.

Dave

[Wrong]

Originally Posted by bdbcat

Wrong...

I'm done with experimenting.
Please tell me an exact recipe that does not work for you.

Dave

Sorry that the steps giving rise to the display problem related to ownship, marks and waypoints appear opaque to you. They're in my last post. Try them or not, it's your call.

[bcn]

Originally Posted by bdbcat

Wrong....


5. And (Tada!) it runs just fine in no-OpenGL mode.

Thanks
Dave

Wrong:

Just noticed you have only run O in 'non-OpenGL' mode.

[RhythmDoctor]

Originally Posted by PjotrC

...Yes, I often use a custom version of 2.5.1318 for route-synchronized grib viewing. Not in portable mode.

My original post was not a request for a change that I need now, but just an expression of a certain concern...

Oh, now I get it. Sorry for being a little slow. As a non-programmer, sometimes I forget that you guys have customized your own versions that you would like to keep using.

It sounds to me like you could get along just fine by running your customized v2.5 in non-portable mode, and also O4 in portable mode. Then, if one should crash, you can immediately re-launch, since O4 portable will re-launch with other instance running, and 2.5 doesn't check, so it would re-launch also. Just my suggestion, though.

FWIW, learned this lesson the hard way. I started out running one instance of O in standard mode and a second instance in portable. The standard instance crashed while I was underway, I went to re-launch, and it wouldn't because the portable one was running. After that I created a second portable installation on the same SD card, specifically so that I could re-launch either one immediately in the rare event of a crash.

Like I said, I'm not a programmer, so take this with a grain of salt. I think that, in general terms, having two instances of O simultaneously reading/writing into the same opencpn.ini file is asking for trouble. I used to do it prior to v3.2.2, but it always bothered me, and I did it in a way that the .ini file was always restored from a clean copy at every launch so that any corruption was not propagated. And while there is always a way to program around that (such as O looks for another instance upon launch and if necessary creates a second .ini file), keeping two portable installations works around the issue in a straightforward way without complicating the code for something that only the die-hard users would want to do anyway.

I now realize that you weren't suggesting a change - thanks for making that clear to my sometimes dense brain!

[Wrong]

Originally Posted by bcn

And the point or score you're trying to make?

[ngux]

Originally Posted by nohal;
So to get it, just do
[code

sudo apt-get update
sudo apt-get install libbsb
[/code]Or install it from the Software Center.

Pavel

Works like a charm. What a great job you are doing here ! I will translate this tip on a French forum.
Problem solved for me. Thanks

[Wrong]

Originally Posted by bcn

Originally Posted by bdbcat

Wrong...

I'm done with experimenting.
Please tell me an exact recipe that does not work for you.

Dave

Removed libgl1-mesa-swx11 necessary to enable OpenGL in android. Ran full dependency reinstallation to ensure all are installed.

libglu1-mesa libgl1-mesa-glx zlib1g bzip2 gpsd gpsd-clients xcalib libgtk2.0-dev gettext git-core cmake libgps-dev build-essential wx-common libglu1-mesa-dev libgtk2.0-dev libbz2-dev libtinyxml-dev libwxgtk2.8-0 libwxgtk2.8-dev libwxbase2.8-0 libwxbase2.8-dev libsdl1.2debian debhelper devscripts dh-make dpkg-dev fakeroot lintian diff patch libtinyxml* libportaudio2 portaudio19-dev

Completed fresh installation of O4.

No waypoints, marks or ownship are visible. The "real scale vector" ship with appropriate settings for gps location on my boat only begins to become visible at maximum zoom.

Waypoints and marks never appear, even at max zoom.

Without libgl1-mesa-swx11 OpenGL does not work.

I'll report what happens after I install libgl1-mesa-swx11 and OpenGL is working. But, my expectation is once OpenGL is enabled the ownship will display. Not sure about the waypoints and marks though.

Edit: With OpenGL enabled there is no change. Exact same results.

[Wrong]

Originally posted by bdbcat:

4. Run OCPN4 from the bVNC Viewer, and remotely using xtightvncviewer.

What happens if you take "xtightvncviewer" and your computer out of the mix and run O4 solely on the android tablet with bVNC viewer? I have no idea whether O's settings are affected by the presence of your computer or not... Possible?

[bdbcat]

Wrong...

Some progress here. Leaving aside OpenGL, about which I will have more to say later...

1. Ownship. If you set the screen width parameter correctly (~200mm for a 7" tablet), does the ownship vector rendering show at the correct size? Measure against something that you know, like a narrow channel. This works for me, and seems accurate.

2. Marks, points: On my system, there seems to be some trouble in saving marks and waypoints on exit. The ~/.opencpn/navobj.xml files are all empty, even though the permissions/ownership are right.
I can drop waypoints and create routes no problem. They just are lost on exit. Is this consistent with your observation?

Thanks
Dave

[Wrong]

Originally Posted by bdbcat

Wrong...

Some progress here. Leaving aside OpenGL, about which I will have more to say later...

1. Ownship. If you set the screen width parameter correctly (~200mm for a 7" tablet), does the ownship vector rendering show at the correct size? Measure against something that you know, like a narrow channel. This works for me, and seems accurate.

2. Marks, points: On my system, there seems to be some trouble in saving marks and waypoints on exit. The ~/.opencpn/navobj.xml files are all empty, even though the permissions/ownership are right.
I can drop waypoints and create routes no problem. They just are lost on exit. Is this consistent with your observation?

Thanks
Dave

First, my search on the net for information pertaining to the xoom screen size raises this question. I assumed we are measuring horizontally, but encounter measures diagonally in discussions about android tablets. Attached is a screenshot of dimensions provided by an online calculator using known parameters for my Xoom.

Waypoints do not display when creating a route in O4. Only the route lines and arrow are retained after exiting and restarting O.

Edit: I converted the 8.56" width to 217 mm and manually entered into O4. No change.

xml files are NOT empty.