testing the Uemis code [was Re: UEMIS-bug fix: fixing the dialog message when the memory us full]

[Guido Lerch]

2015-09-16 3:55 GMT+02:00 Dirk Hohndel <dirk at hohndel.org>:

> > Anyway, it looks like the uemis support is usable, but has a few
> > warts. I'm assuming those are the patches you're working on.
>
> My results were not as good as Linus'
> After 8h connected to a charger it finally came back to life.
>
> When trying to download (empty dive file, so start from the oldest dive)
> it loads the first set of dives and then ping-pongs between details for #2
> and details for #3 back and forth and back and forth until the memory is
> full.
>

This is exactly what happened to me with the old code where the offset was
calculated,
I completely re-did that part and tested it on 2 different Uemis computed
which worked
like a charm.

>
> Progress seems even slower than before if that's even possible.
>
> Reading through the code I don't see what happened to the offset we used
> to have there to deal with the fact that the Uemis idiotically doesn't use
> the same id as keys in its different data bases. I didn't have the time to
> dig down into where exactly the bug is but it clearly gets stuck trying to
> load the correct dive details with GetDive, but I don't think the logic
> used to adjust "dive_to_read" is sound.
>

Ca you do me a favour and switch on UEMIS debugging and send me the dump
files ? This will help me to analyse how your object_id and logfile_nr
differ from
mine which will help fixing the matching that obviously doesn't work on you
Uemis.

>
> Cancelling the download from the dialog doesn't appear to work, either.
> Subsurface is simply hung when doing that.
>

A bad on my side that I'll fix.

>
> I'd say there is still room for some improvement.
>
> /D
>



-- 
Best regards,
Guido
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150916/2e445c5c/attachment.html>