Release Notes (Website: Pocket Query API) - October 18, 2022

[+t@bbywmn]

I have 'created' three separate pocket queries along a route several hours ago. The previews look good.  I have checked off today's date (Friday, Oct. 21) but they did not produce any downloads.  I unchecked and checked the day and added my 'finds' pocket query this time as well.   I only received my 'finds' pocket query, but none of the new route pocket queries did run/is available for download.  We're leaving for a big trip on Sunday, so I would hope to have this resolved before then. Thank you very much.

[+Bl4ckH4wkGER]

@t@bbywmn

It's on the list and pending deployment. See the list at the end of my post from 1h ago here:
 

 

[+mustakorppi]

1 hour ago, Bl4ckH4wkGER said:

Wrong order of <author> element makes import into Garmin MapSource fail

I… that’s a quick fix and it might be all you ever need to do, but I would still suggest actually validating your XML output as a part of the process.

[+Bl4ckH4wkGER]

We have now deployed fixes for the following bugs:

• Pocket query preview does not work properly, including sorting
• PQs only include regular Events, bot none of the other ones
• PQs that have the "Found in the last 7 days" filter checked remain empty
• Wrong order of <author> element makes import into Garmin MapSource fail
• New PQs for caches along a route don't run

As you keep using PocketQueries over the weekend, please let us know if you run into any funky behavior. 

Happy geocaching  

[+Monway]

4 minutes ago, Bl4ckH4wkGER said:

We have now deployed fixes for the following bugs:

• Pocket query preview does not work properly, including sorting
• PQs only include regular Events, bot none of the other ones
• PQs that have the "Found in the last 7 days" filter checked remain empty
• Wrong order of <author> element makes import into Garmin MapSource fail
• New PQs for caches along a route don't run

As you keep using PocketQueries over the weekend, please let us know if you run into any funky behavior. 

Happy geocaching  

It does not work with reverse sorting on date, distance, etc.

[+Great Scott!]

Still unable to sort a PQ preview by any of the column headings noted in Monway's post.

The page will refresh, but the sort stays the same.

Edited October 22, 2022 by Great Scott!

[+Bl4ckH4wkGER]

Thanks for the additional reports.

 

While it appears fixed for general seek/nearest searches it's indeed still broken for PQ previews.

 

We will revisit the sorting issues on Monday.

[+Pe_Bo]

Preview of User Route Pocket Query returns much less caches then expected. Map of this PQ seems OK.

 

My testing PQ: https://www.geocaching.com/seek/nearest.aspx?pq=fbfde586-9770-4313-9535-0abc8d066323

preview shows 7 caches, but map shows 27 caches

 

[+Isonzo Karst]

Attribute handling seems to have changed. I saw a thread in the Website forum on this

https://forums.geocaching.com/GC/index.php?/topic/382583-pocket-query-attribute-handling-changed/

 

So I tried it myself, PQ for traditional caches 10 miles home coords with attributes 2 attributes: Thorns Snakes.

Instead of returning caches with BOTH, PQ now returns caches with either. 

I'm 99.99% certain that this is new. 

Search is returning caches with both - 13 caches

PQ is returning caches with either - 32  caches

 

 

 

[+msrubble]

5 hours ago, Pe_Bo said:

Preview of User Route Pocket Query returns much less caches then expected. Map of this PQ seems OK.

 

My testing PQ: https://www.geocaching.com/seek/nearest.aspx?pq=fbfde586-9770-4313-9535-0abc8d066323

preview shows 7 caches, but map shows 27 caches

 

 

I came here to report a similar problem. A "caches along a route" pocket query I set up years ago shows about 107 caches on the map, but only 31 in the preview list and the download.

 

None of the caches in the download have additional waypoints (for additional stages, parking, trailhead, etc.). Maybe that is a clue. No puzzles or earthcaches are included in the download, although they are in the route.

 

Edited October 22, 2022 by msrubble

[+markens]

I ran several PQs just now and they seem to work ok.  But I noticed an issue I haven't seen mentioned yet:  The PQs only include logs which are newer than about five years old.  Previously there was no time limit on logs included.  This means I am seeing a bunch of caches in the resulting GPX file that have no logs at all.  Needless to say this is a loss of useful information as there are numerous (very) lonely caches in my area.  Why was the time limit implemented, and can it be removed so that the five newest logs can be included no matter the time interval (as before)?  Thanks much.

Edited October 22, 2022 by markens
slight clarification

[+Pe_Bo]

Preview of Pocket Query based on distance from Home Location shows empty distances in the column. If I switch the PQ to explicit coordinates, the column shows correct values. But if I switch back to the Home Location, the column shows values based on previous coordinates, not Home Location, although the search results are OK.

 

[+Isonzo Karst]

16 hours ago, markens said:

caches in the resulting GPX file that have no logs at all.

 

Confirmed.

guid of PQ 

2e358e2e-8fc4-4e5c-a437-73fa9d707e55

 

caches within 1 mile of GC48QED

returns 1 log the most recent found it on that cache, from 2014, and no logs at from a couple of others, with more recent finds.

 

Most recent 5 logs of any date would be nice to get back.

[+Gamma5]

On 10/21/2022 at 5:19 PM, Bl4ckH4wkGER said:

We have now deployed fixes for the following bugs:

• Pocket query preview does not work properly, including sorting
• PQs only include regular Events, bot none of the other ones
• PQs that have the "Found in the last 7 days" filter checked remain empty
• Wrong order of <author> element makes import into Garmin MapSource fail
• New PQs for caches along a route don't run

As you keep using PocketQueries over the weekend, please let us know if you run into any funky behavior. 

Happy geocaching  

 

Good news, the following fix seem to have resolved the problem for my REGULAR PQs:

 

- PQs that have the "Found in the last 7 days" filter checked remain empty

 

However, for ROUTE PQs also with the "Found in the last 7 days" filter set returns zero results.

 

Example PQ: https://www.geocaching.com/pocket/urquery.aspx?guid=7897d592-3ea0-4ec7-abb0-304997535f92

 

Thanks

 

 

Edited October 23, 2022 by Gamma5

[+steben6]

I run a PQ for unfound caches in my area.  Today, the PQ title is lined out.  I can preview the PQ, but the distances of the caches are not there.  Help?

[+Bl4ckH4wkGER]

Thank you all for the reports over the weekend.

I have filed bug reports for the following issues:

• Sorting columns on PQ preview refreshes the page but doesn't actually sort
• Distance column on PQ preview remains empty if PQ is relative to home coordinates
• Attribute filters return caches with EITHER attribute instead of BOTH attributes
• User route PQs don't contain all expected results
• User route PQs remain empty if "Found within 7 days" is checked

On 10/22/2022 at 11:53 AM, markens said:

I ran several PQs just now and they seem to work ok.  But I noticed an issue I haven't seen mentioned yet:  The PQs only include logs which are newer than about five years old.  Previously there was no time limit on logs included.  This means I am seeing a bunch of caches in the resulting GPX file that have no logs at all.  Needless to say this is a loss of useful information as there are numerous (very) lonely caches in my area.  Why was the time limit implemented, and can it be removed so that the five newest logs can be included no matter the time interval (as before)?  Thanks much.

 

This is a limitation of the new system that we won't be able to rectify. It results from Pocket Queries no longer running straight against the database but instead against a data cache. The latter contains the last 5 years of data (that's when it was implemented) and will continue to populate going forward.

 

I understand that it may be inconvenient in your area, and apologize for the inconvenience. 

 

Overall, the number of caches that haven't been found in 5 years is very small. We hence consider this tradeoff as manageable, if it improves performance for all players at scale.

 

13 hours ago, steben6 said:

I run a PQ for unfound caches in my area.  Today, the PQ title is lined out.  I can preview the PQ, but the distances of the caches are not there.  Help?

 

Please take a moment to compare the bug reports from other players in this thread and your own. Unfortunately, it is missing crucial information.

I'd be happy to help you once you provide some screenshots & the Pocket Query ID for troubleshooting.

 

[+Isonzo Karst]

30 minutes ago, Bl4ckH4wkGER said:

Pocket Queries no longer running straight against the database but instead against a data cache. The latter contains the last 5 years of data (that's when it was implemented)

Thanks, knowing this makes workaround  doable. Either direct download from the page, which will come with the last 20 logs, or GSAK 'refresh data' will grab more logs.

[+markens]

1 hour ago, Isonzo Karst said:

2 hours ago, Bl4ckH4wkGER said:

Pocket Queries no longer running straight against the database but instead against a data cache. The latter contains the last 5 years of data (that's when it was implemented)

Thanks, knowing this makes workaround  doable. Either direct download from the page, which will come with the last 20 logs, or GSAK 'refresh data' will grab more logs.

I agree, thanks for the explanation.

[+Viajero Perdido]

2 hours ago, Bl4ckH4wkGER said:

This is a limitation of the new system that we won't be able to rectify. It results from Pocket Queries no longer running straight against the database but instead against a data cache. The latter contains the last 5 years of data (that's when it was implemented) and will continue to populate going forward.

 

What's the user's mental model for this?  "A pocket query contains..."

• Five logs plus your own.
• Up to five logs, plus your own.
• Up to five logs plus all of your own, or less.
• All logs since 2017, maximum 5, not including your own.
• An unknown number of logs; it depends.
• ...?

A clear spec would improve confidence / trust.

 

~~~

 

EDIT to suggest...  Lonely caches where this is a problem must be a tiny percentage of the total.  Shouldn't it be a straightforward exercise to build a one-time script that copies old logs of lonely caches from the database into this cache?

 

Edited October 24, 2022 by Viajero Perdido

[+Isonzo Karst]

15 minutes ago, Viajero Perdido said:

All logs since 2017, maximum 5, not including your own.

I'm seeing logs of any age  that are my own.   I'm seeing 5 logs +  mine.

The logic as described by Bl4ckH4wkGER is not quite what I'm seeing, one cache came with a single log, from 2014,  but it's close enough.

And those who care can find another way. 

[+Bl4ckH4wkGER]

15 minutes ago, Isonzo Karst said:

I'm seeing logs of any age  that are my own.   I'm seeing 5 logs +  mine.

The logic as described by Bl4ckH4wkGER is not quite what I'm seeing, one cache came with a single log, from 2014,  but it's close enough.

And those who care can find another way. 

 

You are correct. Allow me to clarify  

The only logs that are limited to the past 5 years due to the new implementation are "logs posted by other players."

 

You will always see your own cache logs, regardless of how old they are.

[+pwgo]

On 10/22/2022 at 1:56 PM, Pe_Bo said:

Preview of User Route Pocket Query returns much less caches then expected. Map of this PQ seems OK.

 

My testing PQ: https://www.geocaching.com/seek/nearest.aspx?pq=fbfde586-9770-4313-9535-0abc8d066323

preview shows 7 caches, but map shows 27 caches

 

I am experiencing the same issue.
- Preview - map seems to be complete and ok.

- Preview - list is lacking more than 50% och the caches and also contain some stray caches that is outside the distance filter, i e 1 kilometer from the route. This is also what is delivered in the PQ file

[+Viajero Perdido]

1 hour ago, Bl4ckH4wkGER said:

The only logs that are limited to the past 5 years due to the new implementation are "logs posted by other players."

 

Will that be 6 years a year from now, then 7, and so on?

[+Hügh]

1 hour ago, Viajero Perdido said:

Will that be 6 years a year from now, then 7, and so on?

 

5 hours ago, Bl4ckH4wkGER said:

The latter contains the last 5 years of data (that's when it was implemented) and will continue to populate going forward.

 

[+Viajero Perdido]

I saw that, but it doesn't answer the question.

 

Does the cache accumulate, or expire old stuff beyond 5 years?  Caches by their nature tend to expire stuff.

 

If it accumulates, eventually it won't matter much, except to a few passionate lonely-cache hounds.  In a decade or two.

[+Hügh]

1 hour ago, Viajero Perdido said:

Does the cache accumulate, or expire old stuff beyond 5 years?  Caches by their nature tend to expire stuff.

 

I assume the cache doesn't expire stuff, since the cache "will continue to populate." As in, over time, the percentage of all logs that are in the cache will increase.

[+Bl4ckH4wkGER]

14 hours ago, Hügh said:

 

I assume the cache doesn't expire stuff, since the cache "will continue to populate." As in, over time, the percentage of all logs that are in the cache will increase.

 

That is correct.

 

 

@DaTechniker

I just wanted to circle back and say that we re-ran the four missing queries for you that you had highlighted:

Quote

Status 404, URL not found: https://api.Groundspeak.com/v1.0/lists/PQV8TNY/geocaches/zipped Höflein 17.10.
https://www.geocaching.com/seek/nearest.aspx?pq=d41ba73c-4047-4896-b7cd-15708f44d4e6
Status 404, URL not found: https://api.Groundspeak.com/v1.0/lists/PQVFXNE/geocaches/zipped Wels 17.10.
https://www.geocaching.com/seek/nearest.aspx?pq=87c939d1-1a6a-4ad1-bc50-1cb437877f1b
Status 404, URL not found: https://api.Groundspeak.com/v1.0/lists/PQVFN76/geocaches/zipped Leoben 17.10.
https://www.geocaching.com/seek/nearest.aspx?pq=87235bea-4a13-4bb6-9047-4ed5143aa6a2
Status 404, URL not found: https://api.Groundspeak.com/v1.0/lists/PQVE98H/geocaches/zipped Vorarlberg SW 17.10.
https://www.geocaching.com/seek/nearest.aspx?pq=96737337-8428-47c6-aa93-6a43cf32b7d5

The discussion at the time was correct, that ad hoc PQs weren't carried over into the new system because they were handled by a different query job. That was an oversight on our end.

If anybody is still missing ad hoc queries, please feel free to re-run them. Any missing PQs would expire tomorrow, so you'd be close to re-running them anyway. We apologize for any inconveniences caused. Going forward, any newly scheduled ad-hoc PQs will run.

 

 

@ all

 

We're still working on the various bug fixes that were previously mentioned:

• Sorting columns on PQ preview refreshes the page but doesn't actually sort
• Distance column on PQ preview remains empty if PQ is relative to home coordinates
• Attribute filters return caches with EITHER attribute instead of BOTH attributes
• User route PQs don't contain all expected results
• User route PQs remain empty if "Found within 7 days" is checked

I will circle back when we have fixes.

[+baer]

I have a PQ which returned caches which have two attributes ("bicycle" and "> 10 km").

 

When it ran yesterday, it returned caches which have at least ONE of these two attributes, which is much more caches than before.

 

Is this by intention or another bug?

[Keystone]

34 minutes ago, baer said:

I have a PQ which returned caches which have two attributes ("bicycle" and "> 10 km").

 

When it ran yesterday, it returned caches which have at least ONE of these two attributes, which is much more caches than before.

 

Is this by intention or another bug?

As noted in the post just above yours, this bug is in line to be fixed. 

[+TommyGator]

I came to this thread because, all of a sudden, my PQs that I have been running for years are now only providing a fraction of the returns that they were just a month or so ago.

 

I noticed this when I wentr to update a (caches along a route) GPX with a PQ that I have run for years, and the PQ returned only about half of the caches.  I have not changed or messed with the PQ, but after filtering out the ones that did update (using GSAK), I was left with a substantial number of un -updated caches that are clearly within the bounds of the PQ  selection criteria.

 

Please note that I only used GSAK to do the filtering to determine what was going on.  I ran the PQ from the website, then downloaded the result directly to my computer desktop.  I then loaded a previous (older) route file into GSAK, loaded the PQ, and found that 94 out of 154 valid, current caches were not contained in the new PQ.

 

My original GPX, containing prior results of the exact same PQ, had 154 caches along the route, and I checked to make sure they were all still valid (i.e., not archived, already found, etc), but the new PQ only contained 60 of those caches.

 

I also noted that the name of the PQ download file was exactly the same as a previous run from yesterday (8380642_Texas_Rt_IN_IL.zip), which also only contained those same 60 caches.

 

I tried another PQ for a different route and had a similar experience.  This wasn't happening in July, which was the time prior that I checked these PQs.

 

I've provided the PQ name and have a GPX of the previously downloaded caches that the new PQ didn't contain.

 

 

[+Bl4ckH4wkGER]

@TommyGator thanks for the report.

The issue is already captured in the list of bugs that is actively being worked on.

 

You can find the full list by looking 3 posts above yours:

 

 

[+pwgo]

On 10/25/2022 at 7:11 PM, Bl4ckH4wkGER said:

 

That is correct.

 

 

@DaTechniker

I just wanted to circle back and say that we re-ran the four missing queries for you that you had highlighted:

The discussion at the time was correct, that ad hoc PQs weren't carried over into the new system because they were handled by a different query job. That was an oversight on our end.

If anybody is still missing ad hoc queries, please feel free to re-run them. Any missing PQs would expire tomorrow, so you'd be close to re-running them anyway. We apologize for any inconveniences caused. Going forward, any newly scheduled ad-hoc PQs will run.

 

 

@ all

 

We're still working on the various bug fixes that were previously mentioned:

• Sorting columns on PQ preview refreshes the page but doesn't actually sort
• Distance column on PQ preview remains empty if PQ is relative to home coordinates
• Attribute filters return caches with EITHER attribute instead of BOTH attributes
• User route PQs don't contain all expected results
• User route PQs remain empty if "Found within 7 days" is checked

I will circle back when we have fixes.

Great!

What is the ETA for those fixes?

 

Also, it would be nice to hear the explanation of why a new version is set into production without prior testing in a QA environment?

[+Bl4ckH4wkGER]

3 hours ago, pwgo said:

Great!

What is the ETA for those fixes?

 

Also, it would be nice to hear the explanation of why a new version is set into production without prior testing in a QA environment?

 

If you are experiencing any particular issues, it'd be great if you'd share them. That way we can either acknowledge them as known or help you and others by documenting new bugs and fixing them. 

 

Otherwise the tone of your message seems misplaced, especially because based on your last statement you don't know what has gone into this release up until this point - frankly, how would you.

 

The original PQ code was ancient. Documentation for it was close to non-existent and so a lot of the work to get to this release was forensics, documenting, implementing, and then working with a test group of long term PQ users to verify whether what they were seeing matched the old expectations. Internal testing with HQ staff began in May, followed by a player-test group in June. The production release was in October.

 

Pocket Queries offer a very extensive number of options, combinations, ways to create them, etc. The fact that across those 1000s of options, yes you read that right, we've only had ~10 bugs, I'd call that a win and a display of the hard work that has gone into QAing this.

 

And to those who are saying "well, there shouldn't be any bugs", that's not how software development works no matter how solid your practices are and how many unit-tests you write.

[+pwgo]

On 10/24/2022 at 8:48 PM, pwgo said:

I am experiencing the same issue.
- Preview - map seems to be complete and ok.

- Preview - list is lacking more than 50% och the caches and also contain some stray caches that is outside the distance filter, i e 1 kilometer from the route. This is also what is delivered in the PQ file

 

19 hours ago, Bl4ckH4wkGER said:

 

If you are experiencing any particular issues, it'd be great if you'd share them. That way we can either acknowledge them as known or help you and others by documenting new bugs and fixing them. 

 

Otherwise the tone of your message seems misplaced, especially because based on your last statement you don't know what has gone into this release up until this point - frankly, how would you.

 

The original PQ code was ancient. Documentation for it was close to non-existent and so a lot of the work to get to this release was forensics, documenting, implementing, and then working with a test group of long term PQ users to verify whether what they were seeing matched the old expectations. Internal testing with HQ staff began in May, followed by a player-test group in June. The production release was in October.

 

Pocket Queries offer a very extensive number of options, combinations, ways to create them, etc. The fact that across those 1000s of options, yes you read that right, we've only had ~10 bugs, I'd call that a win and a display of the hard work that has gone into QAing this.

 

And to those who are saying "well, there shouldn't be any bugs", that's not how software development works no matter how solid your practices are and how many unit-tests you write.

 

Included my earlier post about issues I discovered.

 

I know there is always bugs, always! There is no software anywhere that is bug free, you are completely correct.

 

What sets my "tone", is that there were no obvious warning about the "upgrade" and some of the issues (like loosing 50% of the content of the PQ) would have been found after 5 minutes of testing in my view. I spent MANY hours trying to sort out  what has happened. Apologies if someone got hurt!

 

Can you please inform us about the new functions in the release you are mentioning? (If I understood correct)

 

And again, what is the ETA please? (if there is one)

 

Only 10 bugs is very impressive!!

Regards.

 

 

 

Edited October 27, 2022 by pwgo

[+TommyGator]

Bl4ckH4wkGER,

If you already know what is wrong with the PQs,, please disregard.

 

However, if you need assistance in debugging, I have two different runs of the same PQ, obtained 9 and 27 Oct 22, which I'll be glad to send you to compare and analyze.

 

If you want them, please send an email through my profile with return address enabled so I can reply with attachments.

[+Bl4ckH4wkGER]

@TommyGator Done, thanks for the offer  

[+mbooda]

For the last week or so, whenever I create a pocket query, my specifications concerning Days to Generate and Selected Types seem to be ignored. Regardless of the day of the week I select to generate the query, the query is generated immediately after I hit Submit Information. And regardless of the types I select, all types are included.  My latest query is:

 

https://www.geocaching.com/seek/nearest.aspx?pq=e667fc55-0226-4ec3-8d1c-dbb65157aa11

 

I submitted it about a half hour ago with Wednesday selected as the only day of the week to generate, but it generated immediately.

[+Team Canary]

Any updates on the sorting by Date feature?

 

I really miss this feature as I use it often.

[+Bl4ckH4wkGER]

@mbooda

Thanks for the report. Could you clarify with what types of PQs you're seeing this?

• PQs from a List
• PQs from the map
• PQs along a route
• standard PQ
• all the above

 

By selected types, I assume you mean cache types. Again, we need more specifics of what you're trying to include and what is included instead.

 

@ all

Regarding the other bugs, we'll be releasing some fixes at the end of tomorrow's sprint, Tuesday November 2, at the end of the day pacific time.

 

I will post again once the release is out.

 

[+mbooda]

8 hours ago, Bl4ckH4wkGER said:

@mbooda

Thanks for the report. Could you clarify with what types of PQs you're seeing this?

• PQs from a List
• PQs from the map
• PQs along a route
• standard PQ
• all the above

 

By selected types, I assume you mean cache types. Again, we need more specifics of what you're trying to include and what is included instead.

 

@ all

Regarding the other bugs, we'll be releasing some fixes at the end of tomorrow's sprint, Tuesday November 2, at the end of the day pacific time.

 

I will post again once the release is out.

 

standard PQ, and selected types = cache types. I’m including everything except events, but events get included. Latest example: https://www.geocaching.com/seek/nearest.aspx?pq=d98ab160-907c-4a5b-a8fa-44d86f517b57 , generated just a few minutes ago.

[+mbooda]

Also, selecting “Placed” in the query does nothing; I.e. the caches are still listed by distance from origin, not time/date placed.

 

Here is screenshot of the latest query.

Edited November 2, 2022 by mbooda

[+Bl4ckH4wkGER]

12 hours ago, mbooda said:

standard PQ, and selected types = cache types. I’m including everything except events, but events get included. Latest example: https://www.geocaching.com/seek/nearest.aspx?pq=d98ab160-907c-4a5b-a8fa-44d86f517b57 , generated just a few minutes ago.

 

Thanks that's very helpful.

 

32 minutes ago, mbooda said:

Also, selecting “Placed” in the query does nothing; I.e. the caches are still listed by distance from origin, not time/date placed.

 

That's been brought up several times in this thread and is part of the larger sorting issues on the PQ preview. We should have a fix for that later today.

[+Bl4ckH4wkGER]

Alright, here is the promised update

Bugs that were fixed:

• PQs with attributes filters contain ANY is true instead of ALL is true
• PQ preview columns not sortable
• PQ preview distance column is empty
• Missing PQs when "uncheck the day of the week after the query runs" was checked
• Caches along a route PQs remain empty if "Found in the last 7 days" filter set

Bugs that are still in the works:

• Caches along a route PQs return much less caches than anticipated (we now know what's causing this, we just need to do the work to fix it)
• PQs include Events even if Events are not selected (we're currently failing to reproduce this, so we may need additional screenshots etc @mbooda)
• PQs run immediately instead of on selected days (we're currently failing to reproduce this, so we may need additional screenshots etc @mbooda)

 

Please continue to bring up new issues as you encounter them. Thank you for your patience as we address the remaining bugs.

[+Bl4ckH4wkGER]

@mbooda

 

Following up with you specifically.

If we run both of the PQs you shared, we're not getting Events - as expected and as designated in your criteria. Likewise, we cannot reproduce the issue with something scheduled for later running right away.

Could you please share additional screenshots of the setup, the preview, the results of an example PQ that exhibits the issue?

 

Ideally step by step instructions would be great to help us reproduce. If we aren't able to reproduce the issue, we aren't really able to address it unfortunately. 

[+Pe_Bo]

The "PQ preview distance column is empty" fix is probably causing a much more serious problem.

If the PQ has "From Origin -> None Selected" set (or it is a User Route PQ or Bookmark PQ which do not contain the "From Origin" option),

a preview page returns "Error 500".

 

[+Bl4ckH4wkGER]

56 minutes ago, Pe_Bo said:

The "PQ preview distance column is empty" fix is probably causing a much more serious problem.

If the PQ has "From Origin -> None Selected" set (or it is a User Route PQ or Bookmark PQ which do not contain the "From Origin" option),

a preview page returns "Error 500".

 

Thanks for the report. That looks like a regression that slipped through the cracks.

We'll continue our game of Whac-A-Mole.

[+mbooda]

The latest fix seems to have cured all the problems except one: regardless of the day of the week I pick to generate the PQ, it is generated immediately upon submission. Latest example:

 

https://www.geocaching.com/seek/nearest.aspx?pq=83b6b55f-5569-4066-a244-a5be3a9f7186

 

As you can see from the attached picture, I chose it to be generated next Tuesday. However, it was generated immediately after I submitted it, a few minutes ago today (Wednesday).

[+mbooda]

The PQ itself looks fine; it’s just generated too early.

 

[+mbooda]

And when I select “Placed”, I get exactly what I expect.

 

[+pwgo]

After the night (CET), I get http 500 och almost all of my PQs if I press "Preview Pocket Query". Map view seems to be ok.

 

The PQs that don't work has one of the following settings that differ from the one that works:

Caches along a route

Placed during a span of dates.

All ofther setting are "default"

 

PQ files seems all to be ok (still missing 50% in caches along a route)

Hope this helps!

Edited November 3, 2022 by pwgo