dirkhh
Contributor
Ah, ok. So you have done 150 or more dives with your uemis Zurich already? Impressive. I was mostly worried that the object_id was bogus to begin with.
The off-by-one error may not be uemis' fault - this might be an error in our extraction tool. We are investigating this.
As for the files that you posted - THANK YOU. Once again my latest version parses the divelog perfectly and is just missing some data (divespot, gear, buddies) on the dive file.
Very encouraging.
The off-by-one error may not be uemis' fault - this might be an error in our extraction tool. We are investigating this.
As for the files that you posted - THANK YOU. Once again my latest version parses the divelog perfectly and is just missing some data (divespot, gear, buddies) on the dive file.
Very encouraging.
Hi dirkhh,
on my computer, the coresponding diveXXX.SDA and divelogXXX.SDA get the same number, simply 1 too low.
I already included the corresponding divelog147.SDA file into the zip in my previous reply. Both files include the identical date and time 2011-07-20T18:16:50 and it is further corresponding with the date/time in the base64 data stream.
Strangely in divelog147.SDA the object_id now says 148. It looks like they made a real mess with their ID's.
<hash ref="divelog" version="1.0">
<val key="computer_id">
<int>18877</int>
</val>
<val key="object_id">
<int>148</int>
</val>
<val key="date">
<ts>2011-07-20T18:16:50</ts>
</val>
...