Data Import Error w/ Cressi Leonardo

Jef Driesen jef at libdivecomputer.org
Tue Apr 8 12:02:20 PDT 2014


On 07-04-14 09:32, Kevin Darch wrote:
> On 2014-04-07 06:40, Kevin Darch wrote:
>> I seem to be getting a "dive data import error" when trying to import my
>> latest dives.
>>
>> PC is Win8.1, Subsurface 4.0.3.0, I am using a Cressi Leonardo, and had no
>> problem importing the data previously.
>>
>> Using the supplied Cressi PCInterface tool I am still able to import the
>> dives without error, so it would seem the data itself is not corrupt.
>> Though that tool is really sucky and cannot export to any useful formats
>> (I attached the x2 offending dives in the tools .txt export format).
>>
>> Getting a logfile/dumpfile seems to indicate an issue with ringbuffer
>> pointer? "ERROR: Invalid ringbuffer pointer detected. [in
>> cressi_leonardo.c:341 (cressi_leonardo_extract_dives)]"
>>
>> Is there any recovery path you can suggest? I attached log & bin files for
>> reference.
>
> This error typically indicates that your data somehow differs from the
> expected data format. Typically an incorrect assumption in the reverse
> engineering. In this case, it seems it's the logic to find the last valid
> dive that fails. We look for an empty logbook entries (all 0xFF bytes), but
> your data contains an empty entry that has a few bytes that are not 0xFF. And
> that causes it to get interpreted as a valid dive, but the data of course
> doesn't make any sense.
>
> How many dives do you have? Am I correct that there are only 12 dives
> present?
>
> Yes, only 12 dives logged on the leonardo. I had previously imported upto
> #10, the latest dives #11 & #12 are those not wanting to import (dated 4/6).
>
> I am not sure if it makes any difference but I have dives logged upto #13
> already within subsurface itself, some manual entries, I don’t think this
> matters as I understand it looks at the date/time to make sure it does not
> import duplicate dives. I also had merged dive 3/4/5 from the leonardo into
> a single dive within subsurface which alters dive #'s. Regards

The problem is now fixed on the libdivecomputer master branch.

Jef


More information about the subsurface mailing list