no dives are shown in the Dive List
miika.turkia at gmail.com
Sun Feb 2 06:03:50 UTC 2014
I seem to have sample files from Diving Log 5.0 that are in XML format. The
XML file does have an export date in it, so it is probably an export. And I
believe DivingLog supports also exporting in UDDF format. I have never run
Diving Log myself, so I might also be wrong...
On Sun, Feb 2, 2014 at 2:58 PM, Jun Song <jun_song23 at yahoo.com> wrote:
> Diving Log 5.0 format is *.mdb
> But subsurface cant import *.mdb, what format would you like me to use for
> 'direct import' from diving log 5.0
> *From:* Miika Turkia <miika.turkia at gmail.com>
> *To:* Js <jun_song23 at yahoo.com>
> *Cc:* Jef Driesen <jefdriesen at telenet.be>; Dirk Hohndel <dirk at hohndel.org>;
> subsurface List <subsurface at hohndel.org>
> *Sent:* Sunday, 2 February 2014, 0:18
> *Subject:* Re: no dives are shown in the Dive List
> On Sat, Feb 1, 2014 at 5:59 PM, Js <jun_song23 at yahoo.com> wrote:
> Hey guys,
> I managed to download the dives to diving log 5.0 and from there upload to
> en.divelogs.de then download to subsurface.
> We do also have direct import support for DivingLog format. Could you give
> it a try and report back, if it features any worse than the import via
> divelogs.de? (I tend to miss some fields when doing the conversions so
> some testing is always appreciated.) Note, that you will have to import
> them to different log file as otherwise the duplicate dives are merged
> Jef Driesen <jefdriesen at telenet.be> wrote:
> >On 2014-01-28 16:11, Dirk Hohndel wrote:
> >> I wonder... Didn't the header length change? If he now has the new
> >> firmware with the longer header, will the old dives be downloaded with
> >> the new or the old header?
> >> That could cause parsing errors...
> >Yes, there are two variants with a different length, but there is a
> >version number embedded in the header to figure out the correct length.
> >but the header looks correct to me. I didn't notice any problem there.
> >The problem is in the profile data. When parsing the section with the
> >sample divisors, the corresponding sample lengths are all wrong. For
> >example a temperature sample is supposed to be 2 byte long, but the
> >length stored in the data is 3 bytes. The libdivecomputer parser fails
> >there already, but if modify the code to accept 3 bytes, it just fails
> >at some later stage.
> >The fact that the ostc itself also has problems displaying these dives,
> >is for me a strong indication that there is a problem with the data
> >rather than the parser.
> subsurface mailing list
> subsurface at hohndel.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the subsurface