Tak jsem si chtěl vyfiltrovat kešky co mají alespoň čtyři favority a tak jsem si zadal tag favorites >=4 a zobrazilo mi to i kešku, která má jen jeden favorit. Tak nevím kde je chyba.
1 Líbí se
Mohu potvrdit stejné chování, spolehlivější je dát podmínku favorites > 3.
Ahojte,
nejak se mi historicky rozjely pocty kesek ve statistikach v geogetu => Stator verzi a geocaching.com/project-gc. No a jelikoz rozdil delal uz ne jeden kus, ale 36, tak jsem se vcera uz nastval a pustil se do reseni. Co s tim?
Loni bych nadaval a hledal v DB, seznamech porovnaval, studoval vystupy z plugin LabForGG atd.
Letos je doba uplne jinde.
Takze na GitHub - rimuln/claude-plugins: Pluginy pro Claude Code kolem geocachingu a spravy kesi v GeoGet · GitHub najdete skill, ktery jsem pro to vytvoril. Kdo ma Clauda a jeste si ho neudelal, tak treba vyuzije. Je to formou pluginu, takze instalace do Claude Code je zavolani dvou radku viz readme v repu.
1 Líbí se
Pekna prace. 
Chvili jsem tedy bojoval se spustenim (dosud jsem nic takoveho nespoustel). Vysledek me trochu udivuje, mozna proto, ze mu nerozumim:
SOUCTY GeoGet server rozdil
celkem (dtfound>0) 12874 12865 +9 <<< NESOUHLASI
z toho labky 968 967 +1 <<< NESOUHLASI
z toho nelabove 11906 11898 +8 <<< NESOUHLASI
kontrola nelabovych 11906 (vlastnich find logu v DB)
kontrola labek 967 (lab logu v LabFinds.json)
LABKY vs server (223 serii)
sparovano se serverem : 967 / 967 {‚guid‘: 722, ‚name‘: 245}
[!] log na serveru, v GG NENI oznaceno jako nalez : 0
[!] log na serveru, labka v DB vubec neni : 0
[!] v GG nalez, na serveru log neni : 1
[A] legacy duplikat (bez guid i LABid) : 0 → SMAZAT
[B] ostatni : 1 → proverit smart-link
NELABOVE
[!] [C] nalez v DB, ale zadny muj log : 0
[!] muj log, ale dtfound=0 : 0
DUPLICITNI LOG RADKY (nema vliv na pocet nalezu)
kesi s 2+ mymi find logy : 1 (prebytecnych radku 1)
VERDIKT: 1 polozek k reseni, detaily nize.
[B] LAB nalez bez logu na serveru — proverit smart-link serie
GC98RBZ 20220506 1510 gs_cacheid=8162332
Drahanský potok
adv= guid=dba62da2-ae9b-4dc2-adb8-e05c8f1de224
Kdyz kouknu na pocet nalezu na serveru a v GG, obe cisla se shoduji. Tady je rozdil 9 a neni mi jasne, co je to 12865 za cislo. A kdyz ty cisla souhlasi, jak je to s tou labkou [B]?
Kes se dvema FI logy je vporadku, alespon z meho pohledu - v te dobe to slo a tato keska mela 2 krabicky. Jedna byla bezna a druha v terenu 4+. Autor dva logy pozadoval.
Co skript našel:
1× třída [B]: GC98RBZ – Drahanský potok (nalezeno 2022-05-06) — labka odklikaná jako nalezená, ale bez logu na serveru. Podle popisu jde nejspíš o předčasně otevřený FoundIt log bez zadané odpovědi. Náprava: ověř sérii (adv guid dba62da2-…) a jen odznač příznak nálezu, záznam nemaž.
0× [A], 0× [C], žádné chybějící nálezy.
1 keš s duplicitními log řádky — na počet nálezů nemá vliv.
Zbylých +8 u nelabových keší nevysvětluje žádná nalezená třída — a Account.json (server snapshot) je z 2026-07-20, zatímco DB je aktuální k dnešku (2026-07-31). Přesně scénář, na který skill upozorňuje: starý snapshot. Doporučení — v LabForGg znovu načíst nálezy z účtu a audit spustit znovu, ať se čísla porovnají k aktuálnímu datu.
Od 20.7. jsem nemel cas nic logovat, tak to neni ani na serveru ani v GG. A labku jsem od te doby take zadnou nenasel/nelogoval. V tom problem nebude. (Znam lidi, co budou tvrdit, ze ja nemuzu mit nic normalni 
)
tak je to lazene jen na jednom pripadu, takze nemusi byt 100%
[B] je obecne pripad, kdy ta Labka je zalogovana v GG/aDrake, ale claude ji nenasel v LabsFinds.json
U me to bylo napr. co si pamatuji, ze jsem si predcasne klikl v aDrake novy log, ale pak jsem labku realne nevylustil v Advantures Lab opravdu byla jeste bez fajfky.
Claude odpoved 
:
Díky za otestování! A hlavně díky za to, že ti to nesedělo — tvůj výsledek odhalil dvě chyby ve skillu, ne u tebe. Obojí je opravené, viz konec příspěvku.
Co je to 12865
To číslo není z tvého profilu. Je to GeocacheFindCount ze souboru Account.json, který si LabForGg ukládá do Offline/ vedle LabFinds.json — a je to počítadlo, které vrací Adventure Labs API, ne hodnota načtená z profilové stránky.
Že zahrnuje i labky, je vidět na mém účtu: 5299 = 4426 nelabových + 873 lab stages, přičemž StagesCompletedCount = 873. U tebe tedy 12865 − 967 = 11898 nelabových.
A tady je ta první chyba: skill to číslo vydával za „oficiální číslo serveru". U mě se s profilem shodovalo, takže jsem to zgeneralizoval z jednoho vzorku. Tvůj případ ukazuje, že to tak obecně neplatí.
A moje druhá chyba — to doporučení obnovit Account.json
Napsal jsem ti, že je snapshot z 20.7. a ať ho obnovíš. Odpověděl jsi, že od 20.7. nic nelogoval, takže v tom problém nebude.
Jenže mtime souboru říká jen to, kdy se soubor stáhl — ne že je počítadlo uvnitř aktuální. Když zaostává na straně serveru, znovustažení ho nesrovná. Takže tvůj argument to nevyvrací, ale ani nepotvrzuje. Obnovit to má smysl jen proto, že to nic nekostuje a ubere jednu neznámou.
Čemu ve tvém výstupu věřit
Tvoje detailní kontroly jsou nulové kromě té jedné labky. To znamená, že u všech 11 906 nelabových nálezů máš v geolog svůj vlastní nálezový log. To je podstatně silnější důkaz než jedno agregované číslo — 11 906 nálezů je podložených 11 906 logy, které někdy přišly ze serveru.
Takže bych řekl, že tvoje DB je v pořádku a nepřesné je to počítadlo. Ale je to jen indicie, bez tvých dat to nedokážu.
Jak si to rozseknout sám (nic posílat nemusíš)
-
V LabForGg znovu načti nálezy a spusť audit znovu.
-
Podívej se, co udělá třída [C]:
-
[C] = 8 → to jsou keše, kde log na serveru zmizel (owner smazal, keš zamčená…) a DB je o 8 napřed. Skill je vypíše jmenovitě.
-
[C] = 0 → server ty logy pořád má, takže mimo je to počítadlo, ne databáze.
-
Kdybys to chtěl dohnat úplně, klíčové číslo je z project-gc, „našel N různých keší":
| project-gc řekne | znamená |
|---|---|
| 11 906 | počítadlo z Labs API je mimo, DB je správně |
| 11 898 | DB má 8 nálezů, které server nepočítá — hledáme je |
Ta keš se dvěma FI logy — máš pravdu, chyba byla u mě
Skill tvrdil, že duplicitní řádek je „tentýž log 2×". U mě to platilo (měl jsem 67 dvojic a všechny měly rozdíl gs_logid přesně 411 120, což je systematický jev — ukázalo se, že u mě jde o zástupné logy typu „Později", ke kterým pak dopíšu plný text, a v DB zůstane obojí).
Ale to je popis mého případu, ne definice. Tvoje keš s dvěma krabičkami, kde owner dva logy vyžadoval, je legitimní dvojlog a mazat se nemá. Skill má teď sekci, jak to rozlišit:
-
dva různé plné texty popisující dvě krabičky → v pořádku, nechat
-
jeden plný a jeden dvouslovný → zástupný, ten navíc
-
desítky dvojic se stejným rozdílem
gs_logid→ systematický jev, ne desítky legitimních dvojlogů
K té labce GC98RBZ
Třída [B] je obecně případ, kdy je labka zalogovaná v GG/aDrake, ale není v LabFinds.json. Příčiny znám dvě:
-
předčasně otevřený FoundIt log — u mě to tak bylo, klikl jsem nový log v aDrake, ale labku jsem reálně nevyluštil a v Adventure Lab zůstala bez fajfky
-
přeobsazený slot v sérii — owner labku v sérii vymění, GeoGet slot přepíše novou labkou a příznak nálezu na něm zůstane po té staré. Jméno, které pak u záznamu vidíš, s tím nálezem nesouvisí.
Náprava je v obou případech stejná: ověřit na smart-linku série, jestli tam ta labka je, a pak jen vynulovat příznak nálezu — záznam nemazat. Je to živá neodlovená labka a chceš ji dál vidět v seznamu k odlovu.
Aktualizace pluginu na v1.1.0
Opravy jsou venku. Postup jsem si ověřil, funguje:
claude plugin marketplace update rimuln-plugins
claude plugin update geoget-audit@rimuln-plugins
Výpis má skončit Plugin "geoget-audit" updated from 1.0.0 to 1.1.0. Pak restartuj Claude Code, jinak se pořád použije stará verze (updater na to sám upozorní). V sezení to jde i přes menu /plugin.
Ověření, že jsi na nové verzi: v hlavičce výstupu je teď sloupec pojmenovaný LabsAPI místo server, s poznámkou, že je orientační:
SOUCTY GeoGet LabsAPI rozdil (LabsAPI = Account.json, orientacni)
A když se rozchází jen souhrnné číslo a detailní kontroly jsou nulové, verdikt už netvrdí „téměř jistě starý snapshot", ale napíše, že přednost mají detailní kontroly, a nabídne přesně ten test s reimportem MyFinds.
Dekuju za analzyu a opravu. Na me strane byla chyba taky - Drahansky potok byla tradicka, ne labka. Proto nemohla byt mezi labkami nalezena. Proc se mi to zmenilo na labku a kdy, to nevim, ale muj kontrolni plugin uz mi to ted taky nasel jako chybu. Vratil jsem to v databazi zpet na TR3B (i kdyz ted je na serveru TS3B, ale ja mam u kazde kese poznacen stav, v jakem jsem ji nalezl a mohu to vratit).
Vysledek po oprave mych data a spusteni nove verze:
Audit dopadl čistě, žádné podrobné seznamy nebylo potřeba zobrazit (vše nulové). Po oprave vystup z neve verze:
Výsledek kontroly (uživatel gordici, 2026-08-02):
┌─────────────────┬────────┬───────────────────┬────────┐
│ položka │ GeoGet │ server (Labs API) │ rozdíl │
├─────────────────┼────────┼───────────────────┼────────┤
│ celkem nálezů │ 12 880 │ 12 880 │ 0 │
├─────────────────┼────────┼───────────────────┼────────┤
│ z toho labky │ 967 │ 967 │ 0 │
├─────────────────┼────────┼───────────────────┼────────┤
│ z toho nelabové │ 11 913 │ 11 913 │ 0 │
└─────────────────┴────────┴───────────────────┴────────┘
Labky: 967/967 spárováno se serverem (722 přes guid, 245 přes jméno v sérii). Žádné třídy [A] ani [B].
Nelabové: žádná keš třídy [C] (nález bez vlastního logu) ani obráceně.
Duplicitní log řádky: 1 keš má 2 vlastní nálezové logy navíc (na počet nálezů to nemá vliv — jde jen o statistiky logů). Vzhledem k tomu, že jde o ojedinělý případ (ne systematický vzorec), pravděpodobně legitimní dvojlog nebo zástupný+plný log — nejde o chybu importu.
Verdikt: DB je plně konzistentní se serverem, nic není potřeba opravovat ani přeimportovat.
Nova verze pluginu mi vytvorila vystupni soubor hluboko v AppData (C:\Users\...\Temp\claude\e–Geocaching-GeoGet\05b891ad-afdd-4147-9931-e99850aee1cf\scratchpad\audit_out.txt). Spatne se to hleda. Predchozi verze mi ulozila soubor audit_nalezu.txt do DATADIRU. To mi pripada mnohem lepsi.
V kazdem pripade dekuji za nastroj a rychlou opravu. I kdyz to asi nebude nastroj pro kazdeho…
no něco jsem zkoušel, a asi to bude chtít ještě víc prozkoumat. Nemám složku c:\adrake ani GeoGet v AppData, takže jsem to musel trochu přemlouvat. Nakonec s využitím všech parametrů mám nějaký výsledek.
SOUCTY GeoGet LabsAPI rozdil (LabsAPI = Account.json, orientacni)
celkem (dtfound>0) 4780 4776 +4 <<< NESOUHLASI
z toho labky 293 289 +4 <<< NESOUHLASI
z toho nelabove 4487 4487 +0
kontrola nelabovych 4486 (vlastnich find logu v DB)
kontrola labek 289 (lab logu v LabFinds.json)
LABKY vs server (60 serii)
sparovano se serverem : 289 / 289 {'guid': 220, 'name': 69}
[!] log na serveru, v GG NENI oznaceno jako nalez : 0
[!] log na serveru, labka v DB vubec neni : 0
[!] v GG nalez, na serveru log neni : 4
[A] legacy duplikat (bez guid i LABid) : 0 -> SMAZAT
[B] ostatni : 4 -> proverit smart-link
NELABOVE
[!] [C] nalez v DB, ale zadny muj log : 1
[!] muj log, ale dtfound=0 : 0
DUPLICITNI LOG RADKY (nema vliv na pocet nalezu)
kesi s 2+ mymi find logy : 0 (prebytecnych radku 0)
VERDIKT: 5 polozek k reseni, detaily nize.
------------------------------------------------------------------------------
[B] LAB nalez bez logu na serveru — proverit smart-link serie
------------------------------------------------------------------------------
GC7B1WC-A0 20180331 1111 gs_cacheid=63830380000
Museum of Geocaching / Traditional Geocache
adv=9cf259b9-76da-46e2-9290-80513552eefc guid=9cf259b9-76da-46e2-9290-80513552eefc
GC7B1WC-A1 20180331 1112 gs_cacheid=63830380001
Museum of Geocaching / Multi geocache
adv=9cf259b9-76da-46e2-9290-80513552eefc guid=9cf259b9-76da-46e2-9290-80513552eefc
GC7B1WC-A2 20180331 1113 gs_cacheid=63830380002
Museum of Geocaching / Letterbox hybrid
adv=9cf259b9-76da-46e2-9290-80513552eefc guid=9cf259b9-76da-46e2-9290-80513552eefc
GC7B1WC-A3 20180331 1110 gs_cacheid=63830380003
Museum of Geocaching / Earth geocache
adv=9cf259b9-76da-46e2-9290-80513552eefc guid=9cf259b9-76da-46e2-9290-80513552eefc
------------------------------------------------------------------------------
[C] Nalez v DB, ale zadny muj log — pravdepodobne NENAHRANY log na gc.com
------------------------------------------------------------------------------
GC8NP3W Community Celebration Event nalez 20221203 1740 posledni log na serveru 20221203
Tady koulel sudy Ferdinand Vaněk
S těma labkama Muzeum Geocachingu nevím co je blbě - když jsem neměl označené nálezy v GG tak to taky pindalo, tak jsem to napravil a teď zas prý nemám log na serveru. Ale ony jsou všechny archivovaný, tak už to asi nedoplním.
No a u Vaňka jsem mělo log “Unknown” což by měl být “Will Attend” a i když jsem dotáhnul log “Attended”, tak se mu to nezdá. On je to ale divný typ keše.
DecodeDate(Date, Year, Month, Day);
mesic:=‚0‘+IntToStr(Month);
datum:=IntToStr(Year)+Copy(mesic, Length(mesic)-1, 2);
ShowMessage(datum);
GEOGET_DB.GetTableStrings(‚SELECT SUBSTR(dthidden, -4) FROM geocache WHERE SUBSTR(dtfound, 1, 6) = „‘+datum+‚“‘, nalezy);
ShowMessage(IntToStr(nalezy.Count));
for i:=0 to nalezy.Count-1 do ShowMessage(nalezy[i]);
Dokáže mi někdo poradit, kde mám chybu ve visualizačním skriptu, kde první ShowMessage mi zobrazí správně 202608, neboť chci všechny nálezy z aktuálního měsíce, když si pustím ručně následující dotaz SELECT SUBSTR(dthidden, -4) FROM geocache WHERE SUBSTR(dtfound, 1, 6) =”202608”, tak mi správně vrátí sedm nálezů, ale v tom visualisačním skriptu se už neprovede, neboť další ShowMessage se mi už nezobrazí.
Tak ono s Claudem a AI agenty je to nekdy slozite. Skill je takovy predpis. hodne se pak ovlivnuje samotnym promptem a contextem. A casto staci nejaky update anthropicu a chova se to uplne jinak. Ale uzasne je, ze staci mu rict, ze chces neco jinak a on se prizpusobi. ten c:\adrake je historicky kdy jsem prestal kopirovat primo pres MTP z geogetu, ale nejdriv to kopnu tam a nasledne rucne v TC do telefonu na spravne misto. Vypada, ze v poslednich verzich W11 a A16 na S25 uz nemusim na 2x. tj. v 1. kole smazat db v telefonu a v 2. kole po odpojeni a opetovnem pripojeni to tam kopnout. uz to da ten replace najednou.
Ale kdyz se mu rekne pouzij tento skill DB je tam a tam a vystup uloz sem, tak on si to proste do tech parametru posle.
-
jinak scratchpad je jeho pracovni temp oblast, kde si on v klidu dela co potrebuje. pokud chces vysledek nekde, tak je mu to casto explicitne rict.
Tak teď jsem si tu část kódu zkusil pustit jako normální plugin a dostal jsem následující error. Tak tomu teď vůbec nerozumím.
