Jump to content


Photo

GSAK Errors


  • Please log in to reply
16 replies to this topic

#1 chefkimmo

chefkimmo

    Member

  • Members
  • PipPip
  • 152 posts
  • LocationHouston (Cy-Fair area)

Posted 13 May 2013 - 12:01 AM

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? 



#2 Baytown Bert

Baytown Bert

    Short fat dude with good hygiene

  • Senior Members
  • PipPipPip
  • 3,358 posts
  • LocationBaytown, Texas

Posted 13 May 2013 - 04:03 AM

I delete the database all the time.

TXGA SETX Representative


#3 Eagles1181

Eagles1181

    Senior Member

  • Senior Members
  • PipPipPip
  • 884 posts

Posted 13 May 2013 - 07:28 AM

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


Posted Image

#4 HoustonControl

HoustonControl

    Charter Member

  • Senior Members
  • PipPipPip
  • 9,933 posts
  • LocationBaytown

Posted 13 May 2013 - 08:13 AM

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.


img.aspx?txt=What+in+the+Hell?&uid=1dd8c

#5 KeyResults

KeyResults

    Senior Member

  • Senior Members
  • PipPipPip
  • 1,319 posts
  • LocationTomball

Posted 13 May 2013 - 08:41 AM

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/boar...ndpost&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
Why am I all sweatty and late? Umm...

#6 chefkimmo

chefkimmo

    Member

  • Members
  • PipPip
  • 152 posts
  • LocationHouston (Cy-Fair area)

Posted 13 May 2013 - 08:45 AM

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!! 



#7 chefkimmo

chefkimmo

    Member

  • Members
  • PipPip
  • 152 posts
  • LocationHouston (Cy-Fair area)

Posted 13 May 2013 - 08:49 AM

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.



#8 KeyResults

KeyResults

    Senior Member

  • Senior Members
  • PipPipPip
  • 1,319 posts
  • LocationTomball

Posted 13 May 2013 - 10:13 AM

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. :)
Why am I all sweatty and late? Umm...

#9 Eagles1181

Eagles1181

    Senior Member

  • Senior Members
  • PipPipPip
  • 884 posts

Posted 13 May 2013 - 01:34 PM

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


Posted Image

#10 TravelingGeek

TravelingGeek

    TravelingGeek

  • Senior Members
  • PipPipPip
  • 1,483 posts

Posted 13 May 2013 - 02:30 PM

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)


Posted Image

#11 Eagles1181

Eagles1181

    Senior Member

  • Senior Members
  • PipPipPip
  • 884 posts

Posted 13 May 2013 - 03:05 PM

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


Posted Image

#12 chefkimmo

chefkimmo

    Member

  • Members
  • PipPip
  • 152 posts
  • LocationHouston (Cy-Fair area)

Posted 13 May 2013 - 04:24 PM

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.



#13 2katz

2katz

    Senior Member

  • Senior Members
  • PipPipPip
  • 602 posts
  • LocationSpring

Posted 13 May 2013 - 05:51 PM

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.
Posted Image

#14 Baytown Bert

Baytown Bert

    Short fat dude with good hygiene

  • Senior Members
  • PipPipPip
  • 3,358 posts
  • LocationBaytown, Texas

Posted 13 May 2013 - 06:52 PM

Can Kenny be my BFF as well?  :angel:


TXGA SETX Representative


#15 KeyResults

KeyResults

    Senior Member

  • Senior Members
  • PipPipPip
  • 1,319 posts
  • LocationTomball

Posted 13 May 2013 - 07:42 PM

143 Bert. 143.  :)


Why am I all sweatty and late? Umm...

#16 KeyResults

KeyResults

    Senior Member

  • Senior Members
  • PipPipPip
  • 1,319 posts
  • LocationTomball

Posted 13 May 2013 - 07:53 PM

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 ;) ]


Why am I all sweatty and late? Umm...

#17 chefkimmo

chefkimmo

    Member

  • Members
  • PipPip
  • 152 posts
  • LocationHouston (Cy-Fair area)

Posted 14 May 2013 - 09:03 PM

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/boar...ndpost&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






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users