Missing HR data in one lap - can’t find it in file but Garmin Connect has it

Attached is a file from a swim/transition/bike multisport file. The issue I have run into is with the swim session. There are 4 laps on the swim, and the final lap is 2:38 in duration. That lap has no data for HR in it other than the final record (it has 70 as the HR) which is incorrect. The records should have HR values between 157-163 for that 4th lap.

I've verified this in Garmin Connect as you can hover over the charts in their system and see the data for this lap. I have contacted Garmin and they said that the data is in the file and that they are not using a special algorithm to extrapolate the missing values. I've checked the "hr" messages at the end of the file, and it's not in there either (according to the SDK the HR Mesg should be #132 and I don't see that in the file). There's a lot of "unknown" messages but none are #132.

Has anyone run into this before and would you be able to take a look at this file to see if you can find the missing HR data? I have no idea where Garmin Connect is getting this from. Thanks for any help you can provide.

File Attachments

What version of the SDK are you using? It looks to me like there are HR messages at the end of that file. If you use the FitHrRecordReader Plugin that is included in the SDK the Records can be reconstructed.

So finally, we were able to find this data in the buffered messages. The issue we are now running into is that the way we read the files breaks the buffered MessageBroadcaster. When we read a file, we do the following:

1. Set the incompleteStream flag to true. This allows the decoder to read files that are incomplete -- or cutoff at the end.
2. Skip reading of the header. The header contains a checksum in it. If the checksum fails, the file won't process. Skipping the header ignores that checksum check, and allows us to process what data is present.

If we don't do #1 and #2, we can read the buffered messages, but then we can't parse as many files (we find a lot of whacky files that these methods allow us to parse correctly). I guess we have to decide which route we want to go.

Does anyone know how common/uncommon these buffered messages are? I guess that would help us decide if we no longer do #1 and #2 so we can get the buffered data, or if we leave things as they are (assuming the buffered data in files is fairly rare).