<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br><br></div><div><br>On 29 Jun 2015, at 01:00, Andrey Zhdanov <<a href="mailto:andrjufka@gmail.com">andrjufka@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On 28 Jun 2015, at 18:49, Dirk Hohndel <<a href="mailto:dirk@hohndel.org" class="">dirk@hohndel.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">On Sun, Jun 28, 2015 at 04:48:03PM +0800, Miika Turkia wrote:<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">Miika, I would love it if you could try this (but I understand if you<br class="">don't have the time or network bandwidth to do so). I think the debug<br class="">messages are verbose enough to make it easy to track down what happened<br class="">and why the fixes are chosen.<br class=""></blockquote><br class="">I think I got correct locations today. I'll try to test this a bit<br class="">more, purely for the benefit of all :D<br class=""></blockquote><br class="">I think this is related to downloading new dives from DC and getting<br class="">the GPS positions. It occurred again after I had just downloaded the<br class="">day's dives, while syncing GPS coordinates. I hope I can catch this on<br class="">gdb tomorrow, otherwise I might have to start backtracking the log<br class="">file and downloading again from DC...<br class=""></blockquote><br class="">For crashes like this it's often easier to catch them with Valgrind...<br class="">Since downloading from DC and syncing GPS coordinates shares some<br class="">infrastructure my bet would be that there is some dangling data that<br class="">doesn't get cleaned up...<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">Also the IOS companion app is very slow to realize there is no<br class="">Internet connectivity when I am attempting to start logging.<br class="">(Workaround: quit and open up the app to trick it to notice syncing is<br class="">not going to happen.)<br class=""></blockquote><br class="">Do you have a pointer where to report this one? If you do not have<br class="">that handy, I can always dig it out myself later.<br class=""></blockquote><br class="">Andrey Zhdanov wrote the IOS companion app. I copied him on this email.<br class=""></div></blockquote><br class=""></div><div>Yes, that’s me. I check mailing list from time to time, but it’s always better to contact me with a private e-mail, on facebook (that’s will be a perfect option) or submit an issue on <a href="https://github.com/zdanovs/subsurface-companion-ios/issues" class="">github</a>. </div><div><br class=""></div><div>So, what is needed to be done? Better “no internet” handling? </div></blockquote><br><div>Yes, when there is no Internet the sync should timeout immediately or maybe not even attempt it. Also with extremely poor connection, it might make sense to just fail the sync. Anyway, my aim is to start tracking the location fast when I am hurrying to a boat...</div><div><br></div><div>It would also be nice to know, what has been synced to the cloud or possibly when the last sync occurred successfully.</div><div><br></div><div>BTW what does the cloud symbol indicate in some of the dives?</div><div><br></div><div>miika</div></body></html>