2015-09-16 3:55 GMT+02:00 Dirk Hohndel <[email protected]>: > > 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
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
