Strange duplication of dives

[Jef Driesen]

On 16-12-12 18:14, Dirk Hohndel wrote:
> Jef Driesen <jefdriesen at telenet.be> writes:
>>> I just found an odd new bug (or maybe a feature ;) when downloading
>>> today's dive on a newly built version. I use a Reefnet Sensus Pro to
>>> track my dives, which doesn't seem to allow me to delete dives, so I
>>> rely on the drop-duplicate code. Today, I found that it was adding the
>>> dupes, but putting them 1 minute earlier, and often treating them as
>>> separate trips. I have attached my file, complete with the
>>> manufacture test dives and some odd log entries due to leaving my
>>> Sensus on the balcony in Mexico (I don't think I would be here with
>>> real dives like that!).
>>
>> I suspect that this is due to how the sensuspro keeps time. It uses the clock of
>> the host system, which means that if the host clock has been adjusted since the
>> last download, then on the next download all dive timestamps will be adjusted
>> with the same amount.
>>
>> @subsurface dev's: Shouldn't the diveid hash that was introduced some time ago
>> catch this? The raw timestamp in the dive doesn't change, only the parsed
>> date/time value.
>
> The diveid is simply part of the SHA1 hash of the fingerprint of the
> dive. I assume that contains the raw timestamp, correct?

For the sensuspro, the libdivecomputer fingerprint is indeed the 4 byte raw 
timestamp. So the fingerprint (or its hash) is invariant and thus should have 
triggered the cut off, regardless of whether the final date/time value is 
different or not.

> We used to cut off downloads by saying "this dive was prior to the last
> dive that we already have" - much simpler and certainly prevented what
> happened to you...

That's not entirely correct. If the duplicate gets a time that is greater than 
the time of the dive you already have, you would still get a duplicate.

Jef