GSAK Errors

17 posts in this topic

Posted · Report post

I have spent a little bit of time searching the web to find an answer but thought I would try here.  I am having is two errors - one of them is not the right number of caches (GSAK shows one number and Geocaching.com shows another).  I have now had it both with GSAK show more and now it is showing less than I think I have found.  The first time was more than what I had found and went through one by one to find that GSAK was showing a DNF as a found... So I deleted that cache.  Easy enough other than the time to look at each one, one at time until I found the error.

 

Before I go back one by one to find the problem, I am wondering if anyone has had this problem and if so, how did you resolve it? 

 

My second error is that I am noticing that random caches finds have different dates than when I actually found them and some without dates.  I have found something on the GSAK site about the dates being wrong but it was posted in 2011.  Can anyone help me to figure out how to fix this?

 

I was thinking I could probably manually fix these errors but I am wondering it may keep happening so it would be wasted time. 

 

Should I completely delete my database and start over? 

Share this post


Link to post
Share on other sites

Posted · Report post

Tell me more about the database you are running.  IS it just found caches?  Is it everything in the Houston area?  Do you have corrected coordinates in it (for either puzzles or multis)?  How many total caches do you have in there?

 

Another possibility with GC.com showing more finds than GSAK is that you might have logged the same cache as found more than once.  GC.com looks at the number of "Found it" log entires while GSAK looks at the number of caches that you have logged at least one "Found it" log to.  

 

Before you delete anything, open up a new database and import a "my found caches" pocket query into it.  See if that matches GC.com.  If not that you have probably double logged something.  If so, then the problem is probably in your database somewhere.

 

Eagle

Share this post


Link to post
Share on other sites

Posted · Report post

There is a macro that can search your database and find double-logged caches.  I agree with Eagles -- download a fresh My Finds PQ and open it in a new database and see how it matches up.

Share this post


Link to post
Share on other sites

Posted · Report post

Kim, this happens to everyone sooner or later. It's common to have founds get out of sync now and then. Stay calm. Don't delete anything you haven't copied or backed up. Your mission is to figure out which count is correct: GSAK or GC. FTF real time logging w phone is the usual culprit for the scenario you describe. You've simply logged a find on GC.com for a cache not yet known to GSAK. This will cause GC found count to be higher. There are a few other scenarios too. 1. Create a new GSAK database of your found according to GC. Name it myfindsGC. Make sure it matches found count on GC.com 2. Next, on a copy of your working GSAK DB, name it myfindsGS, filter out everything but "found". This number should be smaller than "myfindsGC" DB from what you've said. 3. Now download GSAK macro called "CompareDBs" when you run this macro you will simply enter each of the DBs in question to identify the difference(s) between the two. http://gsak.net/board/index.php?showtopic=7423&view=findpost&p=169983 It should be obvious to you what to do once you run the comparison macro, but if not, PM and Ill help you through it. It is a really useful and important macro! Also, ill post a video of this scenario and a couple othe common ones ASAP.

chefkimmo likes this

Share this post


Link to post
Share on other sites

Posted · Report post

I will run it on a new database tonight.  Praying it isn't a double cache because then my milestone won't be there... GSAK says I have 999 and geocaching.com says 1,001 so I would be sick to have set a goal for yesterday and made it feeling good about it, to have not really reached.  I know it can easily get 2 more but it is just the thought. 

 

When I had the problem before when it was the other way, it was that GSAK kept showing a DNF as found.... maybe it is the same?  If I run it in a new database tonight I don't know and guess I will need to compare all my finds.  I will work from the present backwards since

 

More info on my database -

 

Is it just caches found?  No, it includes caches in several areas including Houston, Little Rock, Nacadoches, Waco

 

Total caches is (estimated since I am at work) over 9,600...

 

Do I have corrected coordinates in it?  Nope, haven't gotten this done but have thought I need to keep track of these for the future.  Seems when I write them on my hand in the field it goes away!! 

Share this post


Link to post
Share on other sites

Posted · Report post

Kenny, thanks for your information.  I will do what you said and let you all know what happens.

 

 

Do you have any idea why I have some caches with dates different than my finds.  The only way I noticed on some of them is I was looking at a couple caches and saw that the date I made the find (showing in GSAK) was before I started caching.

Share this post


Link to post
Share on other sites

Posted · Report post

GC.com is always master when it comes to dates found. However, the date it uses for found is always what was reported when logged. GPSr may have had bad date/time is a common cause of erroneous "past" date. PC used for publishing using GSAK or other Garmin programs could also cause incorrect date also. No worries though, the dates can be changed by editing your logs. No biggie. :)

Share this post


Link to post
Share on other sites

Posted · Report post

Once you get this sorted out I would start separating databases.  Make one for Waco, one for Little Rock, ect...  Managing smaller databases will speed up filter times and is just generally easier.  

 

As far as correcting the log dates, once you have the errors figured out upload your "my find pocket query" and it should correct the dates.

 

Eagle

Share this post


Link to post
Share on other sites

Posted · Report post

I keep a database for:

 

MyHides

MyFinds

NotFoundNearMe 

 

 

I also have two or three "WIP" databases that I use, empty, and reuse.  For example, last month I was using WIP1 for my trip to Delaware and PA and I used WIP 2 for planning for Geowoodstock in Florida.  Both of these can and will be wiped out and refreshed when I'm done with them as any "Finds" will get pulled into myFinds.   (WIP=Work in Progress)

Share this post


Link to post
Share on other sites

Posted · Report post

I keep a database for:

 

MyHides

MyFinds

NotFoundNearMe 

 

 

I also have two or three "WIP" databases that I use, empty, and reuse.  For example, last month I was using WIP1 for my trip to Delaware and PA and I used WIP 2 for planning for Geowoodstock in Florida.  Both of these can and will be wiped out and refreshed when I'm done with them as any "Finds" will get pulled into myFinds.   (WIP=Work in Progress)

 

I do something similar, only when I dumb them I normally toast the entire database and start over.  Currently have a HoustonALL (both found and unfound), My finds, My hides, Archived (comes in handy for puzzles sometimes) and then a couple for various challenges that I am working on.

 

Eagle

Share this post


Link to post
Share on other sites

Posted · Report post

Interesting, I didn't realize it would be good to separate them out.  I also have a couple other databases but the one has the most in it.  I think I had one for Waco but not sure of the others.  I also had one to figure out what caches I still needed to log for Brandon so that was deleted last night... I was kind of hoping that was what was causing the problem --- but noooo.

 

 

As far as the dates go, something i was reading on the GSAK website last night indicated it would keep messing up unless you checked a certain box.  (keep in mind the thread was from years ago)  I need to look that up because I don't want to spend a ton of time fixing it and then have it mess up again when I did my next Pocket Query of my finds.  If one of you happen to know what I mean, could you point me in the right direction to save some time.

Share this post


Link to post
Share on other sites

Posted · Report post

Kim - I have one master database for caches and make a new temporary one if planing a trip out of state. Afterwards, I delete once i return and load my finds in the master. Although, I do have an additional database for trackables and a few additional that are required for specific macros to run. I prefer to keep things simple and not deal with many databases. Kenny is working on some potential options for you and will forward once done. Not sure what the checkbox is, he suggests that you disregard that, for now. Fix one thing at a time.

Share this post


Link to post
Share on other sites

Posted · Report post

Kim, 

 

I'm kinda of the opinion that GSAK is a very individual thing and that over time you'll sort out what's right for you in terms of organizing your data. I think that as you acquire lots of stuff to track it becomes beneficial to break things up. 

 

I like to think of GSAK databases as I think of Spreadsheets, and create and delete them routinely as required. They're cheap! Just always remember to back up and you'll always get out of a pickle. And, be sure to copy a backup set off of your computer into a cloud drive or memory stick or whatever regularly too. After a while the corrected coords of all solved puzzles and trackables history and collections, not to mention hide and log histories become very precious indeed! [speaking of puzzle solution GSAK DB's, if any of the hgcs esteemed puzzle-heads needs me to compact and defrag theirs I'll be happy to help! I promise I won't peek long ;) ]

Share this post


Link to post
Share on other sites

Posted · Report post

Kim, this happens to everyone sooner or later. It's common to have founds get out of sync now and then. Stay calm. Don't delete anything you haven't copied or backed up.

Your mission is to figure out which count is correct: GSAK or GC.

FTF real time logging w phone is the usual culprit for the scenario you describe. You've simply logged a find on GC.com for a cache not yet known to GSAK. This will cause GC found count to be higher. There are a few other scenarios too.

1. Create a new GSAK database of your found according to GC. Name it myfindsGC.

Make sure it matches found count on GC.com

2. Next, on a copy of your working GSAK DB, name it myfindsGS, filter out everything but "found".

This number should be smaller than "myfindsGC" DB from what you've said.

3. Now download GSAK macro called "CompareDBs" when you run this macro you will simply enter each of the DBs in question to identify the difference(s) between the two.

http://gsak.net/board/index.php?showtopic=7423&view=findpost&p=169983

It should be obvious to you what to do once you run the comparison macro, but if not, PM and Ill help you through it. It is a really useful and important macro!

Also, ill post a video of this scenario and a couple othe common ones ASAP.

I worked on this for quite a while last night... The new database in #1 now shows I have 996.  I have gone through the easier ones... virtuals, events, multi's, etc - ones I don't have many and all those numbers match and then spent time on the traditionals to figure out what is missing. 

 

Thanks for all the help and hopefully I will get this figured out tonight... or tomorrow

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now