Show Delete Activity Delay in Status

As someone whose city doesn’t play well with GPS tracking, I end up editing the GPS traces for my runs, delete, upload to Garmin, and resync from Garmin. But this process is always held up by the delete step, and when I delete the old activity, I have no idea how long it will take …For instance I’m waiting right now for over an hour to delete (As an aside, is there any reason it takes so long to delete an activity?)

It would be nice to have an idea of when I can come back to my profile page and upload my fixed activity and I hope this would be something easy to add to the various metrics on the Status page.

I have a single “slow” queue that I put slow/expensive jobs in. This includes deleting stuff, all the reprocessing that comes after adding/updating cities, and completed street calculations.
I’ve been hesitant to make it visible on the status page because it doesn’t indicate anything specific, and I tend to get lots of support queries when things are confusing.

I’ll add it to the status page in the next release, but if it ends up causing lots of support questions I’ll probably remove it.

This is the chart for the last week of that queue:

Any guess as to when I bulk-imported Australia? :flushed:

I’ve recently been thinking about notifications/emails that might be useful for people.
There’s a whole other conversation of handling people who bulk-delete activities (please don’t? lol) but other than that, this seems like a useful email to set up.

1 Like

Agree with everything here and would love to receive an email notifying me my run was successfully deleted. I know others might use the delete activity function differently or for bulk deletes sometimes, but this would be perfectly suited to my purposes.

1 Like

If deleting is slow and expensive maybe having something like a toggle that deactivates auto-synch would help by avoiding the need for deletions and waiting altogether (at least for the use-case described). I don’t know how others do it, but I “synch now” all my CS-relevant activities anyway, so it wouldn’t make a difference in practice from a user perspective.

1 Like

It’s an interesting thought but I need to see what nodes I missed from the initial upload. I don’t ‘prune’ my trace to look perfect but if the GPS signal got wiggly and missed some nodes I go back and fix that. So the first upload tells me what I need to edit in Runkeeper and I try to edit the minimum because it takes forever

1 Like

Alright, both the slow queue displaying in the status page and the activity deletion emails are live now. Updates on April 8, 2021 (Release 79)

1 Like

I edit my traces in runkeeper as well, so I’m familiar with its limitations. Definitely a painful process for longer runs :unamused:.

Since James has been kind enough to implement (nearly) all my wished-for improvements, maybe I’ll go pester the folks at runkeeper about the editor instead :laughing:. Just the ability to edit multiple points simultaneously would make things so much easier…

There are much better tools than runkeeper if you have an off gps track and want to make it closer to reality

Are you going to leave us hanging in suspense?

1 Like

200

1 Like

ok ok ok hold your horses

best experience for me so far was routeconverter
but also Viking GPS data editor and analyzer download is workable, and does the job

4 Likes

Was worth the wait, wow. Routeconverter is pretty easy to use and has the same OSM backend so I think this is what I too will use going forward. Thanks a lot!!!

A continuation of items discussed in this thread…

  • Got my deleted activity email noti today and it worked great! The queue had said ~40 min but happened much sooner, so the email was quite helpful.
  • My run today was missing a part of a trail I ran (GPS not connected error) that I wanted to populate on my LifeMap: a difficult trail that was overgrown with brambles and nettles, I’m not excited to get back out on it, so seemed like the perfect opportunity to try out route converter. Was super easy to use, save, and reupload to Garmin.
  • But it seems there is some problem with the gpx that does not appear in either routeconverter or my Garmin activity, but does manifest in CityStrides? I reopened the gpx in routeconverter and still doesn’t appear. Does not appear to be a processing error…any ideas what could be going on here? Link to activity: CityStrides

This seems to be caused by the timestamp values on the individual GPS coordinates.

When it builds the encoded polyline (the site’s not displaying individual coordinates on the map, it’s a special encoded value that represents the line), it’s sorting all the coordinates by their timestamp value. I’m expecting that it’s seeing certain coordinates as ‘next’ which are much further down your activity path.

If I switch it out from the timestamp to my internal created at value, it gets even worse (it doesn’t create records in order).

:thinking:

Hmm…there isn’t a timestamp field in the route converter. When I look at the code in the gpx file, each ‘drawn’ node has the same timestamp: 2021-04-12T09:36:20.000Z

So the polyline encoder doesn’t know what to do with coordinates with identical timestamps, and doesn’t default to using the order of the coordinates in the code? Maybe next time I should just drag existing nodes instead of inserting new ones - or edit the timestamp with iterative thousandths of seconds intervals? (The multiple ?s indicate I’m way out of my depth!)

I guess either of these should work…either way, editing with this application is way easier/better than runkeeper’s terrible, resource-heavy web-based version, so an extra step is still worth it.

It forcefully clobbers the coordinates to be sorted by that timestamp value, because they’re not necessarily created in order.

That could do it…

Yeah, if the timestamps all fell in order of your running/walking then I’d expect them to be drawn properly in CityStrides - all the way down to those thousandths of a second. It sounds like your edits potentially tagged your newly created coordinates as timestamped to your editing - not timestamped to you actually completing the activity (which makes sense).

The new coordinate do not have the timestamp of the edit, but appear to be ‘clones’ of the same time based on their order. I used the ‘+’ on routeconverter to insert new coordinates between the coordinates recorded by my Garmin, and dragged these to draw the missing part of my trace. I will delete this activity again and try manually editing in the code the iterative thousandths since it’s quick and dirty.

Appreciate your granular advice, only going as deep on this in case others have the problem in the future and just to understand a bit better how all this works - and it is interesting to understand how it works!

Edit: ok thousandths didn’t work for some reason (fewer jumps but still present), but seconds did!