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
_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
