Moving and total time reset several times during activity

[brianjmurrell]

Describe the bug During an indoor (GPS off) activity, I noticed that the timer(s) reset to 0 during the activity. At the end of the 1hr activity, the total time was only 38:43.

To Reproduce Unknown

If applicable:

• add screenshots
• add logcat output

Technical information

• Device: Oneplus 6
• OS: LineageOS 18.1
• OpenTracks version: v3.26.1-17
• OpenTracks commit id : 0f489f1cc +

  
  diff --git a/src/main/java/de/dennisguse/opentracks/io/file/exporter/GPXTrackExporter.java b/src/main/java/de/dennisguse/opentracks/io/file/exporter/GPXTrackExporter.java
  index 15ef7124e..c2bb35a8c 100644
  --- a/src/main/java/de/dennisguse/opentracks/io/file/exporter/GPXTrackExporter.java
  +++ b/src/main/java/de/dennisguse/opentracks/io/file/exporter/GPXTrackExporter.java
  @@ -358,8 +358,9 @@ public class GPXTrackExporter implements TrackExporter {
                   trackPointExtensionContent += ("<opentracks:loss>" + ALTITUDE_FORMAT.format(cumulativeLoss) + "</opentracks:loss>\n");
               }

• cumulativeDistance = Distance.of(cumulateSensorData(trackPoint, sensorPoints, (tp) -> tp.hasSensorDistance() ? tp.getSensorDistance().toM() : null));
• if (cumulativeDistance != null) {
• Double cumulativeDistanceDouble = cumulateSensorData(trackPoint, sensorPoints, (tp) -> tp.hasSensorDistance() ? tp.getSensorDistance().toM() : null);
• if (cumulativeDistanceDouble != null) {
• cumulativeDistance = Distance.of(cumulativeDistanceDouble); trackPointExtensionContent += ("" + DISTANCE_FORMAT.format(cumulativeDistance.toM()) + "</opentracks:distance>\n"); trackPointExtensionContent += ("" + DISTANCE_FORMAT.format(trackDistance.plus(cumulativeDistance).toM()) + "</cluetrust:distance>\n"); } diff --git a/src/main/java/de/dennisguse/opentracks/sensors/BluetoothConnectionManager.java b/src/main/java/de/dennisguse/opentracks/sensors/BluetoothConnectionManager.java index 2c55cac04..962b8cbbe 100644 --- a/src/main/java/de/dennisguse/opentracks/sensors/BluetoothConnectionManager.java +++ b/src/main/java/de/dennisguse/opentracks/sensors/BluetoothConnectionManager.java @@ -107,7 +107,6 @@ public abstract class BluetoothConnectionManager { @Override public void onCharacteristicChanged(BluetoothGatt gatt, @NonNull BluetoothGattCharacteristic characteristic) { Log.d(TAG, "Received data from " + gatt.getDevice().getAddress());

•      SensorData<DataType> sensorData = parsePayload(gatt.getDevice().getName(), gatt.getDevice().getAddress(), characteristic);
       if (sensorData != null) {
           Log.d(TAG, "Decoded data from " + gatt.getDevice().getAddress() + ": " + sensorData);

  diff --git a/src/main/java/de/dennisguse/opentracks/sensors/BluetoothUtils.java b/src/main/java/de/dennisguse/opentracks/sensors/BluetoothUtils.java index d3120843b..9e5f55493 100644 --- a/src/main/java/de/dennisguse/opentracks/sensors/BluetoothUtils.java +++ b/src/main/java/de/dennisguse/opentracks/sensors/BluetoothUtils.java @@ -48,7 +48,7 @@ public class BluetoothUtils {

  public static final List HEART_RATE_SUPPORTING_DEVICES = Collections.unmodifiableList(Arrays.asList( BluetoothUtils.HEART_RATE_SERVICE_UUID,

• //Devices that support HEART_RATE_SERVICE_UUID, but do not announce HEART_RATE_SERVICE_UUID in there BLE announcement messages (during device discovery).
• //Devices that support HEART_RATE_SERVICE_UUID, but do not announce HEART_RATE_SERVICE_UUID in their BLE announcement messages (during device discovery). UUID.fromString("0000fee0-0000-1000-8000-00805f9b34fb") //Miband3 ));

@@ -165,6 +165,11 @@ public class BluetoothUtils { index = 3; if (valueLength - index >= 1) { cadence = Cadence.of(characteristic.getIntValue(BluetoothGattCharacteristic.FORMAT_UINT8, index)); +

• // Hacky workaround as the Wahoo Tickr X provides cadence in SPM (steps per minute) in violation to the standard.

• if (sensorName != null && sensorName.startsWith("TICKR X 4150")) {

• cadence = Cadence.of(cadence.getRPM() / 2);

• } }

   index = 4;

  diff --git a/src/main/java/de/dennisguse/opentracks/services/handlers/TrackPointCreator.java b/src/main/java/de/dennisguse/opentracks/services/handlers/TrackPointCreator.java index d6dc2da6e..58d682b0d 100644 --- a/src/main/java/de/dennisguse/opentracks/services/handlers/TrackPointCreator.java +++ b/src/main/java/de/dennisguse/opentracks/services/handlers/TrackPointCreator.java @@ -119,15 +119,19 @@ public class TrackPointCreator implements BluetoothRemoteSensorManager.SensorDat */ @Override public void onChange(SensorDataSet sensorDataSet) {

• onNewTrackPoint(new TrackPoint(TrackPoint.Type.SENSORPOINT, createNow()));

• synchronized (this) {

• onNewTrackPoint(new TrackPoint(TrackPoint.Type.SENSORPOINT, createNow()));

• } }

  public synchronized void onNewTrackPoint(@NonNull TrackPoint trackPoint) {

• fill(trackPoint);

• synchronized (this) {

• fill(trackPoint);

• boolean stored = service.newTrackPoint(trackPoint, gpsHandler.getThresholdHorizontalAccuracy());

• if (stored) {

• reset();

• boolean stored = service.newTrackPoint(trackPoint, gpsHandler.getThresholdHorizontalAccuracy());

• if (stored) {

• reset();

• } } }

diff --git a/src/main/java/de/dennisguse/opentracks/stats/TrackStatistics.java b/src/main/java/de/dennisguse/opentracks/stats/TrackStatistics.java index daa81800e..0da3ac100 100644 --- a/src/main/java/de/dennisguse/opentracks/stats/TrackStatistics.java +++ b/src/main/java/de/dennisguse/opentracks/stats/TrackStatistics.java @@ -16,9 +16,12 @@

package de.dennisguse.opentracks.stats;

+import android.util.Log; + import androidx.annotation.NonNull; import androidx.annotation.Nullable; import androidx.annotation.VisibleForTesting; +import android.util.Log;

import java.time.Duration; import java.time.Instant; @@ -232,7 +235,12 @@ public class TrackStatistics { }

 public void addMovingTime(TrackPoint trackPoint, TrackPoint lastTrackPoint) {

• addMovingTime(Duration.between(lastTrackPoint.getTime(), trackPoint.getTime()));
• //TODO Remove try catch; just for debugging #1151 race condition
• try {
• addMovingTime(Duration.between(lastTrackPoint.getTime(), trackPoint.getTime()));
• } catch (RuntimeException e) {
• Log.i(this.getClass().getSimpleName(), e + "\n: LastTrackPoint: " + lastTrackPoint + "\nTrackPoint: " + trackPoint, e);

• } }

  @VisibleForTesting(otherwise = VisibleForTesting.PACKAGE_PRIVATE) @@ -379,4 +387,4 @@ public class TrackStatistics {

  • "; Altitude Gain: " + getTotalAltitudeGain()
  • "; Altitude Loss: " + getTotalAltitudeLoss() + "}"; } -} \ No newline at end of file +}

    
    Which is more or less just the PRs for the other of couple of issues I have open.

Indeed, the GPX file has a number of trksegs in it with some disturbing gaps:

<time>2022-04-10T14:44:34.649-04:00</time>
...
</trkpt>
</trkseg>
<trkseg>
...
<time>2022-04-10T14:51:13.642-04:00</time>
...
<time>2022-04-10T14:54:10.647-04:00</time>
...
</trkpt>
</trkseg>
<trkseg>
...
<time>2022-04-10T14:59:42.632-04:00</time>
...
<time>2022-04-10T15:00:45.647-04:00</time>
...
</trkpt>
</trkseg>
<trkseg>
...
<time>2022-04-10T15:04:15.642-04:00</time>
...
<time>2022-04-10T15:07:38.644-04:00</time>
...
</trkpt>
</trkseg>
<trkseg>
...
<time>2022-04-10T15:10:10.639-04:00</time>
...
<time>2022-04-10T15:17:48.632-04:00</time>
...
</trkpt>
</trkseg>
<trkseg>
...
<time>2022-04-10T15:21:26.642-04:00</time>
...

I'm fairly sure the app continued running through those fairly large gaps. I'm fairly sure I would have noticed at least one of those.

There is nothing in logcat between those gaps though.

[dennisguse]

Were you using the TICKR X? And can you check the KML? There are same workarounds for GPX in place.

[dennisguse]

@brianjmurrell :point_up_2:

[brianjmurrell]

Were you using the TICKR X?

Yes.

And can you check the KML?

Check it for what exactly?

There are same workarounds for GPX in place.

But to be clear, the multiple segments in the GPX are just a symptom and confirmation of what I saw on the display during the activity and that's that the timer for the activity reset back to zero during the activity -- a number of times.

So this is not a GPX export problem. This is an activity-timer-reset problem. Just in case I had confused this issue with the GPX aspect of it.

[dennisguse]

Thanks. In the GPX the TrackPoints are merged together that do not have a GPS coordinate as GPX doesn't allow this - and this merging might lead to the generation track segments (as the max. recording distance threshold is reached).

If you export the data as KML/KMZ, you get the actual TrackPoints that were recorded. And it would be interesting to see "original" data (technically, we might still be missing things as those were ignored) as it allows to investigate the issue.

And I would love to see a screen recording.

In theory, we do not have any timer - so there might be some other effect that we do not want to have.

[brianjmurrell]

The KML shows multiple tracks:

...
        <gx:Track>
          <when>2022-04-10T14:44:02.913-04:00</when>
...
        <gx:Track>
          <when>2022-04-10T14:51:13.642-04:00</when>
...
        <gx:Track>
          <when>2022-04-10T14:59:42.632-04:00</when>
...
        <gx:Track>
          <when>2022-04-10T15:04:15.642-04:00</when>
...
        <gx:Track>
          <when>2022-04-10T15:10:10.639-04:00</when>
...
        <gx:Track>
          <when>2022-04-10T15:21:26.642-04:00</when>
...

And I would love to see a screen recording.

Of what? The time resetting back to 0 during the activity? That would be difficult. I didn't even see it, the moment it reset. I only noticed some time after that the time was less than it was when I last looked.

In theory, we do not have any timer - so there might be some other effect that we do not want to have.

Well, there is a timer timing the length of the activity from start to end. That's the timer I am referring to.

[dennisguse]

It looks like as some if the TrackRecordingService crashed and that due to an onResume() in the TrackRecordingActivity (e.g., it went into background and back into foreground or the display was turned off and on again) started a new track.

~~And this functionality is implemented and it must be replaced for #1103. Now the question would be: what could cause the crash like this?~~

[dennisguse]

@brianjmurrell forget what I said. A gx;Track is also just a segment. And a new segment is created, if the distance was larger than the threshold (default 200m).

And now the magic: speed/distance sensors (cycling as well as running) have a monotonic counter (some reset on standby; some never). During recording, OpenTracks receives this absolute and makes it relative to the first received data in this recording. So, if the sensor is running it will accumulate the distance and if OpenTracks is not (a) accepting [e.g., standby, etc] or (b) not storing, it will be stored when OpenTracks reconnects (and the recording is still running).

As the sensor does the distance storing, it will not affect the distance. Moving time will way below the expectation as less TrackPoints were actually stored (and only stored once are used for computing track statistics).

Why the UI reset to 0 sometimes and the overall time is less than expected, I don't know. Probably some (usually hidden) bug in TrackStatisticsUpdater.

Best guess: some Android power management issue. https://dontkillmyapp.com/

[brianjmurrell]

The one thing it is NOT is Android power management. The phone's screen was on with OpenTracks as the active application for the entire duration of the activity, while the phone was sitting in front of me on the treadmill console when this happened.

[dennisguse]

Then I don't know what the reason - just that the sensor did not send or they disconnected. Not really sure what to do about it then.

[dennisguse]

@brianjmurrell Any more insights here?

[brianjmurrell]

Not really. I have not seen it happen since the one time. Maybe I'll close this and can re-open if it recurs.