Few bugs and a feature req from testing Subsurface

[Linus Torvalds]

On Mon, Mar 10, 2014 at 4:33 AM, Miika Turkia <miika.turkia at gmail.com> wrote:
> Features:
> - Show original time and new time when adjusting dive time on the dialog
>
> Bugs:
> - I have one DC recording near surface time properly another is not
> recording these times. This results in the second DC recording shorter dive
> duration. And Subsurface seems to trust more the latter DC when reporting
> dive duration even though it used to be that first downloaded DC was the
> main one.

I actually think that you may see subsurface itself discounting any
surface time.

Some dive computers tend to show events at the surface (particularly
at the end of the dive) as you are floating around waiting to be
picked up by the boat. That can be very annoying if they count towards
the dive time, since they can make a 45-minute dive look like a much
longer dive.

Similarly, if you pop up to the surface in between dives (either to
look for a buddy, or because you merged two dives because the first
dive was a 5-minute "jump off the boat, notice you're in the wrong
spot, get back on, reposition, and jump back in"), then the dive sure
shouldn't count as a long dive just because you spent 10+ minutes in
between on the surface.

See dive.c: fixup_dc_duration()

> - Downloading first EAN32 dive from one DC and then downloading second DC
> for the same dive with EAN21 (this DC resets its EAN if it is set too early
> before dive), forces the whole dive to show as being air in this case. I
> ended up with two cylinders, first with EAN32 and proper start and end
> pressures as reported by air integration, second with AIR and no pressure
> info (no air integration on second).

Yes. We currently have no really good way of *fixing* dive computer
event association with cylinders.

We try to do a good job of creating multiple cylinders and associating
the dive computer with the right cylinder (because that's actually a
real use case, with different dive computers sensing the pressure of
different cylinder), but in your case there weren't actually multiple
cylinders, there was just a confused dive computer.

The gas switch and pressure events get associated with the index of
the cylinder that matches the gasmix of the dive computer etc, but
there's room for improvement. I suggest, for example, that if somebody
manually deletes a cylinder so that the divecomputer cylinder index
now points to something that no longer exists, we might just want to
say "ok, let's just reset the cylinder index".

But I think you'd need to implement that logic. I *might* take a look
at it if you send me the XML file for the dive, but no promises.

> - Many events are missing the label explaining what they are (on the
> tooltip)

Do we even know what the events really are? I don't think we have very
good coverage about the event numbers for most dive computers..

> - Dive buddy selection from list with keyboard is not working properly. I
> have entries with first name only and with full name. If I type start of the
> first name, I get list of matches properly, but cannot select the full name
> with arrow keys.

Ugh. Tomaz - this sounds very similar to the cylinder selection
problem we used to have (still have?)

> Crash:
> Dive data import error => Segmentation fault
> [5.539] ERROR: Unexpected answer start byte(s). [in suunto_vyper.c:371
> (suunto_vyper_read_dive)]
> Segmentation fault (core dumped)
>
> Unfortunately the default core handler seems to be apport and it ignores
> cores from apps that do not belong to any package. So no details available
> on this one.

If it is at all reproducible, try just running it under gdb, then gdb
will catch the fault and you can see where it is etc.

                            Linus