Feedback on Run Tags and Moving Time/Pace Calculation

Strava,

What is the difference in tagging a Run Activity as one of these Run Types?

1) Run

2) Race

3) Long Run

4) Workout

5) Treadmill

The one difference I see is that by tagging a Run as a Race, Strava modifies the Pace to be the actual Pace instead of the Moving Pace. On all other tagged Run Types, the Moving Pace is used for mile splits (but labeled as Pace). Also, the Elapsed Time is shown at the top of the overview in large vs small font and presumably calculates the pace from the Elapsed Time.

 

1) I don't see any KB Articles on Run Types, so please elaborate on them

2) Strava should not be using Moving Pace on Run mile splits - its misleading and not accurate. If Strava wishes to display the Moving Pace vs the actual Pace, then Strava should label it as such.

3) I should not have to switch my run to a Race just to see the actual Pace mile splits.

4) IMO Strava should not even use Moving Pace, its not useful. But if they wish to use it, it should be labeled so people are not confused if it is a Moving Pace or the regular Pace. By tagging a run as Race vs Run we are somehow suppose to know that the Pace has been changed from Moving Pace to Pace? Just label the Pace always and show both. For mile splits, GAP and Moving Pace (labeled as just Pace, misleadingly) are of no interest and the true Pace is not shown (unless the run is tagged as a Race)!

 

Strava - please straighten out your usage of Moving Pace. We need to see our real pace for mile splits - not a massaged # that looks great even if we stopped at every drinking fountain.

Also, on the Run overview page, the Moving Time shown is not the actual Moving Time, its the Time. Garmin defines the following times; Time, Moving Time and Elapsed Time. Strava is overloading the usage of Time and Moving Time. The label on the web page is Moving Time, but the value is Time. Change the label to Time. And in the mile splits, you do the opposite, label the pace as Pace when its really the Moving Pace. Both of these are misleading, and in the case of mile splits do not even have the actual Pace per mile. iPhone App displays Pace as Moving Pace with no option to see the actual Pace and does not label the Pace as Moving Pace either. This needs to be fixed too.

Quite simply - label the correct values - and show the real mile split Paces. Label Moving Time as Moving Time. Label Moving Pace as Moving Pace. Label Time as Time. Label Pace as Pace. And show the actual mile split Paces (not moving pace) despite how the Run is tagged.

 

connect.garmin.com labels these values correctly and includes both regular and moving times/paces.

 

 

 

96

Comentarios

217 comentarios
  • Moving time is fucking stupid!

    0
    Acciones de comentarios Permalink
  • It's just complete bullshit to only show moving time.
    How on earth am I able to compare my runs? How do I know which run was faster? I don't. Because sometimes I stop more frequently (my dog is stopping all the time. more red lights) - and thus I run faster inbetween because I had a recovery and some runs are completely smooth. 
    In the first case I run a whooping 6 min/km. In the other case a normal 7 min/km. So, what's my pace now? I'd say the second. And because of that I put every run I go on as "race" because otherwise Strava is just displaying useless and incorrect values.
    Just because I'm stopping doesn't mean I am not running anymore. This time shouldn't be removed. And if you really want to remove that, AT LEAST LABEL CORRECTLY AND LET ME DECIDE WHICH ONE I WANT.
    That's ridiculous and annoying as it is now.

    As long as this thing is as now, I will NEVER go premium. Because useless pace is useless.

    0
    Acciones de comentarios Permalink
  • Setting your activity as race only changes the title. All stats and comparisons and everything else is still using the useless and inaccurate so called moving time. We need more people making some noise about this. Strava seems to complete ignore this fundamental issue. Please all, send some bug/issue reports.

    0
    Acciones de comentarios Permalink
  • It has been years now.  Why not just add an option, a simple check box, "Detect stationary time: YES/NO" so that we can disable it if we don't like it.

    It's just silly when it gives us a speed faster than Mo Farah because of the false detection of vast amounts of stationary time.

    I still have to do the ritual of stopping and starting the watch again at some point during the run to disable the stationary time detection.

    Can't we have an option on the upload page to disable the detection, in case we forgot to do the pause ritual during the run?

    0
    Acciones de comentarios Permalink
  • Evaluating Strava and ran into this immediately, and it's a deal-breaker. At the very least show two sets of statistics: overall time and pace and moving time and pace. Moving on to something else....

    0
    Acciones de comentarios Permalink
  • Have cancelled my Premium Strava membership (I was up for renewal in 5 days).

    Garmin Connect has way better integration with my new Forerunner 920xt and I haven't run into any annoying bugs (yet).

    0
    Acciones de comentarios Permalink
  • Interesting how frequently this topic gets a life again.

    My most recent encounter was on a hike that went wrong after my wife tore ligaments in her ankle. We were moving really slowly on the descent and she was finally airlifted off the mountain.

    The total time for the activity was recorded as 4:05:42. When I first uploaded it and marked it as a hike it showed as 2:59:34. After she was airlifted I ran down and wanted to check my segment time but it didn't show because the activity type was incorrect. So I changed it to a run. The segment now showed and all was good (for the record I smashed a 53 second improvement on a 300m segment after being cooked in 40 degrees Celsius for 4 hours ;)

    Issue now was the run showed a time of 0:43:52 .... I mean really? I've left it as such because I'm happy my segment counts and I'll use it for future comparisons but its totally useless in terms of the activity time. Worse, on the mobile app only Moving Time is displayed, no Elapsed Time which really throws everything off.

    Once again, I was a premium member, cancelled that and still have no intention to renew.

    Vents aside, the social aspect of Strava is what keeps me on the platform. I use Garmin Connect if (outside of segments) I want to interrogate any part of my run \ cycle \ swim.

     

    0
    Acciones de comentarios Permalink
  • I'd like to know how the pace is even calculated because I just jogged at lunch and my strava upload from my iPhone says moving time of 24:26 for 2.2 miles with a pace of 10:44. So not even the math on this is correct. The elapsed time was 24:35 which would even be a slightly slower pace. How is it even calculating 10:44 as the pace?

    0
    Acciones de comentarios Permalink
  • How has this not already been dealt with? I seat raced this weekend doing 6x1500m, when we were switched out of the boat we were expected to do the 1500 on an erg. On uploading to strava, my activity has had about 40m (out of a 2.5hr session) removed entirely, and I'm missing the erg data because it was stationary. This isn't ok strava. The only way I can get this to work is by changing the activity type to running, and select race, which creates totally bogus stats for my running profile by treating rowing as a totally different sport.

     

    Don't make people upload modified data just to use your platform. It's an insult to your (soon not to be) paying customers.

    0
    Acciones de comentarios Permalink
  • I just came here to say I'm pissed about current 'moving pace' calculation.

    0
    Acciones de comentarios Permalink
  • I don't see Strava doing anything about this. They keep saying (to me) that moving time is what they want. But it's hopefully faulty and for many activities not working at all. I can only hope everyone submits individual tickets about this. Maybe that can do something? I wonder why anyone is paying for Strava with such bad support.

    0
    Acciones de comentarios Permalink
  • I'm amazed at how strava responds to it's users. People are telling them that the product isn't fulfilling their needs and they're turning around to say that they know better.

    I can't see myself keeping my premium subscription, though I get the feeling they don't care whether people keep paying their salaries or not.

    0
    Acciones de comentarios Permalink
  • This issue has been going on for years and nothing has been done. Why is it so hard to give us (the customer) the option of using elapsed time or moving time? Is adding a button so difficult? I'll bet the vast majority of people would choose the elapsed time option. Not happy and not going to renew unless it's sorted.

    0
    Acciones de comentarios Permalink
  • It would be good if each and everyone of you sent them this request / bug individually to Strava. Now I know they ignore us all even there (as it takes months for them to reply), but at least it's something.

    I don't know how they are still alive with such bad customer support.

    0
    Acciones de comentarios Permalink
  • Wow... can't believe this has been going on for so long. I recently started using strava importing my Suunto 2S runs. I only trail run, mostly on technical terrain where I often move slowly, so moving time given by strava is highly inaccurate and hugely inconsistent between runs e.g. my favorite run on beautiful Robberg reserve, a run in the open where GPS accuracy should be good -

    https://www.strava.com/activities/581412617/matched-runs

    I'm really interested to compare splits, but with the moving time pace splits given, it is utterly useless to think of doing so.  I'm now using Suunto's own movecount page to compare my runs accurately on actual time with each other and only use strava for the social aspects and for some loose idea (obviously because of moving time errors) of how I'm doing on predefined segments. 

    It boggles my mind that this has not been dealt with. I just thought that I was somehow overlooking the option to disable moving time but low and behold, it is impossible to do so. 

    So, I just thought I'll add my dissenting voice of incedulity at the fact that strava has not done anything about this. Lekker stupid as they would say in my native Afrikaans.

    0
    Acciones de comentarios Permalink
  • 3 years passed and nothing improved ?

    Seriously !?

    0
    Acciones de comentarios Permalink
  • This is a disgrace!
    Ow, my mistake, sorry. Let's not have pauses in our communication either.
    Thisisadisgrace!
    #movingtimeisuseless

    2
    Acciones de comentarios Permalink
  • Second this.

    0
    Acciones de comentarios Permalink
  • Well, this still goes on. I have python code which takes a gpx file and calculates an improved estimate of moving time from that data so that it matches what both my Garmin and RideWithGPS app give me within seconds. Hence, avg speed is also aligned. I'm not sure why Strava cannot get this right. The code simply

    1. Parses the gpx file and converts (lat, lon, elev) to (x,y,z) in ECEF (earth-centered-earth-fixed coordinates)
    2. Computes distances based on the sampled times
    3. Interpolates the distances to a fine mesh using cubic spline interpolation (not-a-knot)
    4. Computes velocities based on the smoothed distance data
    5. Drops times where speed < stoppedMPH (I used 2.0 mph, similar to Garmin pause settings that I use)

    When doing this, the moving time and average speed matches my Garmin device and RideWithGPS within seconds. When I download the gpx file from RWGPS and upload to Strava (a service syncs my RWGPS, Strava accounts automatically this way), I get an extra ~5 minutes and avg speed drops accordingly by about 0.4 mph on Strava. I have observed this for years [as evident by this SUPER-LONG thread], which is why I just wrote this very simply python application. PLEASE, Strava, take my code and fix your moving time calculation. It aint rocket science. Here is a link to the 3 source files - run analyzeGPX.py to show how it works. Compare it to https://www.strava.com/activities/780133812, which only has a 17.2 mph average. I'll even let you use my code, although I usually charge a fee for mathematical consulting ;) You can access the code, examples, and figure below at this cloud link.

    1
    Acciones de comentarios Permalink
  • Karl Rudnick, that is _not_ a solution

     

    Strava this is frankly embarrassing, that you have your members writing scripts to undo one of your 'features'.

    0
    Acciones de comentarios Permalink
  • As a follow-up, since the python code I wrote worked off the .gpx files, I also put together the corresponding code for .fit files, which are saved in the Activities/ folder on my Garmin Edge 800. The source is in the same folder if anyone wants to grab the code and run analyzeFIT.py and compare for themselves. It was a little simpler as the .fit files contain a processed speed (m/s). Still, I interpolated that to a fine time mesh prior to thresholding by the cutoff speed. Compare that run to the .fit upload to Strava at https://www.strava.com/activities/781261972 and you will see that Strava overestimates the moving time by about 4 minutes and so avg speed is about 0.2 mph slower.

    1
    Acciones de comentarios Permalink
  • Strava got back to me with this "There is nothing else I can do at this time". Just give up on Strava and go to other platforms.

    Or you can try voting this thread up so we get some numbers up. Open up new bugs about this, all of you! Flood them about this issue. It is rather embarrassing how they cannot handle this very basic and simple issue.

    1
    Acciones de comentarios Permalink
  • Lawrence Jones

    You misunderstood. I didn't mean to suggest that WE run scripts. I just thought that STRAVA needed to see that it's pretty easy to improve their moving time calculation algorithm to match other algorithms (for example, the RideWithGPS app) and Garmin devices (like my Garmin Edge 800). They evidently need some help. The algorithm in my code, which STRAVA is free to adopt, works just like the auto pause function on some of my bike computers, where moving time is not incremented below a certain speed. We members "could" set that speed threshold in a Strava profile setting, just as I can on some bike computers. It helps to smooth the data onto a fine mesh using interpolation to provide finer time granularity in determining how much time is spent "at rest." Since GPS measurements have a stochastic component, the actual data is "never" at rest. I'm not sure how many folks at STRAVA even work on algoritms like this, let alone actually follow this thread. This unbelievable thread may be so long that any suggestions for improvement go unnoticed. It IS embarassing that I only spent a couple hours knocking out the code, though.

    1
    Acciones de comentarios Permalink
  • Karl, most of the thread is about moving time and moving pace being wrong and misleading, at least when applied to running and especially trail running. I guess your primary activity is cycling. You mentioned that Strava overestimate moving time resulting in slower speed. Well in case of running Strava often underestimates moving time resulting in inflated, unrealistic pace. And for whatever reason Strava applies the same algorithm to hiking where we end up getting moving times that are half or less of actual times and speeds that are more appropriate for running. The algorithm is so bad that the slower you move over challenging terrain the faster your resulting "moving pace" might be according to Strava.

    Amateur runners only care about how fast they can run and Strava caters to their ego. Serious runners who want realistic data should not apply.

    0
    Acciones de comentarios Permalink
  • Yes, thank you for reminding everyone of that. When I first noticed the moving time discrepancy, along with many of my other cycling mates, I searched this Forum and landed on this thread. I really should have picked a "cycling" thread or started a new one.I think what people would like is a setting option, where either pauses are ignored (more for the runner) or time is ignored (more for the cyclist) when speeds are below a threshold. For cyclists, 3 mph is a good threshold but a poor threshold for runners, unless you're extremely fast ;)  Our group typically takes at least one rest stop during rides of 60-80 miles, so average speed gets diluted by how much food or fun we're having during those stops. Also, average speed is seriously affected by traffic signals if you add that time to moving time. Note that the Strava app distinguishes runners and cyclists in its auto-pause settings, but it looks like you don't have the kind of control one has on, say, a Garmin bike computer where you can set a custom speed to define auto-pause. My Garmin Edge 800 is set to pause at 3.0 mph, and when I use 3.0 mph in my simple-minded algorithm, the moving time matches the moving time on my Garmin 800. The moving times that Strava calculates when uploading from my 800 appears to use a threshold of 1.0 mph if I can guess what they're doing under the hood.

    So, thanks for putting my comments on point for this thread and I'll start a new one.  That may help grab Strava's attention. 

    0
    Acciones de comentarios Permalink
  • Karl, if you look back at my comment made at July 07, 2015 09:45 you'll see it is all still relevant to running.

    There are times when my old watch (Garmin Forerunner 110) would stop logging GPS points (despite there being no reason for it to lose the signal at those points) and Strava would rely upon the DistanceMeters attribute that appears in the .fit files. It would consider me stopped if this speed dropped below a certain threshold (0.9m/s =~ 2mph) even though, say, 3 seconds later the next GPS points would be logged further away than it is possible to travel at that 0.9m/s. If I corrected these then it would produce the correct amount of stopped time.

    I now avoid the problem by getting a Garmin Forerunner 920xt (the Triathlon watch) which doesn't seem to log trackpoints with no gps data on them as often (i.e. it's better about keeping a signal lock) but when it does lose signal it is also measuring running cadence and, combined with the reasonable estimate of stride length it maintains, comes up with a better estimate of distance traveled.

    I guess this is why Strava are doing nothing about it, the newer watches simply don't have the problem, and they don't want to spend time fixing a problem that only affects older generation watches.

    I've never had it affect my cycling (recorded on an Edge 705 or the Forerunner 920xt), but I can see how it would certainly be annoying in that respect if it did so significantly.

    I've never worried about the stopped time being inaccurate on cycling as very little of my cycling is non-stop; it's all either commuting or road riding where there will be a reasonable chunk of time stopped at traffic lights or junctions and I've never noticed the stopping/riding time to be so much out of sync that I've considered digging deeper.

    Anyway, the original bug was enough for me not to renew my Premium membership and even though I don't run in to the same problem now I've not been tempted back to Premium.

    0
    Acciones de comentarios Permalink
  • On my Garmin device for a recent snowboard trip I started and stopped the device so I was not recording any uplifts.  On Garmin connect the correct moving time (down-hill only) and distance are displayed but on Strava the distance has been increased by up to 50% and the moving time doubled!!  Is there any way of changing this??

    0
    Acciones de comentarios Permalink
  • I used to get accurate information last year with Apple Watch 1 and Strava. This year it's a shambles. And syncing my runs from Run Keeper seems to be problematic too as run keeper measures less points.

    The only accurate method I've found is to run with phone app only, and then you lose the functionality of the watch which is annoying.

    I've asked Starva if their are any plans to allow runs to disable the "moving time"and only use "elapsed time" (without the "set to race" tag workaround). The answer was.

    "Sorry for the trouble. At this time, I am unaware of  any plans to completely disable this aspect of Strava. In addition, I do not foresee this changing in the near future. Sorry for the trouble and I hope you have a wonderful day. "

    So from what I can tell we're stuck with this annoyance permanently. Such a pity that "accurate tracking" and "using watch and phone" seem to be unavailable on Strava. FWIW, run keeper is doing fine with both. Personally I'll continue using both, but suspect I'll stop paying for Strava given the extra hassle.

     

    0
    Acciones de comentarios Permalink
  • 4+ years and no fix. Come on Strava.

    This is even worse for back country / all mountain MTB!

    Eg. Recent ride into back country track 15 mins, then start push / carry bike up track for another approx 90 mins without stopping. Take a 10 minute rest, bite to eat, put on DH pads. Ride down the track and then out for 30 minutes solid. Elapse Time 2:26, Moving time on Garmin 2:10 (auto upload from Garman to Strava): compared to Strava's moving / activity time: 54 minutes.

    Sorry Strava - you've lost well over 1/2 my activity time - not good enough.

    0
    Acciones de comentarios Permalink
  • I stop being a premium user since it looks like that Strava team doesn't listen to us, the user.

    0
    Acciones de comentarios Permalink

Iniciar sesión para dejar un comentario.

¿No encontró lo que buscaba?

Nueva publicación