hdr_buffer pointer was not always allocated (just on dc dives), but was
always freed.
This should cause a crash while processing a manually added dive (or a dive
whose dc model couldn't be stablished), but not always does, crashes only
if the pointed memory hasn't been previously allocated. In most cases causes
memory corruption, which goes easily unnoticed as it is correctly freed in
next parse run.
This means, obviously, I have some work TODO fixing leaks with valgrind.
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
There were 1 or 2 hour differences between real dive time and the
imported time because of the time zones and energy saving in some locales.
Using timegm() ensures us UTC times instead of localized times.
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
Can't remember what I was thinking when wrote that crappy thing. A
simple sscanf call will do the job, and a sanity check, off course.
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
Libmdbº:xturns localized strings while parsing the data bases. This is
bad for time calculations as we may end with different strings formats
(e.g. en_US vs almost the rest of the world). Solution is simple: set a
fixed locale and parse only this format.
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
In commit 70e2404492 ("Stop accessing the internals of
dc_descriptor_t") the structure definition of the libdivecomputer
descriptor was removed from Subsurface and replaced with accessor
functions. This adapts the Smart Trakl import tool to use the same
accessor functions, which allows it to compile again in current master.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This enables posibility of building standalone import tool via cmake.
Adds an option SMARTRAK_IMPORT (defaults to OFF) which, if turned ON,
will require glib-2.0 and libmdb libraries to be installed, and, calling
will produce an executable with the highly original name of smtk2ssrf.
I have no capability to cross-compile to windows, so I haven't even
tried to put this in Win, less say in Mac. I expect linux users which
may be actual users of SmartTrak, to test this before trying to build on
windows, although the target public will probably be the windows users (or
at least, ex windows user).
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The tool can be called from CLI with or without arguments, if called with a
single argument (this is, no destination file specified) an usage message will
be displayed on the terminal; if called with arguments, these should be the .slg
file(s) to be imported and a single .xml file to store the resulting Subsurface
formatted data; if called without arguments a GUI will display to select the
file(s) to import and to store.
WARNING, if destination file exists, its previous content will be erased.
The GUI is pretty simple and don't think any more is needed but, as this is my
first QT thing, I expect those with much better knowledge of QT/C++ will
improve it as needed.
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
SmartTrak is a Windows based propietary dive log software by Uwatec, which has
been the reference software for every Scubapro/Uwatec IRda based devices,
ranging from Smart to Galileo. It has just been recently that began to be
substituted by newer softwares like LogTrak and JTrak (these only supports
Galileo or newer devices and don't import SmartTrak's .slg files).i
SmartTrak also supports importing dives from older DataTrak software (oldest
Aladin series, serial based DCs) so most divers using Scubapro/Uwatec products
have probably their dives registered in this log, even those who have just moved
to newest Scubapro/Uwatec DCs.
SmartTrak is based in MS Access database with support for recreational and
technical dives up to 10 tanks, trimix (in later versions, prior versions had
support for just 3 tanks with Nitrox) and SCR/CCR.
In Linux, MsAccess databases are supported via libmdb which in turn depends on
libglib2, so this work has a hard dependency on these two libraries.
Libmdb sees very little (or null) development activity today so it can be
considered a mature library, which, in my opinion, makes it independent of
progresses of libglib2, this way, the tool should build on most Linux
distributions, even oldest ones (well, this will actually be false because of
the other dependencies of Subsurface).
Final note: It hasn't been until very recently that libdivecomputer has included
support for some of the data downloaded from Galileo devices, even today
understanding some of these data is WIP (e.g. alarms, are interpreted as
bookmarks at this moment, and there is a lot of noise coming from the
tanks/gases area in libdc)
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
