Unable to click from cache page to trackables listed

[+CCFwasG]

Is anyone else having this issue? It's happening to me on Chrome (latest version) on a PC. 

I can see a list of trackables that are (supposedly) in a cache, but every time I click one I get "Error 404:DNF". I gave it several hours... problem still there!
 

 

[+Max and 99]

Ditto, but for some of the trackables not all of them. For both the current list and previous list. 

[+barefootjeff]

18 minutes ago, CCFwasG said:

Is anyone else having this issue? It's happening to me on Chrome (latest version) on a PC. 

I can see a list of trackables that are (supposedly) in a cache, but every time I click one I get "Error 404:DNF". I gave it several hours... problem still there!
 

 

I'm getting the same message when clicking on the two trackables in my cache GC9M6X5, using Firefox 120.0.1 on Windows 10. I did a routine check on that cache yesterday and both trackables are still in it.

[+kunarion]

Trackables in the cache Inventory have URLs like https://www.geocaching.com/hide/details.aspx?TB=TB7Z7EE which are currently broken. 

But links to "Past Trackables" on a cache page have a URL like 

https://www.geocaching.com/track/details.aspx?id=6954432 which work.

 

https://www.geocaching.com/track/details.aspx?tracker=TB7Z7EE also works.

 

 

Edited December 13, 2023 by kunarion

[Nylimb]

Same here, using an old version of Firefox on an old iMac.  As a temporary workaround, click on the trackables link and then edit the resulting URL, changing "hide" to "track".

[+kunarion]

7 minutes ago, Nylimb said:

Same here, using an old version of Firefox on an old iMac.  As a temporary workaround, click on the trackables link and then edit the resulting URL, changing "hide" to "track".

 

Testing:

https://www.geocaching.com/hide/details.aspx?TB=TB7Z7EE

https://www.geocaching.com/track/details.aspx?TB=TB7Z7EE

 

Edited December 13, 2023 by kunarion

[+kunarion]

The bug (malformed URLs) may extend to more than just Trackables.  I'm clicking on a cache name link for any Trackable History log and getting an especially weird URL.  But it works fine if you drill down to the log itself.

 

Go here (for example) and click on any cache name in the Tracking History logs.

 

 

Edited December 13, 2023 by kunarion

[+worrellsquirrel]

Hello all,

 

Thank you for reporting this issue. I have passed the information along to our engineers so they can begin looking for a fix.

 

We appreciate your patience in the meantime.

[+msrubble]

I just logged my new trackable into a cache I own, to give it a starting location, and now I can't log it back out.

[+Viajero Perdido]

21 minutes ago, msrubble said:

now I can't log it back out

 

In your browser address bar, try typing "(TB" and see if the suggestions that pop up include the page for your TB.  (Works on some browsers.)

[+msrubble]

Thanks for the suggestion, but, no, I'm in incognito mode on Chrome.

I can see the trackable page. I can see the cache page. I cannot get to the trackable "in" the cache. Edited December 16, 2023 by msrubble
typo

[+Skippi]

If oyu can see trackable page, why you cannot click on "Found it? Log it!" link?

There you can select "Retrieve from <cache_name>".

[+msrubble]

Thank you! Sometimes I can't see what's right in front of my nose. I was considering marking it missing, because I think there's an option to calculate mileage from last known location.

[+CCFwasG]

On 12/13/2023 at 12:55 PM, worrellsquirrel said:

Hello all,

 

Thank you for reporting this issue. I have passed the information along to our engineers so they can begin looking for a fix.

 

We appreciate your patience in the meantime.

 

Any ETA for the fix? Still a problem on my end!

[+sbied]

Just to note that I'm seeing both the "/hide/" instead of "/track/" as well as the "/GC0" thing.   Chrome 120.0.6099.110 on Windows, not that it sounds like it matters.

[+shamik]

I don't know if this is a similar bug, but I tried to click on different trackables from my "Trackable Logs" page and get the 404 DNF message. If I click from my watch list, it works just fine. But I'd like to add some recent trackables to my watchlist and cannot.

[+GauPauMa54]

On 12/17/2023 at 4:11 AM, CCFwasG said:

 

Any ETA for the fix? Still a problem on my end!

 

The problem persists for me too...

[+worrellsquirrel]

Hello all,

 

The issue initially described by @CCFwasG is fixed; you can now follow links for trackables from cache pages. Clicking trackables from "Your Trackable Logs" is also fixed.

 

Please note though, there is a separate bug in which clicking on cache page links from any given trackable page leads to https://www.geocaching.com/geocache/GC0 (also a 404 error).

 

Our engineers are aware of this issue and hope to have a fix as soon as possible. Thanks for your patience in the meantime!

 

[+baracutio]

As stated in the subject, all cache links in a trackable log history point to 'https://www.geocaching.com/geocache/GC0' instead of the correct gc code.

 

Regards

[Keystone]

I merged the above post into this existing thread.  It was originally posted as a separate topic.

 

I also removed an off-topic post. Separate bugs should be reported in separate threads.

[+theedoek83]

The clickable links to caches in the Tracking History of owned trackables all point to geocache GC0 resulting in an error 404 page.

[+Sottiwotti]

I've noticed that this problem started a few weeks ago, hope it gets fixed soon

[Keystone]

The two posts above were originally posted in a separate thread.  I merged them into this existing discussion.

[+elrojo14]

20 hours ago, baracutio said:

As stated in the subject, all cache links in a trackable log history point to 'https://www.geocaching.com/geocache/GC0' instead of the correct gc code.

 

Regards

I came to report this after I noticed this last week and then logging some trackables today saw it was still an issue. Glad to see they are working on it. 

[+the Seagnoid]

Trackable logs show that the trackable is in or has visited a number of geocaches. The link to every geocache in the trackabvle log is https://www.geocaching.com/geocache/GC0 - which of course goes nowhere.

 

To see this, open up a trackable page, eg:

https://www.geocaching.com/track/details.aspx?tracker=TB9YP44

Hover over or click on the links to any of the caches that trackable has visited.

 

In the meantime we can get around the problem by clicking on the log link, and clicking to the cache from in the log.

 

 

[Keystone]

The above post was originally a separate thread.  I merged it into this existing discussion.

[Martenson]

If I go to any trackable's page (e.g. https://www.geocaching.com/track/details.aspx?tracker=TB962TN) all the links to the caches the trackable has visited are to `https://www.geocaching.com/geocache/GC0` which is mangled and clearly incorrect. It is the same when logged out and in different browsers.

Edited January 2 by Martenson
typos

[Keystone]

The above post was originally a separate thread.  I merged it into this existing discussion.

[+sbied]

worrellsquirrel, it's been quite some time:  when will we see the fix?

 

[+AutoMagicGeo]

It seems like the problem is still existing - it doesn’t works for me either. But the link at the top of the cache page at „Last Seen“ still works, so I use that whenever it’s possible. Are there any updates from the engineers at HQ?

 

Best regards

AutoMagicGeo

[+azdave1]

Stiil having the problem going from TBs to Caches.

[+omortsoN]

The problem persists many days later.
The link to every geocache in the trackable log is https://www.geocaching.com/geocache/GC0

[+GauPauMa54]

Still the same problem with the redirect on a TB page: the link points to GC0, which causes an error.

The problem has been persisting for a month now, is it that difficult to correct?

[+Nite*Owls]

It's been over a month now. Maybe it's time to get some new people on the bug fix team.

 

On 12/13/2023 at 11:55 AM, worrellsquirrel said:

Hello all,

 

Thank you for reporting this issue. I have passed the information along to our engineers so they can begin looking for a fix.

 

We appreciate your patience in the meantime.

[+JMrW]

On a TB page on a desktop browser I tried clicking the links to previous caches the TB has been to. Yet the click lands me on an Error 404: DNF page. Not the end of the world yet a bit annoying when I want to see the location of where this TB I have in inventory has been. Its been like this for a month or so.

[Keystone]

The above post was originally a separate thread.  I merged it into this existing discussion.

[+JMrW]

7 hours ago, Keystone said:

The above post was originally a separate thread.  I merged it into this existing discussion.

Thanks for addressing my comment. I also have noticed many comments with similar issue merged into this thread. Yet isn't my issue a separate "bug" than the original issue of unclickable Trackables links within a "cache" page? That issues is resolved (I remember experiencing that issue last month). Yet this issue is the cache links within the TB page itself not working and not the TB links within the Cache page. Does this make sense?

[+meninosousa]

i'm a great trackable nerd and honestly it's kind of disappointing that we are in february now and no signs of improvement. Groundspeak you have one job and we are actually paying you for that

[+the Seagnoid]

10 hours ago, meninosousa said:

i'm a great trackable nerd and honestly it's kind of disappointing that we are in february now and no signs of improvement. Groundspeak you have one job and we are actually paying you for that

Now that's unfair. Or even an outright lie. Their jobs are:

Geocaching application
Trackables (a mini-game within geocaching)
Adventure labs
Managing reviewers
Promotion

Policy
Manage servers
Pay the bills
And probably lots more

And each of these is a department in its own right. Geocaching is not run by a single person working out of a garage any more. Their developers are busy working on new features and modifying code for whatever new souvenir challenges are coming up. And doing back end stuff that we do not see (eg managing photo repositories, optimism SQL servers). They have project managers or product owners or the like whose job is to set priorities, and this problem has yet to be given a priority above other work (or maybe it has, and that other work is so low down it will never see the light of day!).

 

YOUR job is to realise how a software house ACTUALLY works, and to do your part within that structure. If you want this fixed you have to raise the priority. You already know how to do that. Do it better.

Sure, I disagree about the apparent prioritisation this bug's has been given. But frankly GC are pretty good at not fixing bugs for years and then rolling out a whole new interface instead. Maybe that is what will happen here (which I am sure will annoy the heck out of everyone, having to wait two more years before this is resolved)

[+barefootjeff]

34 minutes ago, the Seagnoid said:

Now that's unfair. Or even an outright lie. Their jobs are:

Geocaching application
Trackables (a mini-game within geocaching)
Adventure labs
Managing reviewers
Promotion

Policy
Manage servers
Pay the bills
And probably lots more

 

I see you don't include maintaining the geocaching.com website in your list. I guess for most phone-only cachers these days, the website is irrelevant. In any case, I doubt the technical staff would be involved in managing reviewers, promotion, policy and paying the bills. Even in the small company I worked for with just 5 employees, we had separate staff doing the technical, administrative and marketing jobs.

[+MartyBartfast]

8 hours ago, the Seagnoid said:

1: Their developers are busy working on new features and modifying code for whatever new souvenir challenges are coming up.

...

2: whose job is to set priorities, and this problem has yet to be given a priority above other work

...

3: YOUR job is to realise how a software house ACTUALLY works,

...

4: If you want this fixed you have to raise the priority. You already know how to do that. Do it better.

...

 5: But frankly GC are pretty good at not fixing bugs for years and then rolling out a whole new interface instead.

 

1: And that's the problem they're so blinkered and focused on changing stuff (which often nobody has asked for) that they frequently break what's already working.

 

2: They should prioritise keeping the lights on and fixing stuff that doesn't work before pushing out new pointless "improvements".

3: That's just nonsense, as a customer it's not our job at all. I'd like to see you take your car into the garage because it's not driving well and have the mechanic tell you that it's YOUR job to understand how the engine management system works!

 

4: Really?  please tell me how we can raise priorities on bugs, because so often when they're reported they seem to be ignored for months or years and we get scant feedback from GS and there comes a point where bashing your head against the same brick wall stops being fun.

5: I would phrase that as "But frankly GC are pretty bad at not fixing bugs"

This particular bug can't be a difficult fix, admittedly if they were on the verge of a larger release that would fix it then it's OK that they haven't been diverted to roll out a specific fix for this, but then they ought to be telling us that the fix is in the pipeline, instead it's silence (which is the norm).

 

[+the Seagnoid]

On 2/2/2024 at 9:24 PM, MartyBartfast said:

5: I would phrase that as "But frankly GC are pretty bad at not fixing bugs"

I disagree. "Not fixing bugs" is something they are actually pretty good at. Some time ago I posted a list of about 8 bugs that were outstanding for years. Some got fixed by providing a whole new interface (arguably not a fix), other still exist. "Fixing bugs" is the thing they are bad at!

 

On 2/2/2024 at 9:24 PM, MartyBartfast said:

2: They should prioritise keeping the lights on and fixing stuff that doesn't work before pushing out new pointless "improvements".

What? Like keeping the servers running? Actually GC are already pretty good at this. There are very few server downtimes. The phrase "keeping the lights on" refers to the basics, and one (set of) broken links comes nothing close to being a basic part of identifying caches, locating, and then logging them.

[+the Seagnoid]

On 2/2/2024 at 1:30 PM, barefootjeff said:

I see you don't include maintaining the geocaching.com website in your list. I guess for most phone-only cachers these days, the website is irrelevant. In any case, I doubt the technical staff would be involved in managing reviewers, promotion, policy and paying the bills. Even in the small company I worked for with just 5 employees, we had separate staff doing the technical, administrative and marketing jobs.

Leaving out the website was an oops. Rather a big one. Sorry, GC!!  And re the separate jobs, the comment was that GC has only one job, not that the programming staff has only one job.

 

But back to the topic on hand... GC - When is this bug fix scheduled?

[+MartyBartfast]

28 minutes ago, the Seagnoid said:

What? Like keeping the servers running? Actually GC are already pretty good at this.

That's not difficult, contrary to popular belief if you have a server that works it will usually carry on working as long as you don't mess about with it too much, barring H/W failures which can be countered by virtualising or H/W redundancy - in any case the servers are almost certainly from a service provider so that aspect is probably something to credit the service provider with and not GS.
 

I've been doing this for my whole career and it's not unusual to have systems that run without downtime for years, 3+ years+ in my current job  and 7+ years in a previous life, but those servers that get patches, updates or application upgrades   several times a year  will avoid production issues by pre-production testing (which GS seem woefully bad at) and any update that gets into production and results in failures or disruption to the customer will be reverted within hours, or fixed within days.
 

46 minutes ago, the Seagnoid said:

I disagree. "Not fixing bugs" is something they are actually pretty good at.

They're not very good at fixing this one, which should be easy.
And they still haven't fixed (or even acknwleged) this from almost 2 years ago:
 

 

[Keystone]

Discussion in this thread should be limited to the bugs about links between trackables and cache pages.  Other unrelated bugs should be discussed in separate threads for those bugs.  Thanks.

[+PMHerz]

Any progress?

[+shamik]

I am thinking this is related to the same bug. Used to be able to go to the trackable and click on a cache where a TB had been placed. Now get the DNF page just like going from a cache page and clicking on one of the trackables listed.

[+GauPauMa54]

After more than forty posts on this subject, when will this bug be fixed?

[+doffy_74]

May I join?

 

I was trying to find out where my TB (https://www.geocaching.com/track/details.aspx?id=9312679) was placed and the link ended up on the 404 page.

 

All the links following "placed it in", "took it to", "retrieved it from" are the same (https://www.geocaching.com/geocache/GC0). Seems odd that the names of the cache or event the TB had interaction with is the correct one, but not the URL to it. It worries me a little this has not been fixed in the three months since it first appeared. Did someone accidentally delete the information in a column with the GCcode in a database table connected to the TB logs?

[+CCFwasG]

I honestly can't believe that something THIS basic is still not fixed. I am still unable to click through and find a trackable. The link simply does not work, Error 404 etc. It's a pretty basic function and I seriously doubt it is a difficult bit of programming to fix. COME ON Groundspeak. PLEASE FIX.