Return to Project-GC

Welcome to Project-GC Q&A. Ask questions and get answers from other Project-GC users.

If you get a good answer, click the checkbox on the left to select it as the best answer.

Upvote answers or questions that have helped you.

If you don't get clear answers, edit your question to make it clearer.

Categories

Bug: GPX time estimation

0 votes
251 views
Lately, possibly since the new API, whenever I export a vGPS to GPX I am advised that this will take some hours (I had 40 hours once!). Every time it has only been a few minutes at most. Today PGC advised me it would take two hours but was completed in under 10 seconds.

I appreciate it cannot be accurate but a divide by 60 would be a good step!
in Bug reports by the Seagnoid (Expert) (46.3k points)

1 Answer

+1 vote
 
Best answer

Divide by 60 wouldn't be very accurate.

When creating a BuildGPX job there are several jobs added into the database. Four jobs if I am correct.

  1. Refresh cache notes
  2. Refresh corrected coordinates
  3. Refresh Geocaches
  4. Build the GPX
As you can imagine, the 4th job depends on the three others, which can be run in parallel. The trick is then to estimate the time for each job and pretty much do a max(1, 2, 3) + 4.
What had been missed when writing new code was that job type 1 and 2 could have jobs in the queue that wasn't scheduled to run until a certain time has passed. This could be jobs postponed due to a missing oAuth token for example. Currently there was 61 jobs for refreshing corrected coordinates in the queue, which wasn't schedule to run yet. The estimator counted these job as if they would have to be finished before building the GPX file, which wasn't correct.
I have corrected this in the development environment now. Building a GPX file with 122 geocaches currently has a 3 minute estimate for in there.
by magma1447 (Admin) (243k points)
selected by the Seagnoid (Expert)
 | PGC Theme, based on Snow Theme by Q2A Market
Powered by Question2Answer
...