=== DIVE UPLOADS ===
Jef Driesen
jef at libdivecomputer.org
Thu Dec 5 05:03:54 UTC 2013
On 2013-12-05 08:21, Benjamin wrote:
> On 5 December 2013 08:52, Linus Torvalds
> <torvalds at linux-foundation.org>wrote:
>> On Dec 4, 2013 10:48 PM, "Danilo Cesar" <danilo.eu at gmail.com> wrote:
>>>
>>> Suuntu gekko works fine, although the download ends when the progress
>>> bar is at 20%, I'm not sure if it is the expected behavior (but all
>>> dives
>>> are there)
>>
>> This is normal. Once we recognize an old drive, we stop downloading.
>> So
>> what happens is that you might have ten or twenty dives on the
>> computer
>> (depending on length of dives and your sampling rate) but you only
>> download
>> a few of them until you hit a dive you already have data for, and
>> subsurface stops downloading..
>
> From a user perspective, would it not be better to somehow figure out
> ahead
> of time if the current dive is already downloaded and change the
> maximum
> value of the progress bar so that the process doesn't seem to end
> "early"?
> Or dies it kick out the moment it hits the first downloaded dive?
That is technically not possible.
With the gekko protocol, you have to send a "get next dive" command to
the dive computer. You don't know in advance how many dives are present,
or how much data will be transferred. Therefore libdivecomputer has no
other option then to assume the worst case scenario for the progress bar
(e.g. downloading the entire logbook memory area). That's why in
practice even a full download will almost never reach 100%.
There are of course dive computer protocols where we can do better, but
the gekko is not one of those.
Note that with some protocols, it's possible to have 100% accurate
progress events, even when downloading only the new dives. But that only
works when using libdivecomputer's built-in fingerprint feature, because
it needs to make this decision (using internal knowledge) upfront, and
not after each dive. At the application level, you can - as Linus
already mentioned - only stop the download early.
Jef
More information about the subsurface
mailing list