Bl4ckH4wkGER

When I posted that I wasn't able to reproduce it, I was actually running Google map tiles. That still works right now. I now also tried with the Leaflet tiles also and that works as expected, too. We'll need more detail on what OS, Browser, Browser version you're running. Please also make sure that you're not running any scripts or browser extensions that may interfere with the site or block essential cookies. Thanks

I'm unable to reproduce what you're describing. Mapping PQs works just fine for me: from the map icon to the left of the PQ name on the PQ page when selecting "Map this location" from the PQ preview when generating a new PQ when switching back and forth between different PQs on the browse map. Please provide additional screenshots and step-by-step instructions for what you're doing/clicking to see the issue you're describing.

That looks like another regression. I've documented it. Thanks for the report.

Please keep this thread focused on this one issue. There are other threads for other bugs and or you can create a new one if one doesn't exist, yet.

Thanks for the report @Geo Chief. I can reproduce the issue and have documented it so it can be addressed in the future.

@fallingforstars what you are referencing is a WEB issue. This present problem is related to the mobile apps. They are not related and different ecosystems.

I merged the duplicate threads. We understand that this bug is annoying and it will be prioritized now that the new year is here and people are returning to work. Like at many companies, end-of-year tends to be a period of security updates, people taking extended periods of vacation, and code freezes. Geocaching HQ is no exception to that. We apologize for the inconveniences and delays this has caused for this bug to get addressed.

I'm able to reproduce it on Safari & Mac, even on more modern versions than you're running, thanks for the additional detail. Chrome works as expected on both Mac and Windows so I encourage you to use that as a workarounds until we have a fix.

I'm unable to reproduce either of your issues. Could you log out and back in again, hard refresh the necessary pages, make sure that any scripts that may interfere are disabled, and if that doesn't do it give us some more details on what OS and browser version you're using.

Indeed, very curious stuff Back to the drawing board. I'll keep everyone posted.

Both of the original reports are now fixed. In the process, we also fixed the 1000 result bug mentioned by @HHL

That's exactly right. The Event widget in its current form doesn't check for who owns the Event. That said, it's something that one could consider for future improvements to the Event widget. That'd require some more considerations though: Should own Events also be green or a different color? What if an own and another Event one has will attended fall on the same day? Should there also be a way to see whether friends are planning to attend an Event (the list goes on ) For now it functions as expected.

Alright, thank you for your patience. Please give things another pass. Things should be back to normal now.

Alright, thank you for your patience. Please give things another pass. Things should be back to normal now.

Thanks for letting us know. The scenarios you describe reproduce for me. I've passed them on to the developers. In the meantime, you can create a new list via the List Hub and then bulk add caches via search to that List. Not perfect but it'll help until we have a fix.

Falls du das Message Center meinst, dann gibt es aktuell ein Cookie-Problem was dazu führt. Siehe mehr details hier:

Documented and passed on to the Engineers, thanks

We implemented a fix last night but players may need to hard refresh (Ctrl + F5) the pages in question. Could you give that a try and let us know if the issues persist? Thank you for your help.

We implemented a fix last night but players may need to hard refresh (Ctrl + F5) the pages in question. Could you give that a try and let us know if the issues persist? Thank you for your help.

Please see my previous posts for a comprehensive explanation for why we won't be doing further work on the old PQ preview. Thank you for your consideration and apologies for any inconveniences caused.

Today, we deployed two bug fixes: The PQ-setting for "Are not on my ignore list" is now respected When checked, ignored caches will NOT be part of the PQ file. When unchecked, ignored caches will be part of the PQ file. Please note that there is a pre-existing bug with ignored caches being removed in the old seek/nearest PQ preview regardless of the player setting. This will be fixed when we migrate the PQ preview to the new search results. We will do no further work on the existing PQ preview. We did some more fine tuning on caches along a route PocketQueries. Previously the search distance from the route could get a narrower than expected in corner sections, so routes with many corners could see less results than before. We've now ensured that the search distance never falls under the distance set by the player. This exhausts the fine tuning we will do for the new route based queries. Please note that this is a new and different implementation and by nature results may differ slightly. That said, especially with the last changes, the queries are more accurate and we will not continue tweaking them back to the less accurate queries from before.

We did some internal digging and it's indeed a cookie issue, well more cookie-bot, but same same for these purposes You can work around it by temporarily allowing all cookies. We're working on a fix.

In the past this has usually been connected to cookie issues. Could you double-check that you're allowing essential cookies? If that is already the case, could you temporarily allow all cookies and see of that resolves the issue? If the latter is the case, chances are that cookie-bot needs some re-classification on our end again.

I confirmed that Benchmark finds were never featured on the stats page. Outside the dedicated benchmarks find page, they were only ever surfaced on the public profile where the number will remain even after the retirement.

Looks like the OP has found a solution and all has been said here. So I'm closing this thread.