Calorie count is very slow to start, related to bad recordings

[Dogora]

Currently, I'm using v8.11 sourced from Github with Android 14 (LineageOS 21) on a Pixel 4a. The issue is worse now than when I was using v6.07 with Android 11 (same phone). I have no Google services on my phone (hence using Github to source the app).

To start a ride, I choose my profile, start recording with the main screen button, then pedal off. It can take anywhere from 1:45 to 2:30 (m:s) before the calorie count starts incrementing. With v6.07, it was consistently starting around 1 minute. Other meters work fine from the start, but I haven't checked them all.

Once the calorie count starts moving, it changes quickly to catch up so nothing is lost.

Definitely with v6.07, I found that if I turned off the phone screen before the calories started counting I would end up with a bad track recording. I have not tested this with v8.11 because I don't want bad recordings.

I'm more concerned with the bad track recording problem than a slow start to calorie count. I've been using the count as an indicator when I can turn off the screen to consistently get good recordings.

[Sublimis]

Please try with the latest version if possible, v8.32. We've updated the links and made the APK available from here.

Many improvements have been made since version v6.07, and v8.32 in particular includes one important fix for what we think was the main cause of this behavior, but it's hard to be sure about these things. If we're correct, screen off doesn't cause the problem (at least not in v8.11, not sure about v6.07), it's just loosely correlated with it. This also applies to calorie counting.

We haven't noticed any bad track recording since implementing the fix, but since this was a fairly rare event, more time and more testing would need to be done before it can be claimed to be 100% fixed. Your feedback on this is appreciated!

For calories, that's the metric with the longest latency, a minute or two sounds about right. We didn't bother implementing a shorter-latency version of the calorie count for display purposes, as we did for some other metrics. Between v6.07 and v8.11 the digital filter was also completely rewritten, so the latency difference doesn't seem out of the ordinary.

[Dogora]

Thanks for the new version. I'll try it soon, and risk a bad track by turning the screen off soon after starting. That's most important in the winter when I put the phone in my pocket to keep it warm.

I figured the calorie calculation took some time to ramp up. Thanks for the explanation.

[Sublimis]

You probably don't have to risk much, the problem becomes visible within a few minutes after starting, right? To protect yourself a little more, you can enable sounds, e.g. auto pause or tallies sounds, so if you hear sounds while driving you will know that everything is fine.

The conceptual difficulty is to prove that the problem is solved, because the question is how many problem-free rides are enough to claim that the problem is solved? We'll probably just have to be patient... And if the problem does not appear even once in a month or so, we'll consider it solved 🙂

[Dogora]

With v6.07, I would not know if a recording didn't work until after the fact. There was no indication of a problem during a ride - all meters worked normally.

I will say that v8.11 and Android 14 is working more smoothly overall, so I'm less worried. For example, when I finish a ride, the prompt to see history is much faster than it used to be. I take that as a good sign that tracks are being saved properly.

[Sublimis]

@Dogora, have you tried using v8.32 or newer?

[Dogora]

Yes, I have used v8.33 a few times now and it is recording fine with turning off the screen before calories start counting. I'll definitely let you know if I get a bum track.

I tried to install v8.32, but it's missing the file win/aarch64/libzstd-jni-1.5.6-9.dll so did not install. The file is in the v8.33 apk, so installed fine.

[Sublimis]

Oh, ok, thanks! It's possible that we removed the unnecessary dll from the v8.32 APK in an (unsuccessful) attempt to reduce the APK size below Github's 25MB limit.