On 24/10/2021 02:12, Dirk Hohndel via subsurface wrote:
(3) close the cloud storage, open a local .xml file; download again
-> fingerprint file is found, but the matching dive is not in the dive
list, so fingerprint gets ignored (but why are we even looking at it???)
-> dives are downloaded, fingerprint is written again
What's the reason for ignoring the fingerprint if you don't have the
corresponding dive anymore?
Assume you download your dives, and for some reason you don't want to keep the
most recent dive in your logbook. Now, according to the above logic, the next
time you download, you ignore the fingerprint because the dive isn't in the
logbook and thus you'll re-download those old dives again, including the
unwanted dive. For the dives that were already in your logbook, that's just
inefficient, but they won't get added twice (I believe subsurface has some logic
to prevent that). But that unwanted dive will re-appear, and you'll have to
manually remove it again.
As a user, I would expect that the download resumes at the point where it
stopped last time, regardless of whether I kept the previously downloaded dives
or not. If I really want to re-download previously download dives, I can use the
"Force download all dives" option, which disables the fingerprint logic.
Some example scenarios where you don't want to keep every dive recorded by your
dive computer: If you have a watch style dive computer that you also uses as a
watch, the watch may record activity in the pool as dives. Or someone doing both
scuba and freedives may want to keep two separate logs.
I am back to thinking that we should consider the fingerprint a property of a
specific dive log. So both an XML file and the git storage should remember
the last fingerprint for each dive computer from which we did a direct
download. And we should index that exactly like we name these files in the
filesystem right now - model.devinfo-serial - and then have the fingerprint
data be a hex encoded byte stream of fingerprint-deviceid-diveid.
Sadly, this still causes pointless re-download orgies when a firmware change
or some other change messes with the devinfo-serial number which we have to
use as lookup parameter - but it seems like it would get more cases right
than what we have today.
Of course, this all is triggered by the plight of specifically G2 users. And
the annoying fact that even if they do the full download on a PC via cable,
they still have to get a full download to work on their phone via BLE...
I'd much rather come up with a way to not rely on the devinfo-serial number,
but at least on the G2 that one looks like it should be stable (there's no
way to get the firmware version on the G2, it seems).
Why would a change in the firmware version cause a re-download? The serial
number in the devinfo event is completely independent from the firmware version.
Unless the device suddenly starts to report a different number, the serial
number will not change after a firmware update. So it's as stable as it can be.
The devinfo serial number may indeed not match exactly with the serial number as
printed on the device (due to some additional formatting which can't be
represented by a simple 32bit number). But that's another story. The primary
purpose of the serial number in the devinfo event (and the devinfo event itself)
is to support the fingerprint feature: provide a unique ID to identify an
individual device. For that purpose, it doesn't matter it doesn't exactly match
the human readable serial number. It that sense it's like more an opaque ID,
just like the fingerprint itself.
Of course, where possible we try to decode the serial number correctly. The
reason why it's a 32bit number is historic. At the time this feature was added
(more than 10 years ago), representing serial numbers as a 32bit integer was an
obvious choice, because that's how dive computers stored it. Since then, there
are many new dive computers that do things a bit different...
I wonder if I am missing something in my model here... is there a scenario
where storing the fingerprint with the dive log file creates incorrect
behavior? At least for the important case (dive computer that supports both
wired and BLE transfer - do the fast wired transfer on the PC and have the
correct fingerprint for the next BLE transfer both locally AND and on the
phone) this seems like it would be an improvement...
One scenario where you have to be careful is when the download failed. Because
dives are downloaded in reverse order, you get the fingerprint of the most
recent dives immediately with the first dive. But if you do update the
fingerprint when some of the older dives failed to download, then you won't be
able to retry and download those older dives without disabling the fingerprint
again. So you should only update the fingerprint after a successful download,
and deal with the duplicates after retrying.
Jef
