Hi, Conrad.

On Tue, Jul 30, 2013 at 12:09 AM, Conrad Meyer <cse.cem@gmail.com> wrote:
Hi all,

Today my Garmin Forerunner 110 produced a .fit file that GPSBabel does not want to convert. I'll attach the (small) file, and I've posted it to Google Drive in case the list strips attachments.

Thanx for the good description.  The file you provided (in both forms) doesn't seem to actually trigger the problem you describe.   Still, I've applied a patch that should cure this. 

 I'm running the latest (1.4.4) gpsbabel; here's the usage and output at high debug:

$ gpsbabel -D6 -i garmin_fit -f <attached_file.fit> -o gpx -F xxx.gpx
GPSBabel Version: 1.4.4
fit: header len=14
fit: protocol version=16
fit: profile version=135
fit: fit_data.len=8928
fit: starting to read data with fit_data.len=8928
.....fit: got data message at fit_data.len=8927 ...local message type 0x2
.....fit: got definition message at fit_data.len=8926 ...local message type 0xB
fit: Definition message reserved bits not zero

That's not what I see on the file you provided:

fit: starting to read data with fit_data.len=8928
.....fit: got definition message at fit_data.len=8927 ...local message type 0x0
.......fit: definition message contains 6 records
.......fit: record 0  ID: 3  SIZE: 4  TYPE: 140  fit_data.len=8919
.......fit: record 1  ID: 4  SIZE: 4  TYPE: 134  fit_data.len=8916
.......fit: record 2  ID: 1  SIZE: 2  TYPE: 132  fit_data.len=8913
.......fit: record 3  ID: 2  SIZE: 2  TYPE: 132  fit_data.len=8910
.......fit: record 4  ID: 5  SIZE: 2  TYPE: 132  fit_data.len=8907
.......fit: record 5  ID: 0  SIZE: 1  TYPE: 0  fit_data.len=8904
.....fit: got data message at fit_data.len=8903 ...local message type 0x0
......fit: parsing fit data ID 0 with num_fields=6
Did you perhaps binary edit that file or something?

I was going to add your file as a test case, but the change is so self-evident that I'm not going to worry much about it.

In my attached example file, this byte happens to be 0x40. To me, this looks like probably some kind of flag. However, I don't know what it means. Maybe the right thing to do in this case is print a warning that a reserved bit is set, and then proceed as usual? My proposed patch (attached) does this.

This is always the curse of reverse engineered formats - when you have something you can't identify do you ignore it or do you acknowledge that there's something about it that you haven't tested?  There's no clear answer and we do different things in different places.

There's really no reason to warn a human; it's not like there is anything they can do about it, so I've just tossed the warning completely.

P.S., I've filed a bug with Fedora; I couldn't find a bugtracker for
gpsbabel so I hope this mailing list is the appropriate place. The Fedora
bug is here: https://bugzilla.redhat.com/show_bug.cgi?id=989851

This list is the correct place.   I can't recall ever getting a patch from Fedora for anything - even when they break or hobble our product - so if you ever actually need something fixed in GPSBabel, this is the place to come.