Built from source or using prebuilt binaries? The Mk2i is supposed to be read via libmtp, not via a file system. So my guess is that you have some library mounting the device with exclusive access, Subsurface trying to mount it as well, and things fail.
You could select the Mk1 and then point to the Garmin folder above Activities - that should work and it should do the right thing parsing the FIT files (I haven't tried this method, but it's a thought). Or you could just not mount the Mk2i and let Subsurface do its thing (assuming you have linked libdivecomputer against libmtp - that's why I asked if you built from source) /D > On Mar 21, 2021, at 9:41 PM, David Lautenschlager > <[email protected]> wrote: > > Hi, > > I was just going to ask the question that is the subject of this thread "How > to download dives from Garmin MK2i?" I am running Linux Mint, and I can > browse the files on the MK2i, but no matter what directory in the path I use > for the "Device or mount point" I get a "Dive data import error." I assume I > am doing something wrong, but I can't figure out what. > > Thanks, > > David > > On Sunday, March 21, 2021, 07:24:29 PM CDT, Dirk Hohndel via subsurface > <[email protected]> wrote: > > > Hi Mark > >> On Mar 21, 2021, at 3:42 PM, Mark Stiebel <[email protected] >> <mailto:[email protected]>> wrote: >> >> Wasn't sure if I should be responded on the google group, or on the >> subsurface mailing list which I've now subscribed to. Please let me know, >> and I'll repost this email to whichever is your preferred channel. > > Development discussions best work on the developer mailing list. > >> I'm keen on seeing how I can contribute to Subsurface, although having said >> that it might be a slow start to getting to the point of actually being able >> to contribute. I'll give you a little background.. >> >> I've been a diver for about 30 years or so, and every couple of years >> re-evaluate my dive logging platform, and despite the fact that it misses on >> a few subjective things, > > Always curious what these things are. There are a few common ones that we > have repeatedly turned down because they just seem out of scope for what we > do, but it's always worth a try. > >> I seem to stick with Subsurface. I've not dived a lot over the past few >> years due to, well, life. And with a renewed enthusiasm for diving again, >> comes a renewed enthusiasm for attempting to contribute to Subsurface. > > I envy you your renewed enthusiasm. > With two dives in the past 17 months my enthusiasm is at its absolute low > point. > >> I'm also a long time developer, with my roots in C/C++, although admittedly >> haven't got my fingers dirty in real C/C++ for many years, so it will take a >> bit to brush the dust off. I'm still in the IT industry, but with my work in >> enterprise systems architecture and data & analytics and machine learning. >> The hobbyist side of me usually has me on the other end of the scale >> tinkering with the likes of Arduinos. > > I haven't been a professional software developer in a really, REALLY long > time. So futzing around in C/C++/QML/JS/whatever really is just a hobby here. > As is maintaining this project, of course. > >> I have a headless Debian Buster server as well as my Windows box. Given your >> comment below, I thought I'd first try to build native Linux, but have >> already come to a hurdle! Not having used Qt either adds a bit more to the >> learning curve. But nothing is insurmountable, even for an old dog :) >> >> ~/src/subsurface/build$ ./subsurface >> QOpenGLFunctions created with non-current context >> ASSERT: "QOpenGLFunctions::isInitialized(d_ptr)" in file >> /usr/include/x86_64-linux-gnu/qt5/QtGui/qopenglfunctions.h, line 886 >> Aborted >> ~/src/subsurface/build$ > > So Subsurface can easily be BUILT on a headless Debian box - but then for > running it, you need some way to display the screen, right? > We do actually have a headless version that is intended to be used on > Raspberry Pi or other small systems simply as a downloader, but that's likely > not the direction you are looking for. > So what you built above, is a native Linux app that will run on a Linux > system that has an real (or virtual) display. > > In order to run something on your Windows system, you need to cross build for > Linux. That's where the docker image comes in. > >> Maybe I should jump straight onto building it in your docker image :) > > Well, I don't know. The turnaround time is really painful. It might be more > fun to build under Linux. Where / how are you running this headless Debian > system? Is this a VM under HyperV? Or is there a way you could install a VM > with a desktop Linux somewhere? That will really make the learning curve so > much less steep... > > /D > _______________________________________________ > subsurface mailing list > [email protected] <mailto:[email protected]> > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface > <http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface>
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
