To avoid confusion: you'll need Subsurface-mobile 3.4.1(or newer) and Subsurface 5.0.4.25 (or newer) to test this...
/D > On Nov 12, 2021, at 3:46 PM, Dirk Hohndel via subsurface > <[email protected]> wrote: > > My code to share fingerprints via the cloud has been merged into master. > Android test binaries with that new code are pending review to be pushed into > the beta channel. > I'll work on iOS test binaries in a moment. > > It would be extremely helpful if this could get some testing. > This new feature is extremely useful for Scubapro G2 users (download via > cable on your PC and when you next attempt to download via BLE on your phone > the right thing happens). > The G2 is certainly the most egregious case - but I'm sure this will help > with some others that I'm not aware of where having the correct fingerprint > also makes a difference in download duration on mobile. > > In order to test this you need a dive computer that you can download from on > two devices - doesn't matter if its mobile or desktop. > Test scenario: force a download on one computer/device (either delete the > last dive or force download all dives). Sync with cloud, sync with cloud on > the other computer/device. > a fresh download should successfully use the fingerprint and immediately tell > you that there are no new dives. > > /D > >> On Oct 23, 2021, at 5:12 PM, Dirk Hohndel <[email protected]> wrote: >> >> >> Hey Linus, >> >> The more I think about our current fingerprint handling (I think that's our >> third attempt), the more I think we are still not doing this right. >> >> Right now we consider fingerprint files specific to a host (so the specific >> system - PC, laptop, phone, tablet) that Subsurface runs on. >> So let's say I have a PC and a phone. I use the cloud to store my dive data. >> And I also want to download my dives for a research project into an XML file. >> >> (1) on my PC I download from my dive computer and store the dives in the >> cloud >> -> there is a fingerprint file in the PC file system and the dives are in >> the cloud >> (2) after a couple more dives, I download again >> -> Subsurface finds the fingerprint file and only downloads the new dives; >> all good, fingerprint file on the PC and cloud dives get updated >> (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 >> (4) more diving, this time I only brought the phone >> -> no fingerprint file on the phone, all dives are downloaded >> -> new dives go in the cloud, fingerprint file on the phone >> (5) no additional diving, back on the PC >> -> those last dives would attempt to download again (the fingerprint is >> outdated), but after the first one downloads we'd recognize that we already >> have it and give up -- without updating the fingerprint file on the PC >> (6) I buy a new phone, connect to the cloud, then try downloading from the >> dive computer >> -> even though all the dives are in the cloud, because there is no >> fingerprint file, we download from the dive computer >> -> because no new dives were downloaded, no fingerprint file is written - >> so we do this every time until the next time we actually have a new dive >> that's downloaded on that phone >> >> (3), (4), (5), and (6) all indicate that what we are doing isn't really right >> The fingerprint information really is tightly related to the dive log file. >> That's why we have this check in (3) to prevent us from ignoring the dives >> on the dive computer if the fingerprinted on isn't in the dive list. >> I can actually turn (4) and especially (6) into a really annoying situation >> with a dive computers like the G2 where we keep downloading all dive data if >> we don't have a fingerprint (there is no "give me the newest dive" function >> - if you don't have a fingerprint you download everything) -- and of course >> all this is especially frustrating when this is a BLE download that takes >> for ever and is super flaky. >> >> 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). >> >> 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... >> >> Thoughts? >> >> /D >> >> >> >> > > _______________________________________________ > subsurface mailing list > [email protected] > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
