Strange duplication of dives

Dirk Hohndel dirk at hohndel.org
Sun Dec 16 09:53:26 PST 2012


Linus Torvalds <torvalds at linux-foundation.org> writes:

> On Sun, Dec 16, 2012 at 7:34 AM, David Tillotson <david at acmelabs.co.uk> wrote:
> \>
>> 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.
>
> Ugh.
>
> I don't know why you have dives that are more than a minute apart, but
> that's what has happened. Did some of those dives come from an import
> from another divelog software? Or is the sensus relative clock *so*
> odd that it gets things wrong not by seconds, but by minutes?
>
> So the duplicates look like this:
>
>   <dive date='2012-06-17' time='11:22:47' duration='28:00 min'>
>   <dive number='2' rating='4' date='2012-06-17' time='11:24:00'
> duration='28:00 min'>
>
> and I assume that the "11:24:00" one is the old one, since it has a
> dive number (and location and divemaster information).
>
> Your old dive doesn't have any divecomputer model or dive ID
> information (because it's old), so subsurface can't match dives based
> on that either.
>
> So what happens is:
>
>  - subsurface assumes it's the same dive computer (because one of the
> dives has no computer information at all, so it assumes it matches)
>
>  - but the times are off by more than a minute, so subsurface says
> "different dives"
>
> See the logic in "likely_same_dive()" in dive.c. You can obviously
> just change it to always use a fuzz of 5 minutes..

Oh, so this can only happen the very first time he downloads dives - all
existing dives lack diveid and the new ones then are matched as you
describe? Or can this also happen if the xml file already contains some
dives with a diveid and some without?

And anyway, in the case of "no dive has a diveid" (which is what all
regular users upgrading from 2.1 to 3.0 will encounter), shouldn't we
fall back to the old date based cutoff?

/D


More information about the subsurface mailing list