Hi,
been building a browser tool on the JS SDK (currently 21.178.0) that does a few structural rewrites to FIT files: splicing in a second sensor's HR stream record-by-record (nearest-timestamp match against a chest-strap export), moving the boundary between sessions in a multisport file, and cropping/splitting a recording.
After any of these, the original session/lap HR (and speed/cadence/power) aggregates are obviously stale, so I recompute avg/max by re-scanning the record window rather than trusting the device-written values.
Two things I'd like a sanity check on from people who've been deeper in the profile than I have:
1. Lap→session linkage: I'm matching a lap/length to its owning session purely by timestamp overlap against the session's window, since there's no explicit foreign key from lap/length to session in the profile as far as I can tell. Is that the right assumption, or is there an index-based chain (message_index/first_lap_index/num_laps) that's meant to be authoritative instead, that I'd be wrong to ignore? I couln't figure it out.
2. Boundary rounding: when I split a lap that straddles a moved session boundary, I've had to add a ~1s tolerance because start_time is 1-second resolution while total_elapsed_time (which I use to derive an end timestamp) is sub-second, so a lap's recorded start and an adjacent session's derived end can disagree by up to a second for what's really the same instant. Is that a known quirk of the encoding, or something specific to how certain devices round on write?
Separately:
if anyone has a genuinely odd multi-session FIT lying around (COROS, Suunto, Wahoo, or a Garmin multisport structure that doesn't follow the usual swim→bike→run shape), I'd genuinely like to try my tool against it and see where it breaks. Free QA for me, and I'll tell you if I find anything wrong with the file too. Or if you want to do that yourself and let me know how it went you can find the tool in live beta at https://thesplit.fit
Thanks in advance for your help
Stefano