Dirk,
I don't see a description of the problem in the email thread, so I'm probably
missing some context here. Anyway, from a quick inspection of the
libdivecomputer logfile, the contents of the compact headers looks suspicious.
The first 4 entries all look good:
i=0, offset=0, current=1, data=C4160014011C101C1F1A1F0025010024
i=1, offset=16, current=2, data=9C14001405130A2368051C003A020024
i=2, offset=32, current=3, data=8417001405130D071C0621002F030024
i=3, offset=48, current=4, data=0F130014051310005A051A0015040024
The rest of the entries are all 0xFF, which is normal too. Except for the 228th
entry:
i=228, offset=3648, current=16386, data=0240812005408E400220608120024020
Because this one has the highest dive number (16386), it will be selected as the
most recent dive. But that number looks very suspicious to me. I suspect it
might be some corrupted data instead of an actual dive. So if we try to retrieve
that dive, I wouldn't be surprised if things go wrong. I can't really tell what
happened, because the log appears to be truncated at this point.
@Till: Any chance you can download a full memory dump of your OSTC? You probably
need to use the desktop version of subsurface for that. Or the libdivecomputer
dctool command-line application. I'll likely also need the full log from a
normal download.
If this indeed turns out to be a corrupted logbook entry, then we can probably
fix it by erasing the problematic logbook entry.
Jef
_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
