EngPhil

Geosphere goes through some extraordinary contortions to get it right. It shouldn't have to, but it does. (And does a very good job of it, IMO.)

Correct. UTC+10:00. The further east you go, the worse the problem becomes.

Similar here. Chrome seems OK-ish (it still opens new tabs where it should be opening content in the same tab). Safari also seems OK-ish (it still opens new tabs where it should be opening content in the same tab). Firefox viewing my own profile opens blank tabs instead of content. Firefox viewing someone else's profile tries to display content but stalls out trying to load some element(s), resulting in a blank brown page (it's been spinning for several minutes now....)

I'm going against the flow here. At first I actually kinda liked it. The more I see it, the less I like it. Given that, in this case, you can hardly say that "only those who come to the forums complain, the feedback we get elsewhere is positive", I'm curious as to why this is so? It's clear that there's a significant number of folks actively annoyed by this change (and for plausible accessibility reasons, too)..... surely at least an optional, easier-on-the-eyes skin could be added for them?

Yes, this would be the ideal solution. That way you could verify your email account's "primary" address, but still use a different gc.com "primary" address for MC correspondence. Alternately, (or better still, additionally), the MC verification could check both the "From" and the "Sender" header for a match.

What planet are you on that has 3650-day years, and how many geocaches are there on it?

Why limit it to the primary address? Any (validated) addresses should do...

Thanks! Haven't tried it yet, but this should mitigate at least one of the biggest problems of the MC.

In addition to all the other good reasons alreadt given, ...in that case they shouldn't be logging it again anyway, as their old log will now simply show under their new username.

Wow, I didn't realise reviewers had that option. Yes, please, if its good enough for the reviewers, it's surely good enough for the rest of us!

IIRC souvenirs get the date on which the relevant log entry was submitted online, not the date of the log, which is not necessarily the same.

I think it's around 30 minutes. But, honestly, who really cares if "this log has been edited", and why????

If you use Chrome, Opera or Safari, install Tampermonkey and this script and you'll be able to edit the coords on any cache, not just Mystery and Multi. The limitation based on cache type is purely artificial, and I really don't see why the Frog doesn't just remove it.

THANK YOU, seandynamite. Sincerely. Thank you. I'm still not a fan of the whole message centre thing, but this at least should make it usable.

If any of my "network manager" co-workers suggested that, I'd be suggesting they start looking for a new job....

.....welcome to the type of frustration that the rest of the world has always had to deal with

To be clear, I'm generally not too badly affected personally with this problem, since I use an app that has some seriously twisted logic buried in it to ensure that log dates end up correct. (It involves calculating deltas between my local time and Seattle time, and crafting a timestamp that is on the same calendar day in both timezones...) I also usually use field notes, and complete the logs sometime later at home, but whether I do that or log from the field (usually only for an FTF), this app gets it right. However, anyone using the Frog's own apps will invariably suffer incorrect dates. So around half of all logs tend to be off by a day -- leading to some rather bizarre chronology of logs online, and caches being disabled the day before being found (since you can't correct the date on a "Disable" log, amongst others....)

Spare a thought for those of us who have this problem for anything logged before 17:00, then Log dates on all caches over here are a joke. Roughly half will be wrong by a day. But since the problem doesn't affect those living around the Lilypad, it's not a priority to fix. It's been broken forever, but with the trend towards logging in the field, it's just getting worse and worse.

For completeness, I'd also add something like AddGeocacheToWatchList RemoveGeocachesFromWatchList GetWatchList

Not sure how you got a 60CSx into mass storage mode for internal memory. Should never be possible. If there even IS a GPX folder in these older units, you'd never be able to find it. (emphasis in original added by me) Since Team Professor X saw the USB mass-storage device, I assumed it had a microSD card in it. ecanderson is correct in that the internal memory does not (in my experience anyway) present via USB mass storage on the 60CSx. In that mass storage device, there should be a Garmin directory, and within that, a GPX directory. That's where you want to drop your GPX files. (I don't have a microSD card handy to put into my 60CSx at the moment, so I can't walk through this right now....)

You need to drop it into the /Garmin/GPX directory (if I recall correctly.)

Very interesting, st3phan! I'd long suspected this was possible, and there was merely an artificial restriction within the webpage itself, but my lame attempts at hacking the Javascript (I don't speak it, either) had not been able to prove it. I can confirm, with that script, coords of (at least) Traditionals can be updated, and the updated coords even flow through to API consumers. This really suggests that it would cost Groundspeak even less effort to implement this request -- just remove the code that is artificially blocking it now! Hey, HQ -- any chance you could allocate a few minutes of dev time to fix this one up?

Packet loss at a single hop in the trace with no loss after it is not indicative of a fault. The router is doing its job, passing packets back and forth. Responding to traceroutes is right at the bottom of its priority list. If it has better things to do (like, say, routing packets) then your traceroute gets ignored. The fact that there is zero loss after that hop confirms that there is not a problem there at all. The packets are getting through just fine. If the loss started at one hop and continued in multiple subsequent hops, then it would indicate a problem.

Are you exploring the idea of making the MC two-way compatible with email? Such that email replies to email notifications of MC messages end up back in the MC? If not, can you please do so? It would address many (not all, but many) of the gripes people have about the current MC implementation. Thanks.....

Go to "Settings" then "Linked Accounts / Geocaching.com" and "Unlink", then "Link" your account again. You'll no doubt need to do that dance every 60 days. Hopefully Geosphere gets some developer love sometime soon, and can be told to get a new token automatically, but I'm not holding my breath