Why is our IPv6 geolocation database still so confused?

Alright, AdsVolt fam, I'm back with what feels like an ongoing saga – the never-ending quest for decent IPv6 geolocation. It's becoming a persistent headache, honestly, like our data has developed its own quirky personality and decided some IPv6 addresses just don't want to be where they're supposed to be.

The core problem remains: despite our previous attempts to wrangle it, specific IPv6 ranges are still consistently mapping to wildly incorrect locations. Our "What is my City Name" tool, which is usually pretty spot on for IPv4, looks absolutely silly when it tells someone in Berlin they're suddenly vacationing in rural Montana. It genuinely feels like our geolocation database is just making things up for these particular ranges, completely throwing off our IPv6 geo-location accuracy.

We've tried a bunch of things, hoping one would be the magic bullet, but to no avail:

• Regularly updating our MaxMind/IP2Location data feeds. We're on top of the latest releases, but these stubborn ranges persist.
• Cross-referencing problematic IPs with other major geo-IP providers. The frustrating part? They often agree on the wrong answer! It's like they're all in on the joke.
• We even tried some manual overrides for critical, high-traffic ranges, but that's obviously not scalable for the volume of inaccuracies we're seeing.
• Checked for obvious ISP routing anomalies or BGP weirdness. While that can be a factor, nothing stands out consistently across all the problematic IPv6 blocks.

Here's a snippet of our console output showing the kind of frustrating inconsistency we're dealing with:

# Querying a known problematic IPv6 address
$ geoip_lookup 2a01:4f8:c010:1::1
{
  "ip_address": "2a01:4f8:c010:1::1",
  "city": "Helena",
  "region": "Montana",
  "country": "United States",
  "asn": "AS24940 Hetzner Online GmbH"
}

# Actual expected location for 2a01:4f8:c010:1::1 (based on ISP data and user reports)
# City: Nuremberg, Country: Germany

So, I'm reaching out to the collective wisdom here. Has anyone cracked the code on advanced debugging strategies or alternative approaches when standard geolocation database updates just fail to fix these persistent IPv6 inaccuracies? Has anyone successfully 'retrained' their geo-IP data for stubborn IPv6 blocks, or found a way to reliably correct these kinds of systemic errors that impact overall IPv6 geo-location accuracy?