testing of download from divecomputer needed

Miika Turkia miika.turkia at gmail.com
Mon Jan 12 02:34:36 PST 2015


On Sun, Jan 11, 2015 at 5:38 PM, Dirk Hohndel <dirk at hohndel.org> wrote:

> On Sun, Jan 11, 2015 at 12:48:09PM +0200, Miika Turkia wrote:
> > On Sat, Jan 10, 2015 at 1:22 AM, Dirk Hohndel <dirk at hohndel.org> wrote:
> >
>
> > First I tried to DL Vyper a couple of times with no success,
>
> Why was that? Wet contacts? Bad connection?
>

I suspect poor connection, but still no DL from the Vyper. Been trying to
clean the contacts to no avail.


>
> > then Stinger succeeded on first go but got me this crash.
>
> Yes, because of the sequence in which the download dialog does things,
> Robert's patch would always cause a crash when clicking OK. I guess I'm
> not the only one who didn't test a fresh download :-)
>

Pretty much what I suspected :D


> > When I get a DL error at the last of the new dives, I think discarding
> the
> > current DL when I hit retry would be appropriate. (I have the first run
> and
> > the retry on the DL list. Otherwise, highlight the newly downloaded
> dives.)
>
> I'm a bit conflicted about this. One of the weird problems caused by the
> design of the Uemis is that you cannot load all of the dives in one go if
> you have more than about 50 dives to download. So in that case, the retry
> will be incremental - it will add to the already downloaded dives. But I
> guess I should special-case that and indeed clear out the list when you
> click Retry - just makes more sense. Otherwise you always get these
> confusing duplicate dives in there.
>

The status bar showed me Dive 5 when there was 4 new dives downloaded and
available to include in the import. Maybe the status bar could say that
Dive 5 downloaded before or something when it decides not to download it?

Also a download from second DC starts from 11%. I suppose the counters are
not reset when doing a new DL. I even closed the logbook in between
(Subsurface was running the hole time).


> > Deselecting some of the downloaded dives enable a tick mark on one of the
> > already de-selected ones. But this turns out to be that the list is not
> > properly refreshed.. If I go to different desktop and back, the selection
> > is done properly. (Initially I thought the first un-tick was not accepted
> > and redid it due to display not being updated properly.) Anyway, I cannot
> > really be sure of what would be imported due to the crashing after OK
> > button.
>
> Hmm. Odd. The code tries very hard to tell Qt whenever something changes
> to make sure things get properly refreshed. I had very brief delays (a few
> hundred miliseconds) to selecting / unselecting dives in that list, but
> haven't seen a complete failure like you describe.


Mostly it is with no dealys, but the one tick just got stuck.

miika
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150112/67088788/attachment.html>


More information about the subsurface mailing list