[Solved] - Timer Related Issues

That’s terrible. Thanks for sharing. We will definitely fix this. It’s so strange for 95+% of the people and 99% of their rides it works perfectly but one experience like this just destroys confidence. As mentioned this type of issue is mostly older devices but I know that does not matter to the person with the problem and we want to support older devices.

Hi Alex,
Relatively new to the app. I did a 90min trainer session on Sunday and it was a difference of 11 minutes compare to my Garmin. I was using iphone 12 and with the latest IOS version.
What can I do to resolve this?

Thanks

@alex I think there is more going on then performance issues of the devices. What comes back on regular bases is that some sort of interruption happened on the phone and then the app goes crazy. Might be a phone call, a social media message, or similar.

For now a phone restart and limit background activities and putting the app in the background but we are working hard to resolve this right now and can hopefully have something to resolve it in the next week or so.

Yes, I agree something strange. We will find it. Do you have any issues?

Had this one a couple weeks ago:

Oh yes, thanks for the reminder.

Thanks for your work! If it works fine (as it has most of the time I used it) it is the best App out there, as it exactly fits my needs!

1 Like

i had this issue last night: was controlling my tacx neo v1 from my iphone 13 pro. seen it a few times before but not this bad:

time was really dragging, every second was taking several seconds which was very painful on the harder intervals. then after an epic grind it went crazy fast for the rest of my ride. the final 5 min interval then 10 minute cooldown went by in one or two minutes.

looking at the graphs on strava it doesn’t show anything overly odd with the ride. says total ride time was the 2:10 tho i’m sure it was much longer. started at 9:55 but finished at 12:30. so workout actually took around 2:35.

Sorry to hear. Crazy on 13 pro. We are working on multiple solutions to this right now. It’s something related to device performance, low battery is an example, but obviously it’s a problem that needs to be solved with our app.

It would feel less bad if the .fit or .tcx that came out at the other end was based on reality. i.e if it used legit timestamps instead of the timewarped versions.

FWIW my phone sits on a charger while i ride, so it’s not low battery or in a power save mode. I often notice the last second of a ride often takes a long time, maybe related.

That’s a good idea/point. We have like 20 phones and tablets on our team and we can never replicate this problem. If we could replicate it it would be so much easier to solve. We keep thinking we have solved it when we have not. I did not realize the files did not match reality but now that I think about it I completely know why. Yes we could do some post processing to inject the missing seconds.

I’ve done quite a lot of hours riding with the app and other than the last second or two of rides i’ve only noticed it on a couple of other occasions, so not really surprising that it’s hard to replicate.

If you could use system timestamps instead of the “workout time” it might shed some light on things. esp when there is a big difference between the two. It was definitely weird seeing the last 15 minutes of that workout flying past in a couple of minutes. That happened other times i’ve noticed it too, like it wants to get the time back in sync all of a sudden.

Trainer Day is the activity I’ve been talking about btw, feel free to mess around with the data if it helps.

So the way this works is we progress “1-second” at a time. Every time we move forward 1 second we check the elapsed time and make a micro adjustment in milliseconds to try to catch up or extend it. So we actually do what you are suggesting. What we believe the problem is that a persons system can’t do all the required processing in 1 second so even though we are trying to catch up we can’t. We are are fairly sure the re-drawing of the chart is the performance problem so right now we are changing chart drawing technologies to something more native to the device and faster. Hopefully this solves the problem. If it doesn’t the next step we realized we could do is if the system gets to a point that it can’t catch up we could just drop a second to catch back up. That is our new “revelation” to a sure fix.

Finally as you suggest we can record time stamp with each second and at the end do a clean up process to make sure the output file matches what you did.

That is a serious workout wow you are tough. :slight_smile:

This has now become our absolute top priority to fix before this winter and we are 100% sure we will fix it one way or the other.

I do like to do some longer rides to catch up on movies, and I wonder if they are more likely to trigger this.

Not sure if it’s just the charting causing it to get behind in my case. My suspects are bluetooth being weird, or incoming notifications in the background causing the initial desync. Then I think once it gets out of sync it seems unable to recover.

The weird thing is for most of the ride it’s slowing me down, which makes me think that it thinks somehow i’ve gotten ahead of where I should be. Then the weird turbo speed bit at the end seems to indicate it can go a lot faster when it wants to.

How about checking the elapsed real time vs how long the interval has been running for and declaring time bankruptcy as soon as we hit the point where the interval should have finished. Or I guess conversly extend it if we get to the end of the interval but not enough real time has elapsed. Then at least if things get out of sync it’d only be for one interval of the workout but the overall interval and workout lengths would be correct.

Another option might be to stop redrawing the chart whenever we get out of sync until things are back on track.

I’m happy to run a debug build if that’d help track it down. Occasional whacky interval times are still better than my garmin crashing in the middle of a workout :stuck_out_tongue:

Yes there seems to be a direct relationship between longer efforts and this problem. Yes this speeding up is our algorithm in process when things get behind.

And yes, I think notifications and extra background processes are a likely cause of triggering it but since it usually seems to happen more towards the end it would seem it should be performance related (our theory is that it it’s because a lot more data points are plotted), but your phone is so fast it’s an interesting case. I have an 11pro and have never seen this but I have zero notifications and very little running in the background. I also rarely do long workouts but I have and my team has run tests for 2 hours many times and never see anything. We even put the app in the background for these tests and if it does slow down it just speeds back up to fix things.

Ok let me work with my developer and this debug option might help at least to test our potential fixes.

Hi guys to give an update. My app developer (Grigory) has re-written our charts from CPU based to GPU based and he can see that our CPU processing in the old version was 95% chart re-drawing and in new version is 0% and very low CPU usage. We have high hopes this will solve this timing issue the right way. Should be another week or at the most two until this is available.

Interestingly, that’s what I was doing yesterday… moving BreakAway: Indoor Training charts line drawing from CPU based to GPU based. It really helped immensely on my Ipad Mini 2 (year 2013) as compared to when it was running on a newer phone like the iphone 11.

This would definitely help w/ the timing issues on the TD App.

Thank you very much. I used the new version yesterday and it worked as months ago, flawless. Not only the intervals but changing the chart scaling is reacting immediately with no delay.

This seems to be all resolved finally.