oregon 700 not taking me to next closest geocache.

[+RussLinda114]

Hey guys. I have a garmin oregon 700 which we use for geocaching. I've been using it for over three years without trouble until recently. The problem i am having is that after finding a geocache i always hit find next closest, but instead of taking me to the next closest it takes me to the one i just found. This happens mostly when the next geocache is over a mile away.  Is there a setting for this?

[+Atlas Cached]

No setting for this.

 

I personally neve ruse that function, I always just finish logging the cache I am at, then open the map or geocache list and manually select the next geocache I want to navigate to.

 

I rarely do them in order of proximity.

[+barefootjeff]

5 hours ago, RussLinda114 said:

Hey guys. I have a garmin oregon 700 which we use for geocaching. I've been using it for over three years without trouble until recently. The problem i am having is that after finding a geocache i always hit find next closest, but instead of taking me to the next closest it takes me to the one i just found. This happens mostly when the next geocache is over a mile away.  Is there a setting for this?

 

I've had that happen occasionally. I'd thought it might have been because I had two instances of the cache on the device (one in a PQ and another in its own GPX file) but I've never gone checking afterwards. Instead I just record another find on the cache I just found and the next closest then works correctly. I don't use the geocache_visits.txt file to create drafts, though, as I rarely find more than a handful of caches in a day, so I don't know whether doing that creates duplicates.

[Moun10Bike]

This happens to me all the time with a variety of Garmin units. It seems to occur if I select the option to navigate to the next cache too quickly after marking a find on the current one. It's as though the system has not yet had a chance to mark the current one as found before searching for the next closest unfound one, so it sees it as an unfound opportunity. I have never seen this behavior if I remember to wait a second or two before selecting the option to navigate to the next unfound.

[robertlipe]

Seriously. Does anyone else ever get the urge to just drive to Olathe and start wandering the streets until you find a software engineer at Garmin and actually take them geocaching with their own devices? If it is a case where the UI is blocked behind a thread stalled on an SD write and is able to pull the same record again before noticing that this one has just been shot down, that's really silly because it means their design has multiple sources of truth for a really fundamental data item. That's not a case of a missed mutex; that's just a bad design. (Duly noting that speculating about design from speculation of bug sources is a bit silly....)

A human should never have to count bananas between actions on devices of this kind of computing capacity.

I do remember seeing variations of this as far back as the 450. (I stopped buying at the 6x0 as that's also when I 'retired' from geocaching..) The "mark as found and find next" process has long been a frustrating mess of required keystrokes, muscle memory, and flakiness. I do remember conditioning myself to either bounce back to the map to select the next, which always seemed immune from this weirdness (and was often more strategic when power caching in a city) but that was a long time ago in tech years.

So I can't offer anything actionable on the 700 specific (sorry - I'll moderate myself as unhelpful) but I will offer a sympathetic shoulder that this seems to have loooong been a problematic code path for Garmin, even if I'm being charitable about the frequent full-device crashes in this general area that persisted from Colorado through at least the 600.

 

[+RussLinda114]

On 6/10/2021 at 1:38 AM, barefootjeff said:

 

I've had that happen occasionally. I'd thought it might have been because I had two instances of the cache on the device (one in a PQ and another in its own GPX file) but I've never gone checking afterwards. Instead I just record another find on the cache I just found and the next closest then works correctly. I don't use the geocache_visits.txt file to create drafts, though, as I rarely find more than a handful of caches in a day, so I don't know whether doing that creates duplicates.

I have also recorded another find on a geocache that I had just found then everything runs normal.What is weird is that this just started happening to me after years of trouble free use.

[+RussLinda114]

On 6/10/2021 at 12:03 PM, Moun10Bike said:

This happens to me all the time with a variety of Garmin units. It seems to occur if I select the option to navigate to the next cache too quickly after marking a find on the current one. It's as though the system has not yet had a chance to mark the current one as found before searching for the next closest unfound one, so it sees it as an unfound opportunity. I have never seen this behavior if I remember to wait a second or two before selecting the option to navigate to the next unfound.

Thanks I’ll try that.

[+colleda]

I always go back to the map after a find as the next nearest may be on a loop where there are others to do, possibly, in order or there could be a river/gorge/ravine/highway in the way.

[+Atlas Cached]

7 hours ago, colleda said:

I always go back to the map after a find as the next nearest may be on a loop where there are others to do, possibly, in order or there could be a river/gorge/ravine/highway in the way.

 

Exactly.

 

The 'Next Closest' is frequently not the next geocache in sequence when physical barriers are included in the equation This function is really only useful in a large, flat open area.

 

Certainly, it should work correctly, and appears to do so if the geocacher waits a minute before selecting it.