lazyuncle

When I mouse over the statistics for Finds Per Month (not Cumulative Finds Per Month) if I hover my mouse at over the location of both the little speech bubble that pops up and the bar that gives that speech bubble the bubble rapidly flickers on and off. This is more rapid on Firefox than on Chrome, but it occurs in both browsers. I am running Windows 11 on an Intel Core i3 x64 architecture. I can't attach video, but here's a Google Drive link for the video of this happening on firefox.https://drive.google.com/file/d/1GmsOLfDYVOhprnPGPTUKI4U6PiFqlohE/view?usp=sharing, owned by my google Geocaching alt account. I am not clicking/autoclicker on it at all. EDIT: Google drive is being weird, so I converted it to a gif.

Any update on this? This bug is still fully active on GC.COM lists

Just what it sounds like: Bookmark lists have a link to the profile of the CO, but the link is in the "https://www.geocaching.com/p/?u=iryshe" format. I can see how the devs could have missed it, seeing as it works correctly most of the time, but if a cache has been adopted, or if the CO elects to put a different name in than their UN or changes their UN, the url directs to the provided name, often providing a 404 error. https://www.geocaching.com/plan/lists/BM115RT?sortOrder=desc and other bookmark lists of oldest caches have lots of adopted ones and show this more readily. (hint for this one: default sort; second entry. I imagine this has been around for a little while without being noticed. In the cache page itself it has "https://www.geocaching.com/p/?guid=21b83635-9493-4017-b291-d11eb5be92ac&wid=66a748e8-f33f-429d-8982-8cdd8bef3fc1" format. This should not be too hard to fix!

The browser and OS should not be a problem with an error 500, for it is a server error and modern browsers have no problems querying servers (with the possible exception of Safari). UPDATE: This stopped happening. I wonder what was going on? EDIT: I might know what happened. I selected "give 500 caches" but also "within 5 MI of coords." I don't think there were 500 caches within 5 miles of the given coordinates.

When I try to submit a pocket query it gives an error 500. This occurs no matter what I put in as the parameters. When I tried to submit a route, it also didn't work: an empty site dialogue box popped up (I.E. "Geocaching.com says: " <blank/>). This is obviously a major error on the server side, so please don't try to blame me. Hope you have this fixed soon, folks in Fremont! --->

I am not (very) lazy and I'm nobody's uncle, but I'm still lazyuncle. I cache with an old-ish Android smartphone and the "App which Shall Not be Named" along with (NEW! to me) a Magellan eXplorist 310 (which has an excellent basemap BTW). I reside a stone's throw from the Grand Trifecta but have only visited 1 of them so far (The Lily Pad). I have, by my reckoning, 368 finds (including a handful of ALs) and 17 hides, 2 of which are archived (not including the ones I adopted out when I moved from Arizona in 2022). I got interested in geocaching when I was browsing the Google app store and saw the official app back in 2021, and went out and looked for the one close to my house. Lo and behold, it was missing, and I met the CO replacing it. So that's me, everybody. Nothing too impressive, just another cacher who is not suspicious at all.

When I sign logs with other than my official caching name I make sure to make a note of that prominently in my logs IE "Thanks for the quick downtown micro, log doesn't have so much room so signed LazyUnc" or "TFTH QEF Nano on beautiful urban art installation, signed LZU because log's getting full." That's just the generally accepted practice around here in Seattle. Just my €0.02

+1

Anyone got any good GEOCACHING-RELATED quotes, jokes, funny truisms or one-liners? Here's one: Flashlights are tubular metal containers kept in a TOTT-bag for the purpose of storing dead batteries, while batteries are metal tubes kept in GPSr's for the purpose of being drained.

I personally have no qualms about searching for a disabled cache unless the "disable" log is preceded by a string of DNFs or says the cache is missing or inaccessible. I know many other cachers who share this opinion. So I agree with M&99: disabling the cache would be the right choice in this scenario.

The past trackables list also shows "visited" ones which do not indicate size.

No problem! It's what I do!

Use Project-GC Map compare with yourself and an account with 0 finds IE Geocaching HQ Admin selecting Neither Found and filtering to the county.

@GOcacherXXIIINo it isn't. I could go into a long tirade but I'll spare you... I'm sure a cursory search of the forums will show countless cachers/forum classholes making my point for me.

Got mine today! Thank you so much @ByronForestPreserve! It's the best one yet for me! Its new page is https://www.geocaching.com/track/details.aspx?id=7741750

Opencaching? Maybe a private one hidden by some family for a reunion? Or some company for employees? This is very odd. That the finders have nearly all been muggles/signed with real names makes me think it's not an official geocaching.com geocache, despite use of a geocaching.com logsheet.

That's not what I'm saying; For me, the selected cache goes behind any deselected cache

Once I tap on a cache icon (making it a "pin" on the map rather than a circle) it goes behind any (in circle form) that happen to be above it on the map (Android). This does not change based on which way the map is facing, and all geocache icons and map layers are affected. This is not a major bug, but it gets annoying in cache-dense areas. If y'all at the Lily Pad could fix this, that would be great!

I've lived in 2 parts of the Western United States with radically different hide-styles. Tucson and surrounding desert, Arizona (a city famous for its great big areas of open desert): This area is all about the numbers. The biggest local cacher, Philbeer, has about a 40% share of the inner-city's cache and about 80% of the surrounding areas, with the next most, TuffAZNaylz, having less than 5% in-city and about 15% in the surrounding desert. Often, new geocaches are found by the 10 or so major geocachers in the first few days and then monthly at best after that. The bison tube, film canister and micro preform are king in the Arizona desert, and in the city the Nano reigns supreme. Power trails proliferate on the lonely country roads. Caches are often not even waterproof, replaced after each rainy season. In Tucson, hide and find counts are the name of the game. Everett-Seattle-Tacoma metro area, Washington (confined and developed): This area is all about the individual caches. With a more forested terrain, suburban parks are filled with Smalls and Regulars, even occasionally Larges. Of course, we are lucky, being a stone's throw from the Lily Pad, the Monkey and the Original (along with GCD and the HQGT), so our caches are mobbed by Trifectizers. In the City, micros are everywhere (of course) but there is a conspicuous absence of power trails of more than 5 or so caches, mostly due to the sheer amount of "small-time" COs here, myself included. Caches are found nearly every week (except puzzle caches. Mine has only been found twice in the several months of its existence), but a soggy log/moldy swag is common here. The most common caches: Tupperware (here incl. L&Ls and pelicans), Ammo-cans () and film- and pill- canisters. That's just my experience.

Project-GC has a "show archived caches" feature; this shows one way: Just select "none found," enter the coordinates for a filter and search for archived caches. It may also be listed on another geocaching site instead of geocaching.com so maybe check there: I don't think I'm allowed to link to those but a google search for "geocaches -inurl="geocaching.com"" will probably bring up some results! Good luck! (I've had this happen once to me; I checked a random guardrail and found a PMO cache. Being Basic at the time, I could not log it until I upgraded. Sometimes you just get lucky! )

Welcome back @MommaLogan!

I would love one!

Thank you!

There are ways to irreversibly delete a data set in all common query structures, so much so that trying to query/write to that set gives an error and the data is irrecoverable or near such. This can be done without affecting the rest of the related data, so someone may have deleted the data set for GC codes but not the set for Cache Name.

(based on the length of time this has been a problem) a necessary data set was likely irreversibly deleted/DROP TABLE'd/corrupted which would be a difficult, if not impossible fix, and now they can't get the geocodes for the caches back? Just my guess, feel free to disagree