That’s good. We are pretty sure it’s related to other activities happening on your phone that use power. I am trying to research this. There are lots of articles on how to reduce the chances of this happening (phone slowing even iPhone 14 pro max can have this) by changing settings. But ultimately it’s the combination of our app using a lot of resources and then when something else kicks in we don’t have a enough processing power to do everything within a specific second so it starts getting behind. We always try to speed up if it gets behind, but millisecond offsets but it’s still not possible to keep up. We need to do something more drastic.
Otherwise I would like an Iphone Pro Max 12 offered by TrainerDay 
1 Like
Yeah since we are not capable of pedalling indoors for more than 90 minutes the only way we can test this is by inserting your guys data and it’s not a data problem. We can also walk around the house and sit at the computer for 3 hours with a HR strap on though 
We just can’t reproduce this.
And with fast phones like iPhone 13 or Pixel 6 it’s not a phone performance problem unless the phone is slowing down to do something else.
Hi. Like others here I’ve been having this issue since the start but also like others I’ve noticed it get worse with the last couple of updates. I dual record with my Garmin and can see the slowing down happen in real time at about the hour mark. TD slowly starts falling behind real time loosing maybe 2/3 seconds a minute and then it very quickly accelerates (I notice it more at the end of segments I think) and within a few minutes it’s basically ground to a complete holt with nothing responding so becomes completely unusable.
I’m running an iPad Air 2 with iPad OS 15.8. and the latest TD app. The iPad is obviously very old but it’s a very capably machine running arcade type games excellently (although maybe it’s optimised for this and not TD’s use case) However, the iPad is literally permanently set up just for TD and is plugged in all the time and just has TD on it plus a few stock apple apps you can’t delete. I’ve taken to hard resetting it before I start a TD session to ensure everything is clear and fresh but that doesn’t seem to help.
Apologies but I have nothing constructive to add other than it happens to me (albeit on slightly old kit) and it’s terminal to every one of my sessions now.
I’m thinking of splitting all my sessions into smaller ones to keep them under an hour or 45 mins but this seems a bit silly so anything you can do would be much appreciated obviously
Hi, sorry to hear, Video game performance vs what we use is “react native” can’t really be compared. We are a lot farther from the core machine operations so performance is less about what we do and more how react native optimizes. We went this route because it allows us to have considerably lower costs but as we all see now has downsides. I would have never expected an app like this to have performance problems but I am seeing even TR with all their money their app frequently crashes after 2 hours. I believe they have native apps.
Anyway, it’s hard to see this but we believe we have a good base now for stabilization of performance. We believe actually a lot less people are affected but still as you pointed out some are affected worse. We are still actively working on this and hope to improve it even more soon.
I assume you did a workout in the last couple days, can you send a link to one of your activities?
This morning another 2 hours workout and no problem …
The problem seems quite random
1 Like
Hi, I encountered the same issue on an iPad Pro after 58 Minutes. iPad was on charger, no app switches have been made during the workout.
I really like your app, but this is a serious issue and I think it’s caused by a wrong implementation approach. I am a software developer with some experience in app development and I think that maybe you have chosen the wrong approach to get the data from the trainer and tag it with the correct timestamp. Additionally, I don’t really see why it is so difficult to show the correct value for the time spent in the workout even if the device is under heavy load. Maybe you don’t have the chance to update the display every second, but if it’s updated eventually it shouldn’t be a problem to show the correct time then - even if one or two seconds have been skipped.
Hi, this is javascript, assuming you know javascript, there is no time stamp accurate 1 second interval accuracy. setTimeout(…) is approximately 1 second so every second we have to make millisecond adjustments, and what happens is peoples phones / devices slow down to the point that it takes longer than 1 second to do all the processing required (as you mentioned).
Trust me I am software developer since 1978 including years at MSFT and managing big teams. I know a bit about programming. I have worked with thousands and my guys are really good programmers.
I ran it yesterday on my iPad Mini V1 which is incredibly slow for 1 hour and it was accurate to the second. All our devices are 100% second accurate, it’s just something random that happens in specific devices that slows them down for some reason. There is lots of stuff on the internet about iOS devices slowing down randomly. I assume Android is the same.
Yes this idea of “skip seconds” is absolutely the same as what I have been telling my developer we need to do. So you are right on there. We really thought we could speed it up to the point we would not need to “hack it” but now it appears that is the best solution.
I haven‘t had this problem yet. But I usually do maximum 90 minute workouts.
I think @cyber-nico meant that the apprach of implementing the App web-based was not optimal regarding the timer.
I don‘t really know much about web and app programming, my background is more in embedded programming. And there these timer things would relatively easy to handle, because embedded programming supports real-time capability. This is of course completely different with web apps, where there is no real-time support at all I think. There is a list from Mozilla as to why setTimeouts could take longer than specified:
When I read that there, I imagine it would be difficult to even determine that a second is not being observed, you would need a higher-level watchdog that determines that the setTimeout event is simply too late.
And of course, I don‘t know if it would be easier, if you had developed a native app. It‘s much more than only that real-time thing, I estimate you need the bluetooth stack, and many other things, too, which could be harder to implement.
Hope you can fix it, even I had no issues so far
Yes, I am aware of the inaccuracy that you have to face when using setTimeout. But you can get the current system time perfectly accurate even with java script. And that’s why my approach would be to poll the trainer or the heart rate monitor with the (inaccurate) setTimeout function, but within the callback I would get the current time and compute the time spent since the last reading with respect to this value and not rely on the delay passed in setTimeout.
This approach is for example also discussed in Creating Accurate Timers in JavaScript — SitePoint and javascript - setInterval timing slowly drifts away from staying accurate - Stack Overflow.
Probably a reliable solution in your case is not as easy as stated in the above discussions, and I understand that it is not easy to fix if you cannot reproduce the issue on your devices. So please don’t get me wrong, I am quite sure your developers are very capable (otherwise your app wouldn’t be that good in all other aspects) and you have spent a lot of effort in solving the issue. But I cannot believe that the issue is not resolvable with reasonable effort.
Yes but this is the much more expensive route and we never expected these problems and never saw any performance issues during the first year. Now we have 100X more users than then so we get a lot more user feedback Maintaining 2 and eventually 4 or more apps we would need a much bigger team and change 20$ / month like some other apps
Yes this is exactly what we do now. The problem is if the device can’t keep up, it can’t keep up. We also can’t replicate this issue, all our devices have no problem, we insert 6 hours of data and it runs for an hour and is always accurate to the second. We have thousands and thousands of customers and very few mention this issue (other than a recent bug we introduced that cause more people to have it but that was fixed in a few days). Now more could have it but don’t notice. And most people do < 90 minute workouts which you are the first person to mention this issue < 60 minutes.
Since it appears now even fast devices randomly get really slow for some reason (they are temporarily slower than an iPad mini V1) We are going to implement as we suggested, if it gets 10 seconds behind we will skip forward a second each second until it it is under 10 seconds behind, as the device speeds up, that 10 seconds should get back to 0.
One interesting thing we just noticed is our app uses a lot more energy (battery usage), when we broadcast data every second to the server. It’s just the nature of high cell/wifi use it seems.
I wonder how many people have this turned on? We are thinking it is possible this energy usage could contribute slow downs.
I understand that there is no easy solution when the device is not able to do all the processing within the given interval time. Maybe you can increase or decrease this time dynamically on basis of the time spent between two polling intervals. Also you should be able to always show the correct time spent in the workout when computing it just before rendering it on the screen.
And even more important: when you generate the record for the TCX file it seems that you stamp it with the wrong time. The last record of my TCX file was tagged with 2023-11-09T17:49:12.947Z even though the clock on my iPad showed 17:51 at this time. The workout lasted in fact 62 minutes, but the TCX records went from 2023-11-09T16:49:12.947Z to 2023-11-09T17:49:12.947Z. So the resulting TCX file compressed 62 into 60 minutes and in Strava a 62 minute workout is shown as a 60 minute workout.
For Z2 this is not an issue, but nobody likes to have V02Max Intervals even two seconds longer than planned 
Yes this is exactly how it works (millisecond adjustments to settimeout ever second). We just store an array of seconds, power, cadence, hr… We don’t store the time stamps and when we create the data for strava or our system it’s any array of 1 second elements (millisecond adjustments to settime out every second).
Again increasing storage and processing required for a rare issue is not ideal, especially when trying to keep costs down. Also we don’t currently do post workout processing so it would not help but in the future that could be another way of solving it. I hope this skip second (which means inserting extra seconds) just solves the issue. We just make a change in new builds which takes a week or two as there is always other stuff going on as well. It takes a week or two get get feedback if we solved it so ultimately each time it’s a month cycle. We make a fix and people come back and say yes, now it’s great And then someone else eventually shows up and says, I still have an issue…
Yes, we need to cut the time down so they are shorter and the VO2max intervals feel easy, and we have a “great” workout Also I am hoping people (you) are not doing > 60 minute VO2max workouts and this is the first time anyone had a timing issue < 60 minutes at least that they noticed.
This would of course consume much more power. I have checked the setting immediately. But it’s disabled on my iPad.
One additional information: I think that in my case the delay began in the last two minutes of the workout. I was doing a 60 minute HR based workout and I reduced the target heart rate at minute 58. Immediately after pressing the button to decrease the target heart rate I noticed that the remaining workout time began to lag. The last 2 minutes of the workflow have been stretched then over 4 minutes.
That’s strange that it was triggered by you doing something. Really these issues are just 100% unpredictable and we try everything we can on the slowest device possible and can’t reproduce it.
I have had this issue at least a couple times.
Most recently last night 60 z2 workout, started happening after about 35/40 min.
Sorry to hear. What device do you have?