# Intervals.icu messes up fit lapdata

**URL:** <https://forum.intervals.icu/t/intervals-icu-messes-up-fit-lapdata/127532>\
**Category:** Bug Reports\
**Created:** [18 April 2026 18:44 UTC](https://forum.intervals.icu/t/intervals-icu-messes-up-fit-lapdata/127532 "2026-04-18T18:44:31Z")\
**Posts on this page:** 1\
**Showing post:** 10

<div class="post-metadata">

**Author:** ![Jaap\_van\_Ekris](https://forum.intervals.icu/letter_avatar_proxy/v4/letter/j/49beb7/32.png) [@Jaap\_van\_Ekris](https://forum.intervals.icu/u/Jaap_van_Ekris)\
**Post date:** [19 April 2026 20:04 UTC](https://forum.intervals.icu/t/intervals-icu-messes-up-fit-lapdata/127532/10 "2026-04-19T20:04:07Z")

</div>

> [@R2Tom](#):
>
> In my opinion, it’s superior to do the “live” calculation and not use summary fields.
> 
> 1. Any fixes made to the data will be applied
> 2. The user can change the laps duration and the summary will reflect that (how often do I press too late or early that button….)
> 3. You can build lap values (average), that are not written by the app/device, so basically any average of any stream which is present.

I think it should always start from what the device has delivered, without modification. If you want to move a lap position, that is your deliberate decission. But just throwing away upstream data without any cause is a huge no-no for me.

One of the key reasons is that you don’t have access to the underlying data, so you can only mess up perfectly good data. For example: in rowing, average force is the average over distance, not over time. But a standard FIT-file does not contain that distance (drive length). So even if you knew you should be using distance instead of time, you can’t calculate it. Nor does a standard FIT-file contain the drive time, so it is an academic discussion regardless.

And this is the case for most summary fields: as downstream consumer you lack the underlying data, so it is pretty hard to reconstruct what you should be summarizing.

And a 500 meter split is a 500.00 meter split. Not 22 meters (i.e. two full strokes!) earlier or later. The stupid thing is, OpenRowingMonitor actually injects records at these exact boundaries (so there is a record for exact 500m), so even when fields are recalculated, it is executed extremely poorly.

---

_[View the full topic](https://forum.intervals.icu/t/intervals-icu-messes-up-fit-lapdata/127532)._