[FIT File Issue]: Coros Dura FIT files upload successfully but no gear assigned in Garmin Connect

[nothingshocking]

FIT File Upload

i143723345.zip Zip file contains sample Coros generated .fit file and the modified version created by running the fit-file-faker script.

Prerequisites

• I have attached the original FIT file that fails to be recognized by Garmin Connect
• I have searched existing issues to avoid creating a duplicate

Source Platform

COROS

Other Platform (if applicable)

No response

Problem Description

When processing FIT files from a Coros Dura, the activity uploads to Garmin Connect successfully but no gear is assigned. Inspecting the original and modified files shows that Fit-File-Faker successfully rewrites the file_id record but only partially rewrites device_info the product and product_name fields are never updated, leaving Coros branding intact. Garmin Connect uses device_info for gear association, so nothing gets assigned.
For comparison, files from a Hammerhead Karoo 2 process correctly and show the expected Garmin device in Garmin Connect.
Original vs Modified device_info:
[file_id]
manufacturer: 294 → garmin ✅ rewritten correctly
garmin_product: → 3122 ✅ rewritten correctly

[device_info]
manufacturer: 294 → garmin ✅ partially rewritten
product_name: COROS DURA ❌ NOT rewritten (parser aborted)
← FitParseError: Invalid field size 1 for type 'uint32' (expected a multiple of 4)

Command Used

fit-file-faker i143723345.fit --upload

Error Output (if any)

No errors or warnings during processing. The only warning is the expected HTTP 409 conflict on re-upload because this activity was previously uploaded: 
INFO     Processing "i143723345.fit"
INFO     Activity timestamp is "2026-04-26T12:25:37"
INFO     Saving modified data to "i143723345_modified.fit"
INFO     Uploading "i143723345_modified.fit" using garth
WARNING  ❌ Received HTTP conflict (activity already exists)

The root cause looks to be a silent parse failure inside device_info. The Coros Dura writes a non-standard field with an invalid size for its declared type (uint32 with size 1 instead of 4), causing the parser to abort mid-record without surfacing an error.

fit-file-faker Version

2.1.5 (released 2026-04-26)

Operating System

Windows

Additional Context

Source device: Coros Dura
Target device config: Garmin Edge 830
Attached: i143723345.fit (original) and i143723345_modified.fit (Fit-File-Faker output) for direct comparison

[buhtuks]

I made my own research. I see in a modified fit file there is data left that point at Coros. developer_data_id manufacturerId field is 294. I think it is preventing Garmin Connect to assign a device to an activity.

Source device: Coros Dura
Target device: Fenix7x

[nothingshocking]

Hey @jat255, thanks for this tool, it's saved me a ton of manual fiddling. Quick update on this one.

I re-ran a Coros Dura file through 2.1.5 with -v this time, and I think I got the original diagnosis slightly wrong. I'd guessed the malformed uint32 field was causing a silent parse abort in device_info. Turns out that's not it, the parser actually makes it all the way through fine:

DEBUG    Field size (1) not multiple of type size (4), truncating to length 0

That repeats a bunch of times through the file but never aborts anything. So the real issue is narrower than I thought: the Dura's device_info record just never has a numeric product value to begin with, only a manufacturer code and a text product_name. Nothing for the rewrite to map to a Garmin product from:

DeviceInfoMessage Record: 5 - message.to_row()=['device_info',
    'timestamp', 1785916974000, 'ms', 'manufacturer', 294, '',
    'product_name', 'COROS DURA', '']
    (Manufacturer: COROS, product: None, garmin_product: BLANK)
  Modifying values
garmin_product: None
product: None
  New Record: 5 - message.to_row()=['device_info', 'timestamp',
    1785916974000, 'ms', 'manufacturer', 1, '', 'product_name', '', '']
    (Manufacturer: GARMIN, product: None, garmin_product: BLANK)

Ends up as manufacturer: 1 with an empty product and blanked product_name Garmin claim with no device behind it, which tracks with why nothing shows up as gear.

Also noticed file_id does resolve a real Garmin product (EDGE_830, 3122) in the same run, just under a field called favero_product instead of garmin_product, not sure if that's meaningful or just how fit_tool names things internally, but flagging it in case it's connected:

New Record: 1 - message.to_row()=['file_id', 'type', 4, '',
    'manufacturer', 1, '', 'favero_product', 3122, '', 'serial_number',
    2273337773, '', 'time_created', 1785916974000, 'ms']
    (Manufacturer: GARMIN, product: 3122, garmin_product: GarminProduct.EDGE_830)

Can send over a fresh FIT pair or the full verbose log if useful. No rush, appreciate you keeping this going.