Jump to content

Unable to click from cache page to trackables listed


CCFwasG

Recommended Posts

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.

  • Helpful 1
Link to comment

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 by kunarion
  • Upvote 1
  • Helpful 2
Link to comment
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 by kunarion
  • Helpful 1
Link to comment

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.

 

image.jpeg.4c7dc15df70501186b298d3c96d69440.jpeg

 

Edited by kunarion
  • Upvote 1
  • Helpful 2
Link to comment
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!

  • Funny 1
  • Helpful 1
Link to comment

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.

  • Surprised 1
Link to comment

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!

 

  • Upvote 2
  • Helpful 4
Link to comment

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.

 

 

  • Upvote 1
Link to comment

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

Link to comment

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.

  • Upvote 1
  • Funny 1
Link to comment

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.

  • Upvote 1
Link to comment
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?

Link to comment
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)

  • Upvote 3
  • Funny 1
  • Helpful 1
  • Love 1
Link to comment
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.

  • Upvote 1
Link to comment
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).

 

  • Upvote 7
Link to comment
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.

Link to comment
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?

Link to comment
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:
 

 

Link to comment

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.

  • Upvote 2
Link to comment

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?

  • Upvote 2
Link to comment

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. 

  • Upvote 3
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...