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.
- Refresh cache notes
- Refresh corrected coordinates
- Refresh Geocaches
- 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.