4.8.1 planning

[Miika Turkia]

On Fri, Jul 13, 2018 at 1:45 AM, Linus Torvalds <
torvalds at linux-foundation.org> wrote:

> On Thu, Jul 12, 2018 at 3:16 PM Anton Lundin <glance at acc.umu.se> wrote:
> >
> > I just dug up my Sport and put a battery in it and it fails to to
> > download, Both on linux and on Android. I tested it via rfcomm and that
> > worked just fine.
>
> So this actually would mesh with the delay being the issue.
>
> If you use /dev/rfcomm and just open it as a regular serial device,
> then you use the src/serial_posix.c code, and dc_iostream_sleep() will
> call dc_serial_sleep().
>
> Which does the nanosleep that it always used to do, and that we never
> used to override.
>
> The new libdivecomputer "iostream" model made everybody have to
> implement their own sleep implementation, which was obviously not a
> great idea. Not even libdivecomputer got it right (ie the socket sleep
> bug on OS X).
>
> So the "works with rfcomm, doesn't work with direct bluetooth socket"
> would be explained by that sleep difference.
>
> And it also would explain why it just randomly works for some people
> regardless, since it's all just random timing anyway.
>
> But it would be great if somebody could test that patch. None of the
> dive computers I have care (and most of them don't have a front end
> that does any delays in the first place).
>

Hooray, this seems to work. First test was with no new dives and the
connection worked immediately. Then I started a new log, first DL failed,
but a retry started the download. Not sure what went wrong in the failed
attempt, but it did take some time before the attempt timed out.

BTW I do also have the old model with red buttons and classic only.

But, as I downloaded everything that is available on the OSTC sport, it
seems that the oldest dives do not have the dive profile. Does the sport
keep the max depth and time information on log when it needs to start
overwriting? I have dive profiles for 205 dives in it and rest is without...

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