Garmin support: ignore FIT files that aren't dives

[Dirk Hohndel]

> On Sep 4, 2018, at 6:11 PM, Linus Torvalds <torvalds at linux-foundation.org> wrote:
> 
> On Tue, Sep 4, 2018 at 4:38 PM Linus Torvalds
> <torvalds at linux-foundation.org> wrote:
>> 
>>> - in the FIT file, the Descent Mk1 is identified as product 2859; I think this would
>>> make sense to use as model number (instead of 0)
>> 
>> I'll take a look.
> 
> I took all your commits. Minor changes, like not checking that
> device_index, because it actually changes *after* you've already seen
> the values.

As you have seen, there are several devices inside your Garmin. 
device index 0 is the whole device, it has no device type
device index 1 is the <I have no idea - device type 4>
in my case it happens to have the information as index 0, which is why my code
happened to work
device index 2 is the <I still have no idea, device type 3>, no serial, no fw version
device index 3 is of device type 8 and has again no serial, but fw version 30.45

etc

Clearly we need to use the device_info message that is for the correct device_index.
So no, I don't think we can ignore this.

> The garmin field numbering is confusing. For example, device_index is
> indeed field #0, but it's not the first field in the record stream.
> It's one of the last fields because it's a small one-byte field.
> 
> So when the FIT file stream is parsed, you will see things in this order
> 
> first DEVICE_INFO message:
> - firmware field
> - device index: 0
> 
> second DEVICE_INFO message
> - firmware field
> - device index: 1
> 
> so when you checked "is device index 0", that check triggered for both
> of those firmware fields, because the device index updated to 1 only
> _after_ you'd seen the second firmware field.
> 
> I could have done it the "proper" way with actually batching it up
> using the record_data thing, but it seemed unnecessary, and I just did
> that "only overwrite firmware when the old number was zero".
> 
> Which isn't necessarily the technically proper way to do it, but it
> gets the right result, and we get the firmware field details from the
> first/main DEVICE_INFO message.

But that makes the assumption that the first DEVICE_INFO message that
you get is the one for device index 0. Now that I understand better how this
works, I'm not sure I like that assumption all that much, either. We really
SHOULD do this in the record_data function.

> Of course, the serial number and the product data we could have just
> gotten from the FILE message, which only happens once. But that one
> doesn't contain the firmware information, and yeah, the firmware field
> has different values for the different device_index values. I don't
> know why, but at least now it takes that first one.

I'll play with this some more, but I may send you a follow up commit
to make sure we really grab the info from device index 0.

Thanks for merging - I will update the submodule now because at least
with my FIT files the current code happens to work :-)

/D