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

Activity

1. nothingshocking

   added

   bugSomething isn't workingSomething isn't working

   fit-fileHaving to do with FIT files somehowHaving to do with FIT files somehow

   on Apr 29, 2026
2. buhtuks commented on May 8, 2026

   

   buhtuks

   on May 8, 2026

   More actions

   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
3. nothingshocking commented on Sep 13, 2026

   

   nothingshocking

   on Sep 13, 2026

   Author

   More actions

   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.
4. nothingshocking

   added a commit that references this issue on Oct 19, 2026

   fix: mark rebuilt device_info as creator device (jat255#80)

   e64239d
5. nothingshocking commented on Oct 19, 2026

   

   nothingshocking

   on Oct 19, 2026

   Author

   More actions

   Follow-up with a root cause and a tested fix: PR #86

   Root cause (refined from my September update)
   The DURA's device_info record carries only manufacturer (294) and a text
   product_name. It has no numeric product, device_index, serial_number, or
   source_type. Two things in fit_editor.py combine to leave it blank:

   1. The rewrite only overwrites product when it is already present
      (if message.product is not None:), so for the DURA it is skipped.
   2. Removing that guard doesn't help on its own: a parsed message's fields are bound to
      the source definition, so assigning product raises Field is not growable.

   Even with a product set, Garmin Connect still showed no device until the record was
   also marked as the creator (device_index=0).

   Fix in the PR
   When a device_info record being modified has no product, rebuild it as a fresh
   DeviceInfoMessage (the same approach as the FileIdMessage rewrite), set the target
   product, and fill device_index=0, source_type=local, and serial_number if they
   are missing. Records that already have a product (e.g. Hammerhead Karoo) are unchanged.

   Verified on real hardware

   • Re-uploaded a DURA ride from Aug 4, 2026: before the fix, no device in Garmin Connect;
     after the fix, it shows Edge 830.
   • Karoo uploads behave as before.
   • Two regression tests added; the existing suite passes, apart from one
     test_show_dirs test that also fails on unmodified main in my environment.

   I'm now running the patched build in my daily sync pipeline and will report back if
   anything else turns up.