testing of download from divecomputer needed

[Jef Driesen]

On 2015-01-13 09:11, Dirk Hohndel wrote:
> On Tue, Jan 13, 2015 at 09:00:50AM +0100, Henrik Brautaset Aronsen 
> wrote:
>> The only thing I reacted to was that the progress bar only worked 
>> during
>> the first couple of minutes.  After that it was at 0%.
> 
> That's strange. Looking at the shearwater_common_download() function in
> libdivecomputer's shearwater_common.c, it seems that we should get 
> regular
> progress events throughout the download.
> 
> Could you put some debug printfs in the event_cb() function in
> Subsurface's libdivecomputer.c ? Something like the patch below
> 
> I'd be curious what values you get from that...

This is a (known) bug in libdivecomputer. Instead of a global progress 
for the entire download, the petrel backend reports progress for each 
individual dive. So the progress bar will go from 0 to 100% for every 
dive. Due to the fact that the size of a dive isn't known in advance, we 
have to assume the worst case value (0xFFFFFF). But in practice a dive 
is usually much smaller, and thus the progress bar will stay near zero.

Fixing this is non-trivial. We don't know the size in advance, and the 
data is compressed too. The easiest solution would be to count the dives 
instead of the bytes, but that will be very coarse. It also doesn't take 
into account the downloading of the manifests, which will be the 
relative large when downloading just a small number of dives. And that 
happens to be a very common use-case.

I have been thinking of a smarter algorithm (but didn't have time to 
implement or try it yet). Something similar to what I implemented for 
the idive backend. There, each dive gets the same "weight" based on just 
the number of dives (e.g. 100 / ndives). Within each individual dive, we 
scale again to a range from 0% to 100%. This results in a smooth 
progress bar going from 0 to 100%, at the expense of a non-constant 
speed.

One complication here is the fact that we don't know the size of a dive 
in advance. We can probably estimate it based on the divetime from the 
manifest and the fact that samples have a fixed size. But we'll need to 
be careful here not to exceed 100% if our estimation turns out too 
small.

The manifests are another tricky part. We don't know the number of 
manifests in advance at all, and as far as I know it can't be estimated 
either. But you do want to take it into account somehow, because it's 
relative large when downloading just a few dives. Maybe we need a new 
variant of the progress event to indicate a "busy" state (e.g. we're 
working, but don't know yet how long it will take)? An application can 
then use that to show a pulsating progress bar during this phase. I 
could use something like this in other backends too. Right now, I just 
set the maximum to a worst case value (often 0xFFFFFFFF), which 
effectively means the progress stays at 0%. This worst case maximum is 
then updated as soon as we have a better value available. Unless this 
phase is very short, this isn't ideal from the user point of view.

Jef