Cryptosporidium-623

When a drop down menu is selected (e.g. "Your Profile", "Play", etc) on Safari running on an iOS device, the menu momentarily appears and then the web site whisks the user away to the top level link for that menu, preventing the ability to select anything from it Now, this behavior is fine on "your profile" because you can access sub menu times from the quick profile page that appears, but logging a trackable or viewing challenges from the "play" menu is much tougher. The behavior of these menus should be similar to desktop browsers. When the menus appear, you should be able to select a sub-menu item without the page switching away.

You're right. I'd forgotten that one mention at the end of the "teaser". I just went back, and I eventually found that FAQ buried (pun intended) deep down the page. I see he tried to defend the title, but I still maintain it's a poor choice. The references to Geocaching were added after the OP

My opinion as a (very) amateurish magician is that the closest intersection between magic and one aspect of geocaching is probably engineering / disguising objects (in this case caches) to resemble everyday items when, in fact, they have a "special function" or "purpose". An example would be the humdrum payphone that secretly conceals a cache container until the proper code sequence is entered via the keypad. I have seen a few basic magic props (e.g. hollow coins) used in caches, but they are far and few and have not held up well in terms of weather or muggling. Hope it helps.

Not a single mention of geocaching on the kickstarter site, the movie site, FAQs, etc. I call BS.

You had the decency to contact the owner and tell them the truth about what happened. That's worth its weight in gold to many CO's. You did fine.

Not only YES but HECK YES!

Thank you! Believe me, if I could have found a TARDIS in that scale, I would have used it.

This is a creative ammo can cache that I finished recently. It uses mercury switches and an oversized lithium battery to power lights and sound when the lid is opened.

http://nlp-addiction.com/chatbot/eliza/

Perfect timing for what I'm dealing with elsewhere. Yep, and that's why you have "backout plans".

Why oh why isn't there some server redundancy so that when a change is deployed, users can be "cut over" to the new version of production? Then, if something misbehaves, they could redirect the users back to the old servers until they're ready to try again. It works great for us big enterprise guys with 24 hour user traffic, but what do we know?

The drag-release auto-zoom-one-level bug is annoying. I understand the decision to switch but, seriously, Google announced this back in October? This couldn't have been tested just a little bit more?

"Hey! This Jesus trackable REALLY WORKS!"

How does this one work then? The long and the short of it is you have to flip the toggle switches on each row to cause an indicator light to power up at the end (supplying power to the next row and so on). When all the rows have been successfully configured, the 7 segment LEDs display an unlock code (or in this case, a code that leads to an unlock code).

Photoshopped to prevent the final sequence from being given away...

I have noticed that sometimes my landscape photos uploaded from iOS devices will display properly on said device through the app (or when viewing the image from Safari on the device) but when you load same image over the web on a Mac or PC they seemed to be oriented the wrong way. Are the browsers not interpreting the JPG metadata properly? Is it a conspiracy? I don't know, but it IS annoying.

Sometimes, it's just cheating pure and simple. There's a well-known cacher that "visits" our state every once in a while with his buddies. When they cache here, there are days where they split off into 2-3 different directions/cities for the day. Then they cross-log all over the place getting incredibly high counts (with no power trails involved). It's a silly and sad practice, made worse because other cachers look up to this person. Oh well. It doesn't affect how I play, and it shouldn't affect you either. Just have fun.

I cached with my family and we enjoyed our time together.

"Grumpy" cachers.

Impossible to say without knowing the details of the DB setup. It's well possible to have hundreds of requests queued up, waiting for results from the "challenges" count, while other requests fly. And don't hold your breath, you'll never know what was really causing the slowdown. Also, I was wondering how you managed to complete a challenge that's around here without ever having been here. But I see that log is already gone, and it's also a different topic I guess... On #1 - Sure. Depends on disk layout, user resource management, blocking locks, etc. etc. etc. I agree. The only thing that's odd is, if some requests on the DB are hanging up while requests for cache info via WAP and mobile apps are running fine, then why is the entire site hanging up? The two access paths I mentioned pull both user and cache data. So what data does the "web site" access that these apps do not? Session data? Hrmmmm. Ah who knows. They aren't paying me to dig into their problems and I need a beer. On #2 - I was messing with my wife and sister-in-law. (It's their bricks). Once the joke was over, I deleted it.

I wasn't implying that the DB was clogged up. But if the ASP contained some bad SQL (or the DB had some bad design issues considering the SQL being used), then the ASP threads would be tied up waiting for the DB to come back with a result. Meanwhile, the DB would be free to serve requests from other sources. Except the DB wouldn't be "free", it would be swamped with full table scans and the like. Hey, anyone want to start a betting pool? When it'll be up AND what root cause will be? :D Besides, in all honesty, I heard they went to some NoSQL / Name/Value pair DB. Can you even do a FTS in a name/value pair lookup?

They didn't only remove the avatars. They removed them a while ago, and it didn't help. Now they removed the find count from the logs. Seems like this helped. I'm gonna take a wild guess and say that the count of "challenges completed" was implemented by doing a full table scan, or at least an index count or something. Just a wild guess though, but if I'm right, then it's no surprise that it killed the performance. Beginner's mistake really. I was thinking bad execution plan in the DB as well, except wap.geocaching.com is fast and so are lookups from the mobile apps. I'm still sticking to the asp thread pool.

People here seem to like them: http://coord.info/GC23G7C http://coord.info/GC2XNHC

Problem appears to be aspx threads. Not image server. Image server fast. Database fast. Static (not aspx) files from IIS fast. IIS and ASPX threads on same server. Doesn't seem to be a server capacity issue, per say. ASPX thread issue could be lots of things: spinning code, too few threads allocated, back end data access by ASPX slow, spinning, etc. etc.

Rest assured, your location isn't the issue. It isn't their network or yours. This forum server and the main server are on the same subnet and you can get to this fairly quickly and easily. <technobabble> It seems the problem has little to do with the actual geocaching web server or the IIS threads themselves. It seems more likely that the ASP thread pool is what is having the issue (either directly or indirectly due to some underlying backend issue (e.g. self-imposed database issue (missing index, resource contention, etc), storage, firewall bandwidth between the front end web servers and the back end servers, etc.)) For example, static URLs such as: http://www.geocaching.com/articles/Brochures/footer/FAQ_Media.pdf respond VERY quickly. Anything ending with an .aspx is hanging miserably. All that said, If I were a betting man, since WAP and my iPhone app seem to be working ok during all this, I would lean away the back-end and towards the ASP threads on the server. That's my best guess based on no real information on how they are configured. </technobabble>