Uvolnil jsem verzi 6.02 s opravami nahlášených chyb kolem nového API.
Stránka "Podmínky Geocaching API" ukazuje podmínky starého API
Stránka "Podmínky Geocaching API" ukazuje podmínky starého API
Jj, díííky. Už jsem na to přišel :-)
Takze zkousel jsem o vikendu stahnout pres API konkretni kesku. A nevim zda jsem mameluk, ci po zadani konkretniho GC kodu to blbne. Pritom vyhledat podle stredu mapy ok.
Ted jsem zkousel jinou [cache]gc80m0a[/cache] a opet nic. Tak jsem stahl danou oblast opet stredem mapy.
Kdyz pak tento ji dam hledat v DB, tak ji pomoci gc kodu najde. ale pres API stale ne. (filtr mam defaultne cizi/nenalezena/aktivni)
Jo a taky mi to nevytvorilo FINAL waypoint pro corrected souradnice z checkru. Kdyz zkusim aktualizovat cely listing, tak pise Aktualizovano 0; stazeno 0; limit 0
Ahoj,
dela mi to same jako Inavrat. Tlf Xiamoi MiA2 lite, android 9.
To dělá pochopitelně všem. už je připravená oprava.
Chjo :-(. Jsem myslel ze v 6.x to je ok, ale objevila se mi zas neresitelna chyba, ktera mne pronasleduje od 5.20. Kvuli tomu jsem az doted pouzival 5.18, jenze ta nema nove API …
Situace:
Prijizdim na Slovensko. Zmenim tedy databazi z Ceska na Slovensko (jsa z JmK udrzuju si vsechny okolni staty +/- aktualni v samostatnych db). Ta se sice nacte, po chvili ovsem a:drake zhavaruje. Pri jakemkoliv pokusu o nove spusteni okamzite opet zhavaruje. Nemam ani moznost cokoliv prenastavit, a pokus o rucni editaci konfiguraku mi sam znovu prepise
Jediny reseni = reinstalace :-((((
Co s tim??
HW: Android 8, Samsung A5-2017
On asi málokdo používá více databází. Já mám jednu hlavní v počítači a protože se mi nechce kopírovat 4G tak z ní na cestu udělám výřez, který má pár stovek mega. Dělin to podle států považuju za nesmysl - jsou to moresy lidí co se setkali s GSAKem.
Arne1: nevim jak jini, ja to mam takto po statech v GG uz od pocatku pouzivani v r. 2008. Hlavne kvuli objemnosti dat. GSAK jsem nikdy nepouzival. A a:drake zacal pouzivat misto Garmina prave proto, ze jsem si zamiloval tu jednoduchost - proste jsem vzdy jednou za par dni prekopiroval databaze do mobilu a mel je stale u sebe k dispozici.
Pokud bych je mel nejak spojovat a chystat i do mobilu, tak pro me a:drake ztraci odhadem 50 % funkcionality kvuli ktere jsem kompletne pred lety na nej zmenil sve work flow. A stvat me to bude o to vic, ze az do prosince 2018 to fungovalo uplne bez problemu.
To bude nějaká prkotina a věřím tomu, že příčinu Luděk záhy odhalí. Skoro všichni v a:Drake používají jednu db, tak to zatím nevyplulo na povrch. :)
Obcas pri zahranicnich cestach pouzivam vice databazi a nemam s tim popisovany problem. Naposledy asi pred mesicem jsem prepinal mezi databazemi Ceska, Holandska a Skotska - pri ceste tam a pak zpet. Bez problemu.
AD pravidelne pada pri zobrazovani map (mnohokrat hlaseny problem), ale po zmene databaze mi jeste nespadl, natoz aby trvale havaroval. Obavam se, ze bez chyboveho vypisu to Ludek nema jak odhalit, kdyz mu to nedela.
Gord: mi už mapy nepadají. Dělávaly mi to při hodně podrobném zoomu, takže jsem v konfiguraci map dal maximální zoom místo 21 pouze 20 a mám klid, běhaj jako hodinky. Když mi ten kolaps při přepnutí db začala 5.2x dělávat, tak jsem několikrát poslal výpis - přímo to nabízí a je to to jediné, co s tím jde dělat kromě té reinstalace.
Doporucuju dohodnout se primo s Ludkem, nic lepsiho asi nedame dohromady.
EDIT: Ty mapy jsem napsal trochu nestastne. Pada to po zobrazeni mapy a jejim opusteni v pripade, ze nebyla doctena sada bodu pro zobrazeni na mapu (toci se "kolecko").
Protože mám v ADrake ještě jednu databázi s archívními kešemi, zkusil jsem přepnout databázi.
Přepnutí tam a pak zpět proběhlo bez problémů, ale načtení databáze pak trvalo extrémně dlouho. Samotný program mi ovšem nespadl.
Načíst data jsem zkoušel opakovaně, dokonce jsem restartoval mobil (XPERIA Z2) a problém s extrémně dlouhou dobou načítání databáze přetrvával.
Nakonec jsem z adresáře Adrake odmazal soubory s příponou “JOURNAL” a po jednom pomalém načtení to další již proběhlo normálně.
Když cestuju, tak mám 2 databáze mezi kterými přepínám. Čechy a cizina. Taky mi to začalo havarovat stejně jako u darkMS. Samsung A3 (2017) 8.0.0 Chybové hlášky jsem už 2x poslal, tak uvidíme.
Arne1: Také mám odjakživa samostatné .db3 okolních států, co je na tom divného? Při přepínání mi to nepadá.
Myslím, že v odůvodněných případech jsou dvě databáze logické. Nemá smysl držet si nenalezené keše tam, kde jsem jednorázově a neplánuju v dohledné době tam být (dovolená, služební cesta). Přitom nevím, kolik tam budu mít času, tak si stáhnu okolí, dám do navigace a po návratu jen v HLAVNÍ databázi dám Aktualizovat nálezy. Přiznám se ale, že jsem to dělal jen ze začátku, teď všechno tahám do jedné. To jsem ale ještě neměl telefon a při exportu do Garmina se to dá vyfiltrovat. Do Adraka bych dal obě a přepínal. Tedy pokud bych to ve dvou měl. Jak je ale vidět, padá to jen někde (typ telefonu? Verze Androidu?) tak se to asi těžko nasimuluje, pokud to není nějaká chyba, kterou určité verze ignorují.
Taky kdyz nekam cestuju, delam druhou databazi. S prapinanim jsem nemel zatim zadny problem. Pristi tyden zkusim poprepinat vicekrat, jestli nedosahnu padu :)
Ono to opravdu muze byt zavisle na kde-cem. Ted resim s jednim z vas (:-)) posilani dat do AD a telefon proste nekdy nestihne to, co jindy v pohode ano. Netusim proc tomu tak je, ale nastane obcas situace, ze minutu neodpovi. Pri dalsim pokusu totez projde bez obtizi a krachne to zase na jine kesi. A ted babo rad.
Uvolnil jsem verzi 6.03 s opravami nahlášených chyb kolem nového API.- čtení podle GC kódu a zpracování corrected coordinates.