Have balance but cannot download caches

[+sloth96]

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.

[+on4bam]

"Some" caches (16000?)

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.

 

[+sloth96]

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

[+Corfman Clan]

20 hours ago, on4bam said:

"Some" caches (16000?)

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).

[+on4bam]

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.

[+sloth96]

GSAK now uses the new api.  It has new limits.

 

 

https://api.Groundspeak.com/documentation#restrictions

[+Corfman Clan]

4 hours ago, sloth96 said:

GSAK now uses the new api.  It has new limits.

 

 

https://api.Groundspeak.com/documentation#restrictions

Yes, and that is what is being discussed above.

[+sloth96]

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.

 

[+Corfman Clan]

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?

[+sloth96]

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.

[+sloth96]

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.