Quantcast
Channel: GSAK Forum
Viewing all 76122 articles
Browse latest View live

BadgeGen_V4.0 feed back by sbeelis - 2019-04-07

$
0
0
QUOTE (j-w @ April 07, 2019 09:24 am)
I found the following visual differences between 4.0.0.4 and 4.0.0.7, the "Total points" part is also not visible although it is in the HTML code.

user posted image

user posted image

Click on the "More belt information" and the two lines will re-appear. This is the same behaviour that BadgeGen V3 had and I requested that this text would be hidden again by default (and I'm very happy that taybee implemented that change :-)

Seach Query by Kai Team - 2019-04-07

$
0
0
Another way to do it (if composing the SQLite query gives you a headache, or you just want a quick and dirty way to limit the current filter and sort order, whatever it is):

GSK
MACROFLAG Type=Clear Range=ALl
MACROFLAG Type=Set Range=100
GOTO Position=Top
MFILTER WHERE=MACROFLAG

This will filter for the first 100 caches in the gird. wink.gif

BadgeGen_V4.0 feed back by sbeelis - 2019-04-07

$
0
0
QUOTE (j-w @ April 06, 2019 04:48 pm)
Today I ran v4.0.0.7 for the first time and the Belt picture and the 'other banners' are now showing at the bottom of all Tabs instead of only on the Badges Tab.

I think that is due to a lot of mismatched html tags.

I looked at the latest output of V4.0.0.7 thinking I might easily find the mismatched tag. However, after looking at the output, there are so many mismatching tags that my IDE is totally overwhelmed trying to match them.

The first screenshot shows lines 1 - 300 (the collapsed block on the first line contains the badge output from line 1 to 228 which is correct). I found so many mismatches on lines 229 to 300 that I gave up going through the rest.

user posted image

The second screenshot shows lines 2517 - 2567 which also contains numerous mismatching tags.

user posted image

I don't have time right now, but I'll try to look at the output of the V3 macro tonight to see how much of those mismatches were already in V3, but I am not surprised the tabbed output of FSG fails to properly place the BadgeGen output as it is now.

BadgeGen_V4.0 feed back by taybee - 2019-04-07

$
0
0
QUOTE (sbeelis @ April 07, 2019 11:48 pm)
QUOTE (j-w @ April 06, 2019 04:48 pm)
Today I ran v4.0.0.7 for the first time and the Belt picture and the 'other banners' are now showing at the bottom of all Tabs instead of only on the Badges Tab.

I think that is due to a lot of mismatched html tags.

I looked at the latest output of V4.0.0.7 thinking I might easily find the mismatched tag. However, after looking at the output, there are so many mismatching tags that my IDE is totally overwhelmed trying to match them.

The first screenshot shows lines 1 - 300 (the collapsed block on the first line contains the badge output from line 1 to 228 which is correct). I found so many mismatches on lines 229 to 300 that I gave up going through the rest.



I don't have time right now, but I'll try to look at the output of the V3 macro tonight to see how much of those mismatches were already in V3, but I am not surprised the tabbed output of FSG fails to properly place the BadgeGen output as it is now.

thanks sbeelis
find the errors got it working testing how
hope to upload monday NZ time
it was 2 close table tags missing

i think about 90 % of the errors are in V3

New geocaching api by martijnc - 2019-04-07

$
0
0
That's roughly what I did.
But can't you apply that automatically when accessing the API?
Or better just skip them in the answer?
There were also some caches with a strange code that come in using the old API:
GC3913J A4 V2 had a code "GC3913J U A4"
So when I reached around 500 caches, the load failed because of this strange code.
Speaking of a whaste of resources / time wacko.gif
I fixed it in the database, but any code not in the form
^GC[0-9A-Z]{1,6}$ will probably fail.
It would be nice if GSAK just skips those and puts them in the refresh log.
Martijn

New geocaching api by Kai Team - 2019-04-07

$
0
0
QUOTE (martijnc @ April 07, 2019 06:33 am)
There were also some caches with a strange code that come in using the old API:
GC3913J A4 V2 had a code "GC3913J U A4"

No one else has reported this is all the years that the old API was in use. To me, this looks like a waypoint that was received from a GPS after being sent with special tags - e.g.

QUOTE
%code %typ1 %name=2

would produce that exact code for that cache.

QUOTE
I fixed it in the database,

Yes, it's always better to fix an error like that at the source, rather than relying on software to compensate for errors in the data.

QUOTE
but any code not in the form
^GC[0-9A-Z]{1,6}$ will probably fail.

And you obviously know enough to filter for those caches before refreshing.

The bottom line is that users should not expect GSAK to refresh waypoints that have codes that are not from Geocaching.com. It is the user's responsibility to maintain the integrity of their database or to filer out incompatible waypoints before using the API.

More about API's whatever they are by stigvi - 2019-04-07

$
0
0
I am currently on the 122 version.

This is my Groundspeak api section. Is there anything wrong with it?

[Groundspeak api] http://gsak.net/board/index.php?showtopic=...ndpost&p=188943
#OwnerRefreshDays=1 https://gsak.net/board/index.php?showtopic=...ndpost&p=250706
#ApiUrl=oldapi
#ApiVersion=1
#ResetConnection=True http://gsak.net/board/index.php?showtopic=...ndpost&p=237519
#TokenExpireDays=5 http://gsak.net/board/index.php?showtopic=...ndpost&p=223955
#LogsPerCall=30 http://gsak.net/board/index.php?showtopic=...ndpost&p=222075
#LimitExceededRetries=5 http://gsak.net/board/index.php?showtopic=...ndpost&p=208271
#TimeOutSeconds=60
#AutomaticRetries=4
#RetryDelaySeconds=30
#EventTimeOutSeconds=120

[Custom Data]

More about API's whatever they are by Kai Team - 2019-04-07

$
0
0
QUOTE (stigvi @ April 07, 2019 07:10 am)
I am currently on the 122 version.

This is my Groundspeak api section. Is there anything wrong with it?

[Groundspeak api] http://gsak.net/board/index.php?showtopic=...ndpost&p=188943
#OwnerRefreshDays=1 https://gsak.net/board/index.php?showtopic=...ndpost&p=250706
#ApiUrl=oldapi
#ApiVersion=1
#ResetConnection=True http://gsak.net/board/index.php?showtopic=...ndpost&p=237519
#TokenExpireDays=5 http://gsak.net/board/index.php?showtopic=...ndpost&p=223955
#LogsPerCall=30 http://gsak.net/board/index.php?showtopic=...ndpost&p=222075
#LimitExceededRetries=5 http://gsak.net/board/index.php?showtopic=...ndpost&p=208271
#TimeOutSeconds=60
#AutomaticRetries=4
#RetryDelaySeconds=30
#EventTimeOutSeconds=120

[Custom Data]

No, it's fine. You could delete #ApiUrl=oldapi and #ApiVersion=1 but there's no need to delete them because they are commented out (#). Leaving #ApiUrl=oldapi in the file also makes it easier to switch between old and new API should the need arise.

Are you having a problem that leads you to ask the question?

More about API's whatever they are by stigvi - 2019-04-07

$
0
0
QUOTE (Kai Team @ April 07, 2019 08:14 pm)
QUOTE (stigvi @ April 07, 2019 07:10 am)
I am currently on the 122 version.

This is my Groundspeak api section. Is there anything wrong with it?

[Groundspeak api]    http://gsak.net/board/index.php?showtopic=...ndpost&p=188943
#OwnerRefreshDays=1      https://gsak.net/board/index.php?showtopic=...ndpost&p=250706
#ApiUrl=oldapi
#ApiVersion=1   
#ResetConnection=True    http://gsak.net/board/index.php?showtopic=...ndpost&p=237519
#TokenExpireDays=5    http://gsak.net/board/index.php?showtopic=...ndpost&p=223955
#LogsPerCall=30    http://gsak.net/board/index.php?showtopic=...ndpost&p=222075
#LimitExceededRetries=5    http://gsak.net/board/index.php?showtopic=...ndpost&p=208271
#TimeOutSeconds=60
#AutomaticRetries=4
#RetryDelaySeconds=30
#EventTimeOutSeconds=120

[Custom Data]

No, it's fine. You could delete #ApiUrl=oldapi and #ApiVersion=1 but there's no need to delete them because they are commented out (#). Leaving #ApiUrl=oldapi in the file also makes it easier to switch between old and new API should the need arise.

Are you having a problem that leads you to ask the question?

GSAK is asking for username and password each hour. And as I am using GSAK with several accounts, it is a tedious and frustrating job to update the accounts. I cannot use my macro either because GSAK suddenly asks for username and password in the middle of macro operations. And as it always do this with method 1, I have to abort and provide username and password with method 2 instead.

GSAK crashing failing to open apilog.txt by dsiv - 2019-04-07

$
0
0
I've been using GSAK for many years. Recently it will be in the process of updating caches when it will fail with "Cannot open file C:\Users\DSIV\Dropbox\GSAK\gsak8\apilog.txt". My db is on Dropbox and Dropbox was not syncing. I haven't had GSAK crash issues in years and in fact, the last issue I had was due to Dropbox sync, but again, Dropbox sync was turned off.

You can see that I had 4.3 GB of free memory and 1.1 TB of free disk space. My CPUs were getting a good workout from watching the system performance monitor.


GSAK has crashed many times in the past few days. This morning, as in most mornings, I successfully downloaded my PQs. I successfully updated about 20 caches. I then went to about 5,000 caches to refresh and it failed. Yesterday I experimented with refresh size and I couldn't where it would succeed and where it would fail.


A snippet from errors.txt. I could only attach one file, so I attached the apilog.txt, instead of the errors.txt file.

User:
-------------------------------------------------------
3.1 ID : DSIV
3.2 Name : DSIV
3.3 Email :
3.4 Company :
3.5 Privileges: SeShutdownPrivilege - OFF
SeChangeNotifyPrivilege - ON
SeUndockPrivilege - OFF
SeIncreaseWorkingSetPrivilege - OFF
SeTimeZonePrivilege - OFF

Active Controls:
-----------------------------------------------------------
4.1 Form Class : #32770
4.2 Form Text : Windows Task Manager
4.3 Control Class: THTMLButton
4.4 Control Text : <img src="idx:1" align="middle">Abort

Computer:
-----------------------------------------------------------------------------
5.1 Name : DSIV-PC
5.2 Total Memory : 15870 Mb
5.3 Free Memory : 4326 Mb
5.4 Total Disk : 2047.9 Gb
5.5 Free Disk : 1195.69 Gb
5.6 System Up Time: 3 days, 1 hour, 51 minutes, 36 seconds
5.7 Processor : AMD Phenom™ II X6 1100T Processor
5.8 Display Mode : 1920 x 1080, 32 bit
5.9 Display DPI : 96
5.10 Video Card : ATI Radeon HD 4250 (driver 8.970.100.3000 - RAM 512 MB)
5.11 Printer : Canon MX340 series Printer (driver 2.56.2.10)

Operating System:
--------------------------------------------
6.1 Type : Microsoft Windows 7 (64 bit)
6.2 Build # : 7601
6.3 Update : Service Pack 1
6.4 Language: English
6.5 Charset : 0

Network:
---------------------------------
7.1 IP Address: 192.168.001.102
7.2 Submask : 255.255.255.000
7.3 Gateway : 192.168.001.001
7.4 DNS 1 : 192.168.001.001
7.5 DNS 2 : 000.000.000.000
7.6 DHCP : ON

Call Stack Information:
--------------------------------------------------------------------------------------
|Address |Module |Unit |Class |Procedure/Method |Line |
--------------------------------------------------------------------------------------
|Running Thread: ID=66472; Priority=0; Class=; [Main] |
|------------------------------------------------------------------------------------|
|004CDEEB|gsak.exe |strman.pas |TStringManager |FileAppend |7038[7] |
|004CDEB0|gsak.exe |strman.pas |TStringManager |FileAppend |7031[0] |
|006E82A6|gsak.exe |cwe.pas | |FilePut |3894[5] |
|006E8248|gsak.exe |cwe.pas | |FilePut |3889[0] |
|74BEF0A5|KERNELBASE.dll| | |VirtualQueryEx | |
|004CDEEB|gsak.exe |strman.pas |TStringManager |FileAppend |7038[7] |
|004CDEB0|gsak.exe |strman.pas |TStringManager |FileAppend |7031[0] |
|006E82A6|gsak.exe |cwe.pas | |FilePut |3894[5] |
|006E8248|gsak.exe |cwe.pas | |FilePut |3889[0] |
|76CB9910|msvcrt.dll | | |memcpy | |
|74C446C7|oleaut32.dll | | |SysAllocStringLen| |
|00F72E74|gsak.exe |extra.pas | |tryfetch |7077[48] |
|00F72BA8|gsak.exe |extra.pas | |tryfetch |7029[0] |
|00F7443C|gsak.exe |extra.pas | |GcFetchV1 |7553[7] |
|00F743BC|gsak.exe |extra.pas | |GcFetchV1 |7546[0] |
|00F72916|gsak.exe |extra.pas | |GetCachesV1 |6997[45] |
|00F726DC|gsak.exe |extra.pas | |GetCachesV1 |6952[0] |
|00F6D1D7|gsak.exe |extra.pas | |RefreshCaches |5965[114] |
|00F6CC38|gsak.exe |extra.pas | |RefreshCaches |5851[0] |
|76658535|user32.dll | | |CallWindowProcA | |
|7665851F|user32.dll | | |CallWindowProcA | |
|009732C1|gsak.exe |stdrop.pas |TStCustomDropFiles|TargetWndProc |244[21] |
|7666D2A9|user32.dll | | |IsDialogMessageW | |
|7666D200|user32.dll | | |IsDialogMessageW | |
|766630A4|user32.dll | | |IsDialogMessageA | |
|76657355|user32.dll | | |CallNextHookEx | |
|00C408E4|gsak.exe |TntForms.pas| |GetMessageForNT |742[10] |
|00E437A3|gsak.exe |fOffline.pas|TfmOffline |appmanMessage |11955[139]|
|76647BC5|user32.dll | | |DispatchMessageA | |
|76647BBB|user32.dll | | |DispatchMessageA | |
|00FDD465|gsak.exe |gsak.dpr | |GSAK |347[124] |
--------------------------------------------------------------------------------------

Open Publish Logs from FetchFromDrafts by pogwog - 2019-04-07

$
0
0
Odd....mines not opening.

I reloaded your macro in it's original form. I had a couple of drafts on the gc.com server that needed to be pulled so I used the macro. It got a new token, grabbed the drafts, then I was returned to the main GSAK cache list. The Publish Logs window did not open. When I open it manually, the caches from the drafts are there.

I must be missing something in my setup... huh.gif

GSAK crashing failing to open apilog.txt by Kai Team - 2019-04-07

$
0
0
According to the error message, something on your computer is preventing GSAK from opening the file (i.e. something has the file locked). As you probably know, storing GSAK database files directly in cloud sync folders like DropBox is not supported. My advice is to store your GSAK Application Data folder elsewhere.

Open Publish Logs from FetchFromDrafts by pogwog - 2019-04-07

$
0
0
I'm even more confused now....

I compared my Publish Logs settings to yours. I saw that you have the AfterFetch.gsk set to run after fetch. I didn't know about this macro so I downloaded it and added it to my Macro to run after fetch line. I made sure that a particular cache was not in my GSAK db and then created a draft for that cache (wrote note). I then ran the FetchFromDrafts macro. It pulled in the draft AND added the cache! This does tell me that the Publish Logs settings are being read, but the window does not open...or stay open.

I also saw that in your macro you have a section in there specifically for your GSAK user. I commented them out and added lines for my user. See below.


# IF $currentuser="HHL"
# GcPublishFetch Type=File Settings=HHLs LogSettings File="$_AppData\macros\OnlineDrafts.txt"
IF $currentuser="pogwog"
GcPublishFetch Type=File Settings=FetchDrafts File="$_AppData\macros\OnlineDrafts.txt"


Several more tests were done with Publish Logs settings to make sure that my users setting were being used. They are.

I kinda see the screen flicker after the FetchFromDrafts macro runs. I closed out of GSAK and re-opened. A notification popped up about an update, so I did the update. I'm currently running 8.7.1.122 (previous tests were at 8.7.1.121). I ran all of those tests again on 122 and I'm getting the same thing, no Publish Logs window after fetch. sad.gif

I went through the configother.txt just to make sure there wasn't some setting to close the Publish Logs window after fetch. I didn't see such a setting. wacko.gif

Here are my Publish Logs settings:
user posted image

FindStatGen3.gsk - Favorite Karma by lignumaqua - 2019-04-07

$
0
0
I’m not sure how useful this is. As you have complete control over the number of favorite points you give out, it’s really a measure of that alone.

For example, in my own sorry case, I’ve never awarded a single favorite point as I never found the system that useful, so my ratio would always be infinity! rolleyes.gif

Conversely, if we used the number of favorite points you are allowed to allocate (the 10% number) then this is just a measure of caches found, and penalizes cachers with large numbers of finds, even if their hidden caches have large numbers of favorite points.

More about API's whatever they are by lignumaqua - 2019-04-07

$
0
0
I can see how trying to use several accounts at once would be problematic, the system isn’t really set up that way. The browser (whether you use method 1 or method 2) will only have one set of log-in cookies from Geocaching.com, so as soon as you log into one account you will log out of all the others. I’m not sure if GC.com requires you to be logged in when you request a token refresh, if it does, then your scenario will always fail. ph34r.gif

You likely got away with it with the prior API as it didn’t expire tokens as often, and didn’t use the OAuth refresh system.

New geocaching api by Seawind - 2019-04-07

$
0
0
Two days ago, my GSAK update ran perfectly, returning all 4,500 requested unfound caches in my area, and it ran fairly quickly.

This morning, I ran the exact same request, and it ran very, very slowly, then "completed" at 2,000 of the expected 4,500 caches. Subsequent reruns returned 750 and then 300 caches.

Are these issues related to the new API and still ongoing, or should I check anything on my end?

Thanks!

New geocaching api by Kai Team - 2019-04-07

$
0
0
QUOTE (Seawind @ April 07, 2019 10:22 am)
Two days ago, my GSAK update ran perfectly, returning all 4,500 requested unfound caches in my area, and it ran fairly quickly.

This morning, I ran the exact same request, and it ran very, very slowly, then "completed" at 2,000 of the expected 4,500 caches. Subsequent reruns returned 750 and then 300 caches.

Are these issues related to the new API and still ongoing, or should I check anything on my end?

You don't say which version of GSAK you are using - please go to Tools>Check for Newer Version of GSAK and download and install the latest version (8.7.1.122 as of this writing).

If that doesn't fix things, I suspect that there may be server overload issues at Geocaching.com, given that it's a weekend in most areas of the world. My advice would be to try again at a less busy time (e.g. very early in the morning or late at night or on a Tuesday, Wednesday or Thursday in the US) to see if the problem persists. If it's only a problem during busy times, Groundspeak will need to look at how they are allocating server time (right now they are still running both the old and the new API and I don't know how they've allocated resources to the new API). If the problem persists during less busy times, let us know and we can look into it further.

FindStatGen3.gsk - Favorite Karma by bene66 - 2019-04-07

$
0
0
You're right, my first approach would promote cachers who doesn't spent favorite points - and perhaps prevent people of spending favorites to get a good statistic.

So lets stick on the second approach.

Your argument with "penalize" cachers with much founds is the same by the "Caching Karma" itself.

I sometimes see cachers getting a good Karma by placing a Nanos at a touristic hotspot or placing a power trail of film boxes.
Other cachers put much effort in only a few caches - and are punished by the "Caching Karma".
My idea of the "Favourite Karma" shall compensate this effect.

An other possibilities is "Favorites per Found on own caches" - an overall favorite ratio. (Leaving the task, that I can't estimate, of filtering the premium logs)

Grid index out of range by SWIPEE - 2019-04-07

$
0
0
Hi,

I'm experiencing the same issue here. I did upgrade to 122 (GSAK states I'm on the last version when doing a version check).

How to reproduce (consistently in my situation):
- Try and publish logs for caches (source does not matter: file, GPSr, filter, current cache).
- Edit the log for the cache you want to publish
- Click on the 'Trackables' button. Things will start loading, but it errors out with the error 'Grid index out of range' and never lets me continue.

As it happens, we have one TB that is consistently in Visit All mode. In total we have 46 TB's in our inventory and the SQLLite DB contains 182 entries in 'PublishTrackables'.

It does not matter if the cache itself has a TB or not.

Hope this helps in solving this.
If you can point me on how to get the debug info to you, I'm glad to provide it.

Grid index out of range by Kai Team - 2019-04-07

$
0
0
Thanks, but all of that is already known. The problem is that Clyde does not have over 30 trackables. He needs both the debug information and the Geocaching.com log in credentials for someone who is having this problem so that he can access your 30+ trackables to try to reproduce the problem (he won't do anything with the trackables other than try to trigger the problem with the inventory in GSAK).

If you're willing to provide that information, send Clyde the debug information and then send him a private message (click on 'My Controls' at the top of a forum page to access the private message function) with your log in credentials and debug tracking number.
Viewing all 76122 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>