Moje problémys GG a pár návrhů, jak je vyřešit

Předem chci říct, že s GeoGetem jsem spokojen, nicméně pár připomínek k němu bych měl:

Mám PC s W7 x64, Intel CPU, 4GB RAM, systém na jednom SSD a data na druhém SSD v PCIe slotu, takže PC jako takové je vcelku svižné.

1. Docela často se mi na liště mění ikony - buď ikonu GG dostane některý další program (např. Calc z OO 3.4.1, se kterým pracuji spolu s GG, nebo IE, který zobrazuje mapy z GG či poznámkový blok apod.) nebo naopak GG dostane ikonu některého jiného programu (což je méně časté). Podobně jsou na tom i další okna otevíraná z GG a mající vlastní ikonu na liště. Je to do jisté míry drobnost, nicméně pak člověk neví, na kterou ikonu na liště kliknout nebo kam se přepnout pomocí ALT+TAB, když ty ikony nesedí.

2. Pokud pracuji s Calcem z OO a kopíruji přes schránku nějaké údaje (v Calcu si např. řeším mysterky a pak chci překopírovat souřadnice vypočtené finálky), tak se mi zase dost často stává, že se něco někde "zadrhne" a to přepnutí mezi Calc a GG a následné vložení z/do schránky trvá až 10 vteřin (minimum jsou 4 vteřiny) - ale jsou chvíle, kdy to jde zcela normálně a je to okamžitě, což je ale méně častý případ. U jiných programů než GG jsem podobný problém nezaregistroval. A mám dojem, že jsem měl problém i při kopírování mezi GG a poznámkovým blokem nebo PsPadem.
V případě, že je to jen jeden údaj, tak se to dá vydržet, ale před pár dny jsem těch bodů zadával najednou přes 40 a u každého jsem kopíroval 2 údaje, tak to bylo dost nepříjemný.

3. V posledních dnech je pro mě téměř nemožné aktualizovat kešky pomocí GC.live - při stahování plného listingu se mi velmi často objevuje chyba:

Nelze se spojit s Geocaching Live serverem!
HTTP error: 0
Socket error: 10060 Connection timed out
SSL error: 0

Pokud však stahuji "Jen základní informace", tak stahování probíhá téměř bez problémů.
Podle mě, je problém na straně GC serveru, neboť je asi přetížený a nestíhá včas odpovědět. Důsledkem toho je, že i když je omezení na 6000 kešek za den, tak se mi jich podaří zaktualizovat třeba jen cca 2800, neboť větší část požadavků sice byla serverem GC přijata (takže se započítala do limitu jako stažená), ale nestačila se odeslat a vypršela na timeoutu, takže se ve skutečnosti nestáhla do GG a GG mi nakonec nahlásí, že mám již limit 6000 kešek vyčerpán, ale zaktualizoval jen 2800 kešek. Navíc je velmi nepříjemné u toho sedět a neustále mačkat tlačítko na opakování stažení, zde bohužel chybí ono automatické odpočítávání a následné pokračování ve stahováni.
Když stahování provedu "ručně" a vyberu maximálně 20 kešek, tak tento problém vzniká již velmi ojediněle (zkusil jsem si na to udělat skript, který mi stahoval po 20-ti vybrané kešky a z těch asi 2500 kešek se mi ten timeout objevil tuším jen 2x). Podobně jako u těch "Jen základních informací" - když jsem to teď zkoušel, tak jednou jsem zaktualizoval všech 10000 možných kešek a na podruhé 9950, neboť jednou se mi tam objevil ten timeout.

Takže jako řešení vidím pokud možno zvednout ten timeout (teď je někde okolo 13 vteřin, když si změřím čas od stisknutí tlačítka na opakování stažení k objevení se další hlášky o vypršení timeoutu) např. na 20 vteřin (možná i 30, když to vezmu v poměru 20 ku 50) a hlavně plný listing nestahovat po 50-ti keškách, ale nejspíš jen po těch 20-ti, kdy mi problémy nevznikaly (pokud ten počet stahovaných kešek v jednom dotazu GG může ovlivnit). A nevím, co je za timeout v geoget.ini (sekce [gclive] CacheTimeout a CacheLiteTimeout), ale ten, když jsem zkusil změnit, tak to nemělo žádný vliv.
Případně by problém mohl být v IP adrese, kterou se mnou sdílí celá řada kladenských kačerů a GC server může požadavky omezovat i podle této IP adresy (což se už jednou projevilo u jedné mysterky, kdy webzdarma, kde byl jistý prográmek, který měl vydat souřadnice, bylo z této IP adresy téměř nedostupné, neboť někdo si napsal robota, který danou stránku bombardoval dotazy, místo aby trochu přemýšlel - tento brute force útok, by musel trvat minimálně týden, než by se k výsledku dostal a bohužel omezil ty, kteří na to šli hlavou a neměli téměř šanci se na stránky dostat a tím získat souřadnice).
Jinak co se týče vlastního připojení k internetu, tak tam určitě u mě problém není - až do bytu mi vede optika a download/upload se pohybuje mezi 10-20 Mb/s a ping do NIXu mám max 2ms zcela stabilní.

4. Kešky, které byly na GC serveru zaarchivovaný, ale v GG zůstávají jako aktivní, neboť při aktualizaci GC server vrací jen aktivní kešky. Myslím si, že po stažení všech kešek by GG mohl udělat výběr kešek z databáze o stejném poloměru jaký byl zadán při stahování z GC serveru, ale výběr by omezil datumem aktualizace, které by bylo starší než dnešní. Tím by se vybraly kešky, které se teď nezaktualizovaly, ale patří do dané kruhové oblasti a provedlo by se dodatečné stažení i pro ně.
Opět jsem si tento postup ověřil, stáhnul jsem kešky o poloměru 36.0 km od zadaného bodu (aby se to bez problémů povedlo, tak "Jen základní informace"), pak jsem si filtrem vybral kešky o poloměru 36.2 km a které nebyly dneska zaktualizovaný a pro všechny, které se mi takto objevily, jsem si nechal ručně stáhnout listing. A výsledek byl, že vše, co bylo ve vzdálenosti do 35.9 km včetně, se změnilo na zaarchivované kešky, a kešky ve vzdálenosti 36.0 km a víc už byly mimo rozsah té prvotní aktualizace a proto většinou zůstaly aktivní. Domnívám se, že by tohle GG mohl při tom stahování kešek dělat sám, aby v GG nezůstávaly zaarchivovaný kešky jako aktivní, neboť když si pak z něj člověk vyexportuje seznam kešek, tak je to včetně již nefunkčních, které pak marně hledá.
Nevím, jak přesně ta komunikace s GC.live serverem funguje, ale pokud je to tak, že nejprve se pošle dotaz s bodem a poloměrem, který vrátí seznam GC kódů kešek a pak se následně posílají dotazy s 50-ti GC kódy, ke kterým se vrátí požadované informace, tak by to šlo zařídit i tak, že tento prvotní seznam by se rovnou rozšířil i o ty kešky z databáze, které na seznamu nejsou, ale jsou v dané kruhové oblasti, takže by se to stáhlo vše najednou. A případně by se to dalo omezit i tím, že se nebudou stahovat kešky, které už dneska byly zaktualizovaný - tím by se šetřil ten limit 6000 kešek v okamžiku, když si před dovolenou chci stáhnout větší oblast a ty kruhy se mi zákonitě musí překrývat, abych získal celou oblast, kde budu, tak ten překryv by se nemusel stahovat 2x za sebou.

5. A s předchozím bodem souvisí i možnost archivace databáze, která dnes umožňuje archivovat kešky jen podle datum, kdy byly naposledy aktualizovány. Takže by bylo vhodné možnost archivace doplnit o archivovat kešky, které jsem si vybral filtrem (např. chci zaarchivovat kešky, které jsou ve stavu archive, ale které jsem nenalezl - své nálezy si chci v GG uchovat, případně podle určitého tagu, např. mám vyřešené zajímavé mysterky a ty si chci taky nechat pro další inspiraci, tak jim dám určitý TAG) - nebo v té archivaci mít možnost nějaké další volby, co se má archivovat nezávisle na tom datumu poslední aktualizace.

6. A možná změnit přednost barev písma ve výpisu kešek - modře jsou ty, které mají poznámku nebo připojené nějaké soubory a červeně jsou ty, které jsou momentálně disable a modrá má přednost před červenou, mám dojem, že by to mělo být naopak, aby disable keše byly snadno identifikovatelný - to mě většinou zajímá víc, než to, že u keše mám nějaké soubory či poznámky

A na závěr bych chtěl poznamenat, že u GeoGetu jsem si všimnul ikony Donate a tak jsem jí i využil - to jen jako inspirace pro další uživatele

1. To s tema ikonkama fakt nepozoruji, a spise to vypada na zmateny system nez na geoget. Muzes preventive zkusit smazat windowsi vyropvnavaci pamet ikon. Uloz si nasledujici rikazy do BAT davky, a tu pak spust:

taskkill /F /IM explorer.exe
cd /d %userprofile%\AppData\Local
attrib –h IconCache.db
del IconCache.db
start explorer

2. jak vypadaly ty kopirovane udaje? GG monitoruje clipboard a kdyz v clipboardu uvidi treba URL na kesku, tak ti ji v databazi nahleda. Ze by to ale takto zdrzovalo, to se mi jeste nestalo.

3. Timeout uz je zvednuty, bude v nasledujici verzi. Doposud pouzivany timeout bohate stacil na vsechno, jenze ted se jim ten server nejak zpomalil... Taha se to po padesati kesis proto, aby se omezil pocet volani toho API, protoze omezuji pocet volani za nejaky cas. proto je dobry napad vyresit co nejvice behem jednoho volani.

Kreten8 napsal/a:
...

ad 3) problém na straně serveru GS, 50 bych nechal
ad 4) jsem zásadně proti tomu, aby program sám stahoval něco, co stahovat v danou chvíli nechci - až budu chtít, dám mu k tomu pokyn sám (a umím to)
ad 5) nějak tomu nerozumím, o co vlastně má jít?
ad 6) mně barvy vyhovují, beztak tam mám "jednosměrku", akorát by v tom byl zase zmatek se přeučovat

1. to mohu skusit, ale pokud nespustím GG, tak žádné podobné věci se mi nedějí, teprve když spustím GG, tak se ty ikony začnou měnit a řekl bych že jen mezi programy, se kterými si GG komunikuje (ať už přímo, nebo přes schránku) 2. podle mě to dělá ve spojitosti s tím OpenOffice, kopírované údaje jsou text (maximálně text, který je výsledkem vzorečku) nebo souřadnice (zase třeba jako výsledek vzorečku) a je problém už jenom s přepnutím aplikace (takže v Calcu zmáčku CTRL+C, ALT+TAB, čékám těch několik vteřin a pak teprve se objeví GG a mohu data vložit) Pokud nemám spuštěné ty OO, tam si myslím, že se mi to nestalo (a pozoruji to už ten skoro rok, co GG používám)

4. tohle jsme uz trosku diskutovali soukromne. premyslim o tom, a trochu se mi to nelibi. jednak s APi se pracuje trochu jinak, a navic by tohle resilo jen jeden specificky pripad pouziti. Ono totiz v zasade jde o dve nezavisle operace - stazeni dat, a posleze aktualizace stavu toho zbytku. Problem nastava vc nejakem rozumnem urceni toho zbytku, jakemu je treba zaktualizovat stav. To se da totiz urcit vlastne jen odhadem chovani vyhledavani na GS, a to se mi nelibi. (protoze nikdy nevim, kdy to groundspeak predela...) Proto mi prijde tuto specifickou potrebu pripadne vyresit skriptem, ktery ty dve operace zasebou muze bez problemu provest.

5. utopil jsme se v terminologii: Archichovana kes v databazi stale zustava. jen ma oznaceny stav jako archived. Tento stav lze rucne editovat. Na hromadnou zmenu tohoto stavu se da napsat jednoduchy skript. Pokud slo o trvale smazani archivovanych kesi z databaze, tak osobne doporucuji to nedelat. Neni jich zase tolik, a nidky nevis, kdy se ti ta data muhou hodit, zvlast kdyz ziskani dat archivavanych kesi neni uplne snadne. Tudiz je to vlastne takovy maly poklad.

6. jenze pak zase budou smutni ti, kteri to vnimaji presne naopak. Vsechny ty stavy jsou zastoupeny symbolem ve sloupci status, existuje i vizualizacni skript, ktery ti z nich udela ikonky. Takze se to da snadno odhalit podle toho, ne? barvy v radku vnimam jako druhotne pomocne rozliseni, protoze tam nikdy nejsem schopen zachytit vsechny mozne kombinace.

1. Tento problém jsem už párkrát taky pozoroval. Ovšem nedokážu to přiřadit pouze GG. Tipoval bych to na obecný problém systému, může to být jakýkoliv program... 2. Při různých funkcích GG se mi stává, že mi GG pracuje hodně dlouho. Teď jsem zkusil jen tak dát "upravit bod" a GG pracoval asi 17 vteřin, než se objevilo okno s úpravou bodu. Zajímavé je, že při opakovaných pokusech už to běhá celkem rychle... 3. Tak toho, že to užírá počet stažení z Live.API jsem si nevšiml... Většinou tahám data z PQ-ček... Ovšem tohle je nepořádek GS... :-( A potom, že PM dostávají "kvalitní" služby :-( 4. Já osobně chci, aby archivované kešky v databázi zůstaly. Pro archivaci používám plugin Archivátor, který pouštím nad keškami, které nebyly dlouho nalezeny, ale je pravda, že díky tomu, že pracuje pomalu, je to běh na dlouhé lokte... To s tím, že by se vyfiltrovaly nejdříve keše, které se při posledním update z Live.API neaktualizovali a pak by se probrali tímto skriptem a tím by proběhla archivace by myslím bylo vyřešeno... Asi by se to dalo udělat i přes Combine, ne? Škoda, že moc nerozumím, jak se v Combine volají jednotlivé funkce... 5. Taky bych žádné kešky z databáze nemazal. Ale pokud chceš, slouží k tomu funkce "Smazat trvale". 6. Mně osobně připadá barva modrá pro poznámku, červená pro disablovanou - archivovanou docela srozumitelná. Co bys na tom chtěl měnit? Jestli myslíš, že při řazení podle stavu keše, se ti nejdříve zobrazí keše v provozu, pak keše s poznámkou, pak keše disablované, poté keše archivované, tak podle mě je to tak v pořádku, že se zobrazí disablované až za těmi s poznámkou... (i když chtělo by to, aby se zobrazovaly ty disablované kešky s poznámkou před kešemi archivovanými, a ne až za archivovanými keškami s poznámkou...

PS.: Je normální, že mi někdy projede filtr, který mi vyhledá všechny kešky krom eventů na databázi s 50 tisíci keškami za půl minuty a jindy to trvá minuty třeba 2? (v prvním případě se mění čísla u načítaných keškách po tisícovkách, v druhém po stovkách)...

1. zde je ukázka http://geoget.kreteni.eu/
první obrázek - GG nemá ikonu
druhý obrázek - GG převzal ikonu Photoshopu, který jsem si spustil na úpravu těchto prinscreenů (pro šťouraly, mám ho legálně verzi Elements, koupenou se skenerem Epson)
třetí obrázek - GG převzal ikonu z listungu kešky, kterou jsem si z něj otevřel
čtvrtý obrázek - GG má ikonu Calcu z OO, který jsem si spustil

to vše, teď během pár minut, co jsem si blíže ověřoval, jak to "divně" funguje

no a potom jsem zkusil spustit tu dávku se smazání keše ikon, tak na první spuštění měl GG správnou ikonu, ale jakmile jsem pustil OO, tak se opět změnila

No, mě se nedávno stalo, že se mi pro změnu místo obrázků statusbarů zde na fóru zobrazovaly obrázky z listingu jedny mé kešky... Tak jestli to není něco podobného :-) Čert ví, co Widle napadne ;-)

2. problém vzniká určitě, když pustím jako první GG a potom ten Calc když pak v Calcu zmáčknu CTRL+C a kliknu na ikonu GG, tak čekám několik vteřin, než se mi to na něj přepne. Když se však vrátím zpět do Calcu a pak znovu do GG, tak už to jde hned (a data jsou stále ve schránce a mohu je vložit kam potřebuji). Navíc, když si pustím PsPad a v tom Calcu stisknu to CTRL+C a pokusím se to vložit do PsPadu (do kterého se přepnu hned) tak nahlásí nějakou divnou vyjímku (program nespadne, ale hlásí aplikační chybu, že nemůže otevřít schránku a umožňuje chybové hlášení poslat autorovi) Pokud GG pustím jako poslední, tak vše probíhá normálně a i do PsPadu se dá bez problémů vkládat ze schránky (a pokud GG nemám spuštěn, tak samozřejmě taky)

3. chápu, že počet volání je omezen, ale když jsem si udělal ten skript na stahování po 20-ti, tak se mi nikdy nestalo, že by to skončilo s chybou, že je překročen počet volání (což se mi občas stává, když si nechám stahovat jen logy ke keškám) Takže pokud ten GC server má problémy, tak i to snížení počtu by tomu pomohlo a vzhledem k tomu, jak rychle to dneska probíhá, tak se na limit počtu volání nenarazí.

4. je pravda, že GC s tím dost šachuje, vloni jsem například dospěl k tomu, že se nestahuje kruh, ale čtverec. Nicméně když si vyberu stažení kešek z daného bodu o daném poloměru, tak očekávám, že se mi zaktualizují všechny kešky, které v tomto kruhu jsou a pokud se z GC něco "nedodá", tak mě ta dodatečná aktualizace přijde jako logický krok a přijde mi zbytečný si kvůli tomu pouštět ještě další skript - navíc to znamená, že to musím hlídat a až to doběhne, tak ten skript pustit, místo toho, abych to nechal pracovat a vrátil se k hotovému. A jak jsem ještě dodával, nemuselo by to stahovat dneska zaktualizovaný kešky, aby se ten limit šetřil (proč je stahovat 2x), také by se snížila zátěž toho GC serveru, když by se některé kešky nestahovaly 2x (a mohlo by tam být zatržítko, jestli to chci stahovat 2x nebo ne) opakuji jde mi o to, že kešky, které jsou na serveru GC zaarchivovaný zůstávají v GG aktivní a tedy o to, jak zajistit, aby je GG také zaktualizoval a bylo vidět, že jsou zaarchivovaný - nejde mi o jejich mazání, to ať si každý vyřeší po svém

6. Nelíbí se mi, když disablovaná keš je vidět modře, protože u ní je vložen soubor - radějich bych jí viděl červeně, stejně jako ostatní disablovaný keše a to že je u ní soubor poznal podle těch příznaků vedle. Je pro mě důležitější vidět, že teď se keš nedá lovit.

Roman_Jaromer napsal/a:
PS.: Je normální, že mi někdy projede filtr, který mi vyhledá všechny kešky krom eventů na databázi s 50 tisíci keškami za půl minuty a jindy to trvá minuty třeba 2? (v prvním případě se mění čísla u načítaných keškách po tisícovkách, v druhém po stovkách)...

V podstate je to normalni. Ta pomala rychlost je v situaci, kdy se pro pozadovana data musi sahnout do souboru na disku, tedy disk musi nekam najet hlavickama a precist neco z disku. A takhle se poletuje po souboru sem a tam. A to neni rychle. Toto chovani mozna vylepsi nejaka z dalsich verzi sqlite.

Zatimco ta velka rychlost je ve chvili, kdy ten databazovy soubor je v souborove cache operacniho systemu, takze pozadavky na cteni nemusi sahnout na disk, ale prectou data jen z pameti.

Da se to i demonstrovat treba tak, ze kdyz je to pomale, tak operaci treba v polovine vystornuj. Kdyz to cele pak spustis znova, tak ta prvni polovina pojede rychleji, protoze je uz v pameti. Ale ta druha polovina, na kterou se pred tim nesahlo, pojede zase pomalu. Nebo treba spust GGstat. A az dobehne, spust ho znova... druhe spusteni bude take vyrazne rychlejsi.

Obecne je prace s databazi nejrychlejsi po spusteni GG. Je to dano tim, ze pri spusteni se databaze bud zalohuje (tedy se cela pecte a ocitne se v te souborove cache), nebo se na pozadi spusti thread, ktery databazi na pozadi celou precte, tudiz se take dostane do te souborove cache. tedy dostane se tam jen kdyz databaze neni moc velka a zaroven je dostatek volne operacni pameti.

Kreten8 napsal/a:
2. Navíc, když si pustím PsPad a v tom Calcu stisknu to CTRL+C a pokusím se to vložit do PsPadu (do kterého se přepnu hned) tak nahlásí nějakou divnou vyjímku (program nespadne, ale hlásí aplikační chybu, že nemůže otevřít schránku a umožňuje chybové hlášení poslat autorovi)

tu chybu zarve Geoget, nebo kdo? Posli mi tu chybove hlaseni.

Kreten8 napsal/a:
3. chápu, že počet volání je omezen, ale když jsem si udělal ten skript na stahování po 20-ti, tak se mi nikdy nestalo, že by to skončilo s chybou, že je překročen počet volání (což se mi občas stává, když si nechám stahovat jen logy ke keškám)
Takže pokud ten GC server má problémy, tak i to snížení počtu by tomu pomohlo a vzhledem k tomu, jak rychle to dneska probíhá, tak se na limit počtu volání nenarazí.

Jenze normalne problemy nema, takze je zcela zbytecne ten pocet kesi snizovat, ne?