Jump to content
Sign in to follow this  
Followers 3
sloth96

Have balance but cannot download caches

Recommended Posts

So using GSAK I had downloaded All my full quota yesterday.

 

Then I tried downloading some full caches this morning.  I was getting the "cannot get more than 16000..." message.  However a quick check of my balance showed I had over 15000 as the time had just turned over. The same 16000 message appeared when I tried downloading again.

 

Additionally cachetur had pulled some from this newly refreshed quota.

 

It is not clear what is going on.

Share this post


Link to post

"Some" caches (16000?) :rolleyes:

What settings did you use? If you used the same settings it's normal you get the message.

It also seems that you can only get 10000 full caches in one go (GS limit) so you might want to split the 16000 in two 8000 groups.

 

Share this post


Link to post

Cachetur had pulled like thirty.  The difference between 16000 and something above 15000.

Share this post


Link to post
20 hours ago, on4bam said:

"Some" caches (16000?) :rolleyes:

What settings did you use? If you used the same settings it's normal you get the message.

It also seems that you can only get 10000 full caches in one go (GS limit) so you might want to split the 16000 in two 8000 groups.

 

I don't think that is the case. The limitation is that you can't have 10,000 < (skip + take). So if your geocache search has over 10,000 caches in the result set, you're only able to retrieve those that fall in the first 10,000 of the result set. It's not an issue with the number of caches you try to retrieve, but with where the caches you try to retrieve fall in the result set. That is, you can retrieve caches 1 to 10,000 but you cannot retrieve caches 10,001 and greater, even if you first try to retrieve caches 10,001 to say 10,050 (skip = 10,000, take = 50).

Share this post


Link to post
9 minutes ago, Corfman Clan said:

I don't think that is the case. The limitation is that you can't have 10,000 < (skip + take). So if your geocache search has over 10,000 caches in the result set, you're only able to retrieve those that fall in the first 10,000 of the result set. It's not an issue with the number of caches you try to retrieve, but with where the caches you try to retrieve fall in the result set. That is, you can retrieve caches 1 to 10,000 but you cannot retrieve caches 10,001 and greater, even if you first try to retrieve caches 10,001 to say 10,050 (skip = 10,000, take = 50).

I think that IS the case as what you write is exactly what I wrote ;)

to be clear, splitting in 2*8000 has to be done by changing the settings when getting the caches (i.e. 8000 traditionals/ 8000 non-traditionals)

 

Best practice in any case is to populate a database with placed date PQs and then updating by "published during x last days". That way all caches are in the database and can be updated any time by setting filters to split in <10000 chunks.

Share this post


Link to post

Ok.  The discussion of 10000 was confusing me. 

 

I believe GSAK is providing groups of 50 GC codes at a time and the 10000 limit on skip+take is not relevant.

 

Share this post


Link to post
On 4/6/2019 at 5:40 PM, sloth96 said:

Ok.  The discussion of 10000 was confusing me. 

 

I believe GSAK is providing groups of 50 GC codes at a time and the 10000 limit on skip+take is not relevant.

 

It may or may not be relevant but was offered as a possible explanation for what you are seeing. It would be relevant if, for example, skip is initially set to 9000, and progressed from there. In this example, 1000 caches would be retrieved and then things would end when skip reaches 10,000. Personally, I think GSAK has a bug or a macro has a bug, but what do I know?

Share this post


Link to post

This occurred again.

 

The request looked like

GET /v1.0/Geocaches?lite=false&expand=images:30,geocachelogs:30,geocachelog.images:30,trackables:30&ReferenceCodes=GC85X8P,GC85X8Z,GC85XKK,GC85XPT,GC85XT1,GC85XTY,GC85XXZ,GC85Y0E,GC85Y4G,GC85YJ3,GC85YPY,GC85YV0,GC85YWG,GC85Z19,GC85Z2Z,GC85Z8A,GC85Z9C,GC85ZAG,GC85ZF0,GC85ZFZ,GC85ZHK,GC85ZNC,GC85ZQG,GC85ZRC,GC85ZVH,GC85ZWW,GC85ZWZ,GC85ZZ8,GC85ZZT,GC8600E,GC8600V,GC8602X,GC8603M,GC86058,GC8605M,GC8606K,GC860AC,GC860B5,GC860B6,GC860BB,GC860CC,GC860D5,GC860DZ,GC860GV,GC860JJ,GC860NB,GC860QN,GC860TE,GC860TX,GC860WN&Fields=referenceCode,name,difficulty,terrain,favoritepoints,trackablecount,placeddate,publisheddate,type,size,userdata,status,location,postedcoordinates,lastvisiteddate,ownercode,owneralias,owner[membershipLevelId,findCount,hideCount,username],ispremiumonly,containshtml,shortdescription,longdescription,hints,attributes,ianaTimezoneId,relatedwebpage,additionalWaypoints,geocachelogs[referenceCode,ownerCode,imageCount,isEncoded,isArchived,loggedDate,text,type,geocacheCode,owner.membershipLevelId,owner.findCount,owner.hideCount,owner.username,geocachelogs.images.url,geocachelogs.images.referencecode,geocachelogs.images.description,geocachelogs.images.guid,usedFavoritePoint],Trackables[referenceCode,name]

 

So the skip/take issue does not appear to be in play.

Share this post


Link to post

Yet again.  Here is the balance check:

GET /v1.0/users/me/?fields=favoritePoints,geocacheLimits HTTP/1.1

Response:

{"favoritePoints":1303,"geocacheLimits":{"liteCallsRemaining":0,"liteCallsSecondsToLive":870,"fullCallsRemaining":15600,"fullCallsSecondsToLive":86248}}

 

A few seconds later the here is the request for the caches:

GET /v1.0/Geocaches?lite=false&expand=images:30,geocachelogs:30,geocachelog.images:30,trackables:30&ReferenceCodes=GC7CV8Phttps,GC7K93K,GC7KM1W,GC7KM2T,GC7KM3F,GC7KM3V,GC7T81J,GC7XMGR,GC7ZBHH,GC7ZPMH,GC80KCW,GC81KW4,GC8254B,GC84FMH,GC84V66,GC85FTR,GC85YYX,GC85YYY,GC85YZE,GC85Z3Q,GC85Z82,GC85Z98,GC85ZC3,GC85ZCK,GC85ZEN,GC85ZEY,GC85ZFV,GC85ZGG,GC85ZH4,GC85ZH7,GC85ZJD,GC85ZJZ,GC85ZKC,GC85ZKQ,GC85ZKR,GC85ZMZ,GC85ZN0,GC85ZNV,GC85ZQE,GC85ZQX,GC85ZVT,GC85ZVX,GC85ZW5,GC85ZWG,GC85ZX8,GC85ZXG,GC85ZZR,GC8600F,GC8600H,GC86013&Fields=referenceCode,name,difficulty,terrain,favoritepoints,trackablecount,placeddate,publisheddate,type,size,userdata,status,location,postedcoordinates,lastvisiteddate,ownercode,owneralias,owner[membershipLevelId,findCount,hideCount,username],ispremiumonly,containshtml,shortdescription,longdescription,hints,attributes,ianaTimezoneId,relatedwebpage,additionalWaypoints,geocachelogs[referenceCode,ownerCode,imageCount,isEncoded,isArchived,loggedDate,text,type,geocacheCode,owner.membershipLevelId,owner.findCount,owner.hideCount,owner.username,geocachelogs.images.url,geocachelogs.images.referencecode,geocachelogs.images.description,geocachelogs.images.guid,usedFavoritePoint],Trackables[referenceCode,name] HTTP/1.1

Response:

{"statusCode":403,"statusMessage":"Forbidden","errorMessage":"cannot get more than 16000 geocaches or geocache details in a day for user PR36Y2F"}

 

And another balance request afterwards returns

{"favoritePoints":1303,"geocacheLimits":{"liteCallsRemaining":0,"liteCallsSecondsToLive":503,"fullCallsRemaining":15600,"fullCallsSecondsToLive":85881}}

 

So no other app is taking the quota.

 

Looking at this it appears to be an issue with having zero lite calls causing full calls to be blocked.  The 16000 error message suggests that the system knows it is a full request.

 

 

Share this post


Link to post

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...
Sign in to follow this  
Followers 3

×
×
  • Create New...