MGKE szoftverei, új fejlesztések
Online és letölthető térképek, Windows, Android és iPhone alkalmazások

új hozzászólás | témák listája

Összesen: 2633 db hozzászólás

Lapozás: előző | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | ... | következő

Kokó hozzászólásai | válasz erre | 2019.09.13 16:20:05 (2634) Természetesen eddig is lehetett, ahogy most is. A gépemmel történt valami, mert egy másikon rendben működik. Elnézést a vaklármáért! [előzmény: (2632) Old Eye, 2019.09.13 10:14:22]

V_Gabor hozzászólásai | válasz erre | 2019.09.13 15:51:33 (2633) Nekem ott a lehetőség. Draft ládánál is. Csúnya is lenne, ha nem engedne terv közben feltölteni képet. [előzmény: (2632) Old Eye, 2019.09.13 10:14:22]

Old Eye hozzászólásai | válasz erre | 2019.09.13 10:14:22 (2632) Sose lehetett. Gondold végig! Van egy ládaötleted, foglalsz neki egy ID-et. A bejelentésig azt csinálsz vele, amit akarsz, elvetheted ötletedet, kiválthatod másssl, tudtommal (nem vagyok a gépnél) a moderátorok sem látják. Nincs időkorlát, nincs semmi kötelezettséged. Ez a tiltás nem engedi meg hogy saját fotóalbumot hozzál létre a szerveren. Abban a pillanatban, amikor bejelented, a ládaötleted fixálódik, töltheted fel hozzá a képeket, a modik látják, ha akarják. Moderálás ideje alatt biztosítani kell, az összes moderátor ugyanazt az anyagot lássa és váleményezze. Küldd el privátbsn a kérdéses kereshető ládád ID-jét, Fazéknak is. Több szem többet lát. [előzmény: (2631) Kokó, 2019.09.13 09:03:49]

Kokó hozzászólásai | válasz erre | 2019.09.13 09:03:49 (2631) Miért nem? Eddig lehetett. Egyébként kereshetőnél sem tudok választani. [előzmény: (2630) Old Eye, 2019.09.13 07:21:54]

Old Eye hozzászólásai | válasz erre | 2019.09.13 07:21:54 (2630) Bejelentés előtt és a moderálás folyamata alatt nem lehet feltölteni képet. [előzmény: (2629) Fazék, 2019.09.13 07:17:04]

Fazék hozzászólásai | válasz erre | 2019.09.13 07:17:04 (2629) Megnéztem, nekem működik. Másnak? [előzmény: (2628) Kokó, 2019.09.13 01:44:02]

Kokó hozzászólásai | válasz erre | 2019.09.13 01:44:02 (2628) Ládaoldalon a fényképfeltöltés nem működik. Nincs fájlkiválasztási lehetőség.

margabat hozzászólásai | válasz erre | 2019.09.11 18:48:06 (2627) Ilyen nálam is szokott lenni. Ha visszaváltozik zöldre a sárga mosolygós fej, akkor az aktuális láda alapadatainál ráklikkelek a frissítésre. Ezután már végleg mosolygós marad. :) [előzmény: (2625) kovigaga, 2019.09.11 13:39:43]

petrot81 hozzászólásai | válasz erre | 2019.09.11 14:48:28 (2626) Szia! Megírnád légy szíves a részleteket a profilomon lévő emailre? Utánanéznék a problémának. [előzmény: (2625) kovigaga, 2019.09.11 13:39:43]

kovigaga hozzászólásai | válasz erre | 2019.09.11 13:39:43 (2625) Kedves Fejlesztők! Használom a Geoládák alkalmazást, és nem értem egy-egy találat után a mosolygós pont miért változik vissza az eredeti ikonra? Nem minden esetben történik ez meg, de inkább visszaváltozik, mint nem. Előre is köszi

V_Gabor hozzászólásai | válasz erre | 2019.09.10 23:52:57 (2624) Öröm volt ma jelszó nélküliekkel foglalkozni! :) [előzmény: (2623) Hajo, 2019.09.10 19:19:05]

Hajo hozzászólásai | válasz erre | 2019.09.10 19:19:05 (2623) Köszönöm szépen a fejlesztéseket. Egyetértek, hogy jó az irány. Van még pár lépés ezen az úton :-) Privátban folytatom. Köszi még egyszer Hajo [előzmény: (2622) bigmick, 2019.09.10 10:25:26]

bigmick hozzászólásai | válasz erre | 2019.09.10 10:25:26 (2622) És tényleg 😃 Az irány jó, csak így tovább! [előzmény: (2620) Fazék, 2019.09.10 09:32:15]

VP hozzászólásai | válasz erre | 2019.09.10 10:11:18 (2621) Valóban! Most már egy 1600 találatos mozgó összes logja is lejön a time limit előtt. Köszönet! [előzmény: (2620) Fazék, 2019.09.10 09:32:15]

Fazék hozzászólásai | válasz erre | 2019.09.10 09:32:15 (2620) Köszönjük a noszogatásokat. Valóban sikerült kicsit optimalizálni a kódot, a korábbi válaszidőkhöz képest immár villámgyors a logok letöltése. [előzmény: (2617) Hajo, 2019.09.06 19:12:37]

V_Gabor hozzászólásai | válasz erre | 2019.09.07 12:22:54 (2619) Így érezhetően gyorsabb lett az oldal betöltése. Nekem 30 log van beállítva. Sajnos jelszó nélkülieknél néha ez is kevés. De pl. GCKEKL összes logot még mindig időtúllépés miatt csak kb. a 2012-es logokig tölti be. Ott jön a piros üzenet. [előzmény: (2616) Old Eye, 2019.09.06 17:40:21]

bigmick hozzászólásai | válasz erre | 2019.09.06 19:34:56 (2618) a nyitólap letöltése is 3 sec Ritkán szoktam a nyitólapot nézegetni, de most kipróbáltam. Ahhoz képest, hogy relatíve kevés tartalom van rajta, valóban roppant sok idő, míg összeáll. Az index.hu nyitólapja nagyságrendileg hasonló idő alatt jön be, de egy nagyságrenddel több tartalommal. Egy geoláda oldalának letöltése (20 loggal, térképpel) bő 10 másodperc. Ennek az időnek a túlnyomóan nagy része a html összeállításával és elküldésével telik, utána az egyebek (css, javascriptek, grafikus elemek) viszonylag gyorsan lejönnek (bár a méretükhöz képest ők is elég lassan). Az nginx/mariadb logokban érdemes lenne kutakodni, hátha kiderül, hol van a kritikus pont. [előzmény: (2617) Hajo, 2019.09.06 19:12:37]

Hajo hozzászólásai | válasz erre | 2019.09.06 19:12:37 (2617) Kedves Hozzászólók. Az, hogy a ládaoldalon sok log, vagy csak kevés log / fénykép stb jelenik meg és ezzel kb egyenes arányban lassabb/gyorsabb az oldal NEM a gyökér ok, hanem egy tünet. Átmeneti megoldás lehet, érdemes az infinite scroll stb megoldást alkalmazni. ..de ...a gyökér ok valami más. pl a nyitólap letöltése is 3 sec. A fórumok listája is 3 sec. Egy fórum oldal is 3 sec. Ennek mindnek 100x gyorsabban kellene generálódnia és letöltődnie. Nézzetek meg egészen komplex portalokat (hírportalok, egyebek), amelyek komplex tartalmakat generálnak, és küldenek át az éteren tizedmp alatt.

Old Eye hozzászólásai | válasz erre | 2019.09.06 17:40:21 (2616) Csak részletkérdés, nem akarom elterelni a figyelmet a fő problémáról. Teljesen közömbös, minibélyegképekről van szó vagy normál méretűkről, hasonlón összetett mappastruktúrákban kell kezelni a kétféle típusú képeket, u.a. időigény. Érdemes kipróbálni A felhasználói profillapon be lehet állítani, logonként max két bélyegkép jelenjen meg, a loglista letöltése tovább gyorsul. ('Látszódjon az összes kép' - plpa ki) [előzmény: (2615) petrot81, 2019.09.06 15:37:50]

petrot81 hozzászólásai | válasz erre | 2019.09.06 15:37:50 (2615) A képek betöltése később fut le. Persze az is eszi a hálózatot, de minimális pici bélyegképekről beszélünk. A hosszú idő a caches.geo fájl összeállítása, ami a szerveren zajlik és a generálás után kapja meg a böngésző. Ez tart baromi sokáig. [előzmény: (2614) Pongi57, 2019.09.06 12:20:23]

Pongi57 hozzászólásai | válasz erre | 2019.09.06 12:20:23 (2614) Bocs, hogy laikusként beleszólok, de a logokhoz feltöltött képeket nem lehetne gombként/linkként megjeleníteni és csak arra kattintva töltődne be csak az adott loghoz kapcsolódó kép. Én szeretek nézegetni mások által feltöltött képeket, de ez töredéke az elolvasott logokhoz képest. Volt már persze, hogy azért kattintottam egy képre, mert a "bélyegképe" valamiért felkeltette a figyelmemet és ez az általam javasolt megoldásnál "elveszne" de ez vállalható kompromisszum, ha ez által az oldalletöltés gyorsabbá válna.

petrot81 hozzászólásai | válasz erre | 2019.09.06 10:55:50 (2613) A geoládák appban kezdettől fogva ilyen infinite scroll van, valóban nagyon jól használható. Viszont mostanában az is belassult picit.. [előzmény: (2611) eFeS, 2019.09.06 08:08:34]

bigmick hozzászólásai | válasz erre | 2019.09.06 09:00:48 (2612) Ez az infinite scroll szerintem is jó ötletnek tűnik. [előzmény: (2611) eFeS, 2019.09.06 08:08:34]

eFeS hozzászólásai | válasz erre | 2019.09.06 08:08:34 (2611) Kedves Old Eye és más fejlesztők! Egyértelműen látható, hogy a logszám növelése okozza a lassulási problémát. Még a ládaoldal rendes képei is gyorsabban jelennek meg nekem, ha a profilomban csak 5db log megjelenítését állítom be. Igy minden tökéletesen használható... Szóval javasolnám ebbe az irányba az elmozdulást: csökkentsük az egyszerre megjelenő logok számát. DE: nem ebben az esetben nem jó megoldás, ami most van - szerintem - hogy vagy 5db-ot látok - vagy az összeset. Jó lenne valami köztes lépés. Mégis pár héttel csak jó visszamenni, és megnézni a láda "előéletét"... Arra gondoltam, hogy a profilban egy mondjuk 20 alatti számot lehetne megadni (legyen N). Ennyi log látszódik ALAPBÓL. És ezek után ha legörget a felhasználó a lap aljára, akkora háttérben AJAX-al frissül az oldal, és letölt újabb N darab logot, és szépen megjelenik. Ha tovább görget a user, megint N, és így tovább. Ha pedig valaki szeretné kivárni, akkor mehet az összes. Erre kész megoldások vannak, ez az "infinite scroll", szerintem nem kell bemutatnom a fejlesztőknek. De mégis pár hivatkozást iderakok, csak hogy ezt a kifejezést már ne kelljen külön beírni a Gugliba: elméleti alapok jQueryvel: https://wisdmlabs.com/blog/progressively-load-content-scroll-using-jquery/ komplett HTML/jQuery/PHP/adatbázis példa: https://makitweb.com/load-content-on-page-scroll-with-jquery-and-ajax/ kész jQuery plugin: https://infinite-scroll.com/ A dolog természetesen ezerféleképp paraméterezhető lehetne a profil oldalon, de már szerintem egy ilyen - az én meglátásom szerint egyszerű - átalakítással is rengeteget gyorsulna az ládaoldalak betöltése. Előre is köszönettel: eFeS

Gőcze László hozzászólásai | válasz erre | 2019.09.05 22:09:45 (2610) A rengeteg csatolt fotó se segít a helyzeten. [előzmény: (2608) petrot81, 2019.09.05 14:24:34]

eFeS hozzászólásai | válasz erre | 2019.09.05 21:53:24 (2609) Persze, nyilván, de alapvetően minél kevesebb a log, annál kevesebb az ilyen plusz lekérdezés is. 5db log-al szuperül fut minden! [előzmény: (2608) petrot81, 2019.09.05 14:24:34]

petrot81 hozzászólásai | válasz erre | 2019.09.05 14:24:34 (2608) Nem csak a logok száma, ott gyaníthatóan vannak kapcsolt lekérdezések, amik a logok számával exponenciálisan sokasodnak... [előzmény: (2607) eFeS, 2019.09.05 13:23:45]

eFeS hozzászólásai | válasz erre | 2019.09.05 13:23:45 (2607) Ez a megoldás!! :) Miközben VP bejegyzését olvastam, kezdtem el keresgetni a logok irányába. Hol lehet beállítani, hogy mennyi log látszódjon? A profil oldalon!! Egyből tettem is egy próbát, mivel nálam is a VP általi érték volt megadva (200), és visszavettem ezta számot 10-re....majd nekimentem a korábbi "referencia" oldalnak (https://geocaching.hu/poi.geo?id=196730) és megnyitottam innen külön tabokban a hivatkozott 6db ládát. Szerintem kb. 30 másodperc (!!) alatt megjelent az összes! Itt korábban timeout-ot kaptam az nginx-től...és volt vagy 6 PERC, mire - az értékelhető - ládaoldalak teljesen megjelentek... Tehát: a problémát a logok nagy száma jelenti a ládaoldalaknál... [előzmény: (2600) VP, 2019.09.03 23:49:00]

eFeS hozzászólásai | válasz erre | 2019.09.05 11:44:22 (2606) Ha jól látom, Hajó feszegette a kérdés - szerintem - érdemi oldalát. A szaktudást. programozói tudást, hozzá(nk)állásotokat NEM érinti ez a kérdés, mert maximálisan oda-meg vissza vagyok MINDENTŐL, ami történik a gc.hu. Láthatók a folyamatos fejlesztések, és JÓÓÓK! És minden alkalommal meglepődök, hogy "Jé, már ez is megy" [Ez volt ma a ponttól/ponthoz való tervezés lehetőségével éppen a ládaoldalon...] De ezeket - szerintem - csak a nagyon fanatikusok használják, meg mélyednek bele. Amit viszont MINDENKI lát és érez, az a sebesség...és ez gáz - megint csak szerintem -, nagyon-nagyon gáz, hogy ennyire gyatra. Itt van egy überszuper, feature-rich szolgáltatás halmaz, amiben minden benne van, ami szem-szájnak ingere [jut eszembe, nem lehetne egy API kulcsot csinálni, hogy a Google térképet is lehessen használni? De bunkó vagyok, mindig kérek valamit...], és egyszerűen alig lehet őket használni, mert lassúúúúúúúúak... Ez totál elveszi az ember kedvét mindentől... Na, de csak hogy jót is írjak: SZUPER lenne az általad vázolt, szűkített, csak a legfontosabb adatokat megjelenítő caches.geo! Azt, hogy hogy lehetne váltani, amikor egy láda lapot megnyitok, nem nagyon látom, de alapvetően valóban, csak erre lenne alapvetően szükség több tab megnyitásakor. Ezzel csak annyi bajom van, hogy alapvetően ez nem oldja meg a problémát, csak elfedi...bár kétségkívül valamilyen szintű megoldást azt ad rá... [előzmény: (2597) Old Eye, 2019.09.03 16:42:14]

Old Eye hozzászólásai | válasz erre | 2019.09.04 22:47:13 (2605) Üdv a fedélzeten! Elkerülte figyelmedet, határozottan NEM javasoljuk az új eTrex készülékekre a térképek közvetlen másolását. Csak térképtelepítőkkel megy, ehhez asztali gépre MapSource-t vagy BaseCamp-et kell felraknod. https://www.turistautak.hu/garmin.php [előzmény: (2604) Rommel112, 2019.09.04 22:16:22]

Rommel112 hozzászólásai | válasz erre | 2019.09.04 22:16:22 (2604) Sziasztok! Nem rég vettem egy Etrex22x-et, akkor ennél a tipusnál kell valamit átnevezni, variálni, vagy lehet közvetlenül rámásolni a térképet, ahogy az oldal írja? Előre is köszönöm a választ! [előzmény: (2087) tau 0470, 2018.12.31 16:21:36]

Hev hozzászólásai | válasz erre | 2019.09.04 09:50:17 (2603) Lehet, hogy tévedek, de akkor kezdődtek a lényeges lassulások amikor - főleg a turistautak.hu - részen egyes letöltési, térkép használati szolgáltatások csak akkor lettek elérhetők ha előtte bejelentkezett a felhasználó. Itt is említette valaki, hogy bejelentkezve minden lassúbb mint anélkül. Vajon miért?

petrot81 hozzászólásai | válasz erre | 2019.09.04 09:42:18 (2602) Most néztem vissza, még 2017-ben, mikor az API fejlesztés elkezdődött, kaptam Fazéktól egy SQL struktúrát (adatok nélkül), mert szóba került, hogy az appokhoz bevállalnám az API készítést. Bár elég régi, de abban pl. a cache_images táblában nincs (nem volt) index az owner és orderby mezőkön (sima images táblában pl van). A geocaches táblában nincs (nem volt) index a state és status mezőkön (csak sejtem, hogy ezek használva vannak szűrésekkor). Nem akarnék távolról beleokoskodni, meg régen használtam PHP-t és SQL-t, de érdemes lenne MyAdminban tesztelgetni a lekérdezéseket.

VP hozzászólásai | válasz erre | 2019.09.03 23:50:42 (2601) Pedig majd' éjfél, hétköznap. Nem hiszem, hogy tömegek próbálkoznak most! [előzmény: (2600) VP, 2019.09.03 23:49:00]

VP hozzászólásai | válasz erre | 2019.09.03 23:49:00 (2600) A helyzet a 3...30 s-nál is rosszabb! Most pl. nálam a GCKaKu. Újrarejtés előtt szeretnék meggyőződni, hogy amit kinéztem, ott biztos nem járt-e a láda. A leírásban van ugyan egy lista, de az néhol semmitmondó ("Budapest"), tehát jó lenne egy keresés az összes logban. Nosza! Az alap beállítás nálam a maximális 200 log. Ez már 30...40 s-ig tart, csak ezután tudok az "összes log megjelenítésé"-re kattintani. Ekkor újra kezdi előlről, nulláról, majd kb. másfél percig ketyeg, végül kiírja, hogy "A kért feladat nem fejeződött be a beállított időn belül.", és ekkor még messze nem jelent meg minden log. Tehát semennyi idő alatt se tudok letölteni egyetlen ládaoldalt az össze logjával! (Vonalas net, mindenféle hatalmas oldalak bejönnek töredék másodpercek alatt.) [előzmény: (2599) Hajo, 2019.09.03 20:49:46]

Hajo hozzászólásai | válasz erre | 2019.09.03 20:49:46 (2599) Szia OldEye. Tisztelt elnökség! Értem, hogy sok kényelmi szolgáltatás van és ez sok kis/nagy adatbázis lekérdezést futtat stb. Ezzel együtt messze nem indokolt az oldal ilyen lassú működése. Ennél SOKKAL összetettebb tartalmat szolgáltató weblapok is tized vagy éppen századmásodperces nagyságrendű idő alatt generálódnak élesben (szemben az itteni 3sec...30sec tipikus idővel), nem beszélve arról, hogy cachelhető lehetne sok szolgáltatás, ami ezredmásodpercre csökkenti a hasonló időket. A lényeg, hogy legalább benchmark szerint hasonló lapnak 10×..100× gyorsabbnak kellene lennie! Ezen nem vitatkozni kellene, hanem lépni. Megkeresni azt aki képes ez ellen tenni, van kapacitása stb. A userek számára nagyon bosszantóak a több másodperces - és mint láttuk az alábbi leírásokból több perces - laplekérési idők. Az egyesületnek gondoskodnia kellene arról, hogy a userek érdekében a helyzet erőteljesen javuljon. A jogosultsággal rendelkezőknek meg kellene nézniük a lehetséges okokat. Pl: - Mit mutatnak a szerver statisztikák? Mi kap nagy terhelést? Hol van a szűk kapacitás (adatbázis? memória? CPU? diszk? IO? valamelyik process (melyik?) stb. - Ez utalhat arra, hogy melyik területen kell a probléma gyökér okát mélyebben keresni, oda fókuszálni. - Gyakori pl, hogy az adatbázisban a lekérdezések nem jól indexeltek, illetve a lerkérdezések és az indexek nem egymáshoz optimalizáltak, esetleg sérültek. - Megjegyzendő, hogy nem egy lekérdezés/tábla lehet csupán érintett, tekintve, hogy nincs olyan oldal, ami ne lenne érintett a lassúsággal (kivéve pl a fő lap és a fórumok listája, ami bejelentkezve 3 sec, kijelentkezve azonnal letölt...) Ebből érdemes kiindulni a hiba keresésnél és ezeken az egyszerű lapokon megkeresni az okot és a megoldást. Persze máshogy is lehet. - Előfordulhat, hogy valamilyen 1..1,5 éven belüli nem jól optimalizált kód okoz nagy szerver terhelést. A lényeg: szakembernek kellene megnéznie. Nem tudom, hogy van-e erre erőforrása az egyletnek, vagy van-e erre kapacitással rendelkező jelentkező. Kérlek, hogy lépjetek ebben! Tisztelettel megköszönve a fejlesztési és fenntartási munkákat és azt, hogy itt játszhatunk! [előzmény: (2598) petrot81, 2019.09.03 17:48:30]

petrot81 hozzászólásai | válasz erre | 2019.09.03 17:48:30 (2598) Ez az automatikusan kiegészülő ládanév elég rosszul hangzik. Most minden egyes fórumoldal letöltésnél lefut egy ilyen script? Ha igen, akkor az brutális erőforrás pazarlás. Szerintem a látogatók 90%-a nem is tud róla, az az egy plusz kattintás meg igazán nem tesz semmit. [előzmény: (2597) Old Eye, 2019.09.03 16:42:14]

Old Eye hozzászólásai | válasz erre | 2019.09.03 16:42:14 (2597) Annak, hogy igen időigényes több ládaleírás egyszeri megnyitása, több oka van - egyik az adatbáziskezelő sajátsága, hadd ne menjek bele, ezen nem tudunk segíteni - másik az információbeszerzés itteni gyakorlata, ami, finoman szólva, elhibázott. Talán nem sokan tudják, a fórumok hozzászólásaiban és logbejegyzésekben automatikusan linkesedő ládanevek kiegészülnek egy apró szolgáltatással: Ha csak rávisszük a kurzort a ládanévre, egy repülő ablakban ("title") megkapjuk a legfontosabb adatait - már a ládaoldal megnyitása előtt dönthetünk, érdekel-e. Mert ha valaki megnéz valamit, általánostól a részletek felé mélyed bele, nem fordítva. Nálunk mindent a látogató elé tárjuk legtöbbször felesleges erőforrás pazarlással. Próbáltunk ezen segíteni elrejtési mechanizmusokkal, de nem sok sikerrel. Egy lehetőség, a caches. geo egy másik változata: Alapból csak a láda legfontosabb adatait adja meg, ezek pikk-pakk megjelennek, még kötegelt (több tab-os) formában is. És (új!) felsorolja a kiegészítő információk - a térkép, a ládaleírás, a loglista stb - elérhetőségét. Valahogy így: 2410. Castanea sativa (GCCS) Állapot: kereshető Szélesség: N 46° 34,298' Hosszúság: E 17° 5,693' Magasság: 151 m Megye/ország: Zala Térképen: GeoMap - TuHu - OSM - Google Maps Megjelenés időpontja: 2009.04.26 15:38 Rejtés típusa: Multi geoláda (2H) Elrejtők: waneqr Felhasználó: Old Eye +36-20-1234567 Nehézség / Terep: 3.0 / 4.0 Úthossz a kiindulóponttól: 9000 m Megtalálások száma: 162 + 1 jelszó nélküli + 6 egyéb, grafikon Megtalálások gyakorisága: 0.3 megtalálás hetente Megtalálás bejelentése Ládaleírás Loglista Moderáció Útvonaltervezés a GCCS geoládához/geoládától A láda fontosabb paramétereinek változása közelmúltban Koordináták letöltése GPS-be Koordináták letöltése alapértelmezett profillal Közeli ládák Közeli pontok Így az erőforrások igénybevétele egyben a szerver terhelése nemcsak eloszlik időben, hanem a látogató még válogathat is, csak azt kapja, amire szüksége van. Mind Strombus statisztikáiból, mind Mikulás profillapján olvasható elemzésből tudjuk, látogatóink többsége csak okostelefonon át ládázik, ezzel a megoldással, a ládaoldal csak választott részének letöltésével ők is nyernek. Nem nagy munka. A jelenlegi caches.geo természetesen megmarad, aki ragaszkodik a múlthoz, mindent egyben akar letölteni, használhatja, csak ne sírjon, azzal nem lesz a rendszer gyorsabb. Nekem az idő pénz, ami nem érdekel, nem akarom látni, csak a másik, fentebb vázolt változatot használnám. Az is biztos, nem lennék egyedül, sőt, többségben is lennénk :-) [előzmény: (2596) eFeS, 2019.09.03 09:20:25]

eFeS hozzászólásai | válasz erre | 2019.09.03 09:20:25 (2596) Szia Old Eye! Valóban! :) Értem én, miért van szükség a bejelentkezésre, semmi problémám vele. Csak azért írtam le, mert magyaráztam, hogy MIÉRT kell belépnem. Merthogy korábban "megoldásként" írták, hogy ha nem jelentkezik be az ember, akkor gyorsabb a ládaoldal letöltés. Csak hát alapvetően ez nekem semmire sem jó... Hasonló a helyzet az útvonal tervezéssel is. Szó sincs semmi "'Jó lenne ha..." kezdésről! :) Én mindent összerakok, helyesebben összeraknék kézzel, nem kell nekem az automatizmus az útvonal tervezéshez. Nem emiatt írtam. Már csak azért sem, mert sokszor nem is tudjuk, merre megyünk a kirándulásainkon. Annyi a biztos, hogy Zemplén lesz a vége, de hogy oda hogy jutunk el (Mátrát, Bükköt, esetleg a Tisza-tavat érintve), az ezeregy paramétertől függ. Mindig más úton megyünk... Nekem "csak" annyi kéne, hogyha egy lehetséges útvonalat tervezgetek a gépnél, akkor ha végigkattintom azt a pár ládát, ami útközben van, azokat véges időn belül lássam. Ha valaki csak 1-2 ládát akar megnézni, nem szenved annyira. De nekem minden ősszel előjön ez a lassulási - sőt, timeout-os! - probléma, mikor szeretnék 4-5 útvonal mentén tizenegynehány ládát végignézni. Egyszerűen nem tudok vele dolgozni, mert annyira belassul vagy kifagy. A ládákkal való munkám több, mint fele a láda oldal letöltésre való várakozással megy el... De mivel e miatt úgy mint én, alapvetően nem sírt senki itt a fórumon, gondoltam arra is, hogy az én gépemben van a hiba. De azon kívül, hogy Linuxot meg Chrome-ot használok, más "hibát" nem tudtam magamban felfedezni. Meg egyébként is: minden pöccre nyílik a gépemen, csak a geocaching.hu-s dolgokkal szenvedek. A GeoMAP helyzete lényegesen jobb, itt valóban pontosítanom kell. Ez alapvetően jó sebességű, csak néha vannak olyan periódusok, amikor ideiglenesen belassul. Szóval alapvetően nekem "csak" arra lenne szükségem, hogyha bejelentkezve megnyitok 5-6 ládaoldalt külön füleken, azok mondjuk 1 percen belül jelenjenek meg... [előzmény: (2587) Old Eye, 2019.08.30 13:14:25]

Hev hozzászólásai | válasz erre | 2019.09.01 20:58:49 (2595) Valóban ritkább, csak 1103 multi láda van most :-) [előzmény: (2594) Old Eye, 2019.09.01 18:46:17]

Old Eye hozzászólásai | válasz erre | 2019.09.01 18:46:17 (2594) Ha offline helyen vagy, ... Meggyőztél! Gyakori eset. Valóban, csak multipontok gyűjtésénél kell a játékosnak erre ügyelni. Ritkább eset. [előzmény: (2593) V_Gabor, 2019.09.01 17:27:36]

V_Gabor hozzászólásai | válasz erre | 2019.09.01 17:27:36 (2593) Van, sok is. Ha offline helyen vagy, akkor is a beállított idővel tudod elküldeni. Általában pedig beírod a jelszót a ládánál, de nem ott írod meg azt a pár sort, amit a helyszínről el szeretnél küldeni. Ekkor jól jön, hogy az idő fixen az marad, amit először beadott az app. Ha már itt vagyunk. Én annak nem látom értelmét, hogy a rendszer hagyja - akár - 1-2 évvel visszadátumozott megtaláltam logok beküldését is. De hagyjuk. Egy mobilra optimalizált oldalnak jobban örülnék. ;) [előzmény: (2592) Old Eye, 2019.09.01 10:45:02]

Old Eye hozzászólásai | válasz erre | 2019.09.01 10:45:02 (2592) Van ennek valami logikus oka? Ha leveler, mailt írunk valakinek, de az írást többször megszakítjuk, az elküldés időpontja nem egyezhet meg a levélírás kezdetének nyilván érdektelen időpontjával. [előzmény: (2590) V_Gabor, 2019.09.01 07:57:50]

karcsi9641 hozzászólásai | válasz erre | 2019.09.01 09:21:32 (2591) Köszönöm a választ, így volt. [előzmény: (2590) V_Gabor, 2019.09.01 07:57:50]

V_Gabor hozzászólásai | válasz erre | 2019.09.01 07:57:50 (2590) Az adatbázisba így került: 2019.08.31 07:37:49, azonosító: 1978950. Egy oka lehet (ha nem így volt, akkor jelezd kérlek). Megnyitottad a g:hu bejelentés oldalt, ekkor az app rögzíti az aktuális dátumot és időt. Majd 1,5 óra múlva újra beléptél, ekkor már nem ír be időpont értékeket, mert már ott az előző. Elküldted a logot és így került be az adatbázisba. Mozgó találat előtt ellenőrizd, hogy jó-e a dátum/idő! Máskor is lényeges lehet: egy több pontos multinál az első jelszórészletet beírod pl. 10-kor, majd két óra múlva megvan az utolsó pont is. Ekkor is érdemes a valódi megtalálás időpontjára átállítani. Ezt "Most!" gomba bökve tudod megtenni. Aktualizálja a dátum/idő adatot. [előzmény: (2589) karcsi9641, 2019.09.01 06:05:04]

karcsi9641 hozzászólásai | válasz erre | 2019.09.01 06:05:04 (2589) Egy érdekes dolgot tapasztaltam tegnap,kivácsi lennék. mi okozhatta. A GCSPIR ládánál logoltam az alábbi megtalálást mobiltelefonnal: "2019.08.31 05:57 - Megtaláltam - szerkesztés [g:hu 1.6.4]" De én reggel 06:00-kor indultam Sopronból, személyvonattal! A telefon a pontos időt mutatja. Van erre magyarázat?

petrot81 hozzászólásai | válasz erre | 2019.08.30 13:23:41 (2588) Bár ez node-os csomag, de nagyon jó használható pontok vagy lineStringek körüli buffer ("hurka" :)) kalkulációra, aztán a láda koordinátákat csak le kell szűrni, hogy benne vannak-e (erre is van csomagjuk) https://www.npmjs.com/package/@turf/buffer A Geoládák appba egyébként tervezek ilyet, az új bétában már van GPX nyomvonal kezelés, arra kiválóan rá lehet húzni egy ilyen funkciót. Persze más kérdés, hogy ami a térképen 50m, az lehet, hogy a valóságban egy 200 m-es szikla tetején van :D [előzmény: (2587) Old Eye, 2019.08.30 13:14:25]

Old Eye hozzászólásai | válasz erre | 2019.08.30 13:14:25 (2587) Szia eFeS! Rég beszélgettünk :-) 1. Bejelentkezés. Több oka van, hogy bejelentkezéshez kötjük a legtöbb szolgáltatást. Ebben a konkrét esetben (csak azokat a ládákat akarom látni, amiket én még nem találtam meg) tudnia kell a processznek, ki kéri a ládalistát, különben nem tudja megmondani, melyik ládát [nem] találta meg. Aztán meg, ha a látogató összetett kéréssel fordul a szerverhez, nem korlátozzuk, de mivel legtöbbször erőforrásigényes a kérés kiszolgálása, bejelentkezéshez kötjük. Régebben visszaéltek azzal, hogy láthatatlanul tölthettek le hatalmas adatmennyiségeket, öncélúan, órákon át ugyanazt, de most már szem előtt vannak. 2. Az útvonal mentén szeretném látni a lehetséges ládákat. 'Jó lenne ha...' indítás talán jobb lett volna :-) Ugyanezt az ötletet már felvetette valaki, el is kezdtem vele foglalkozni, majd félretettem, voltak fontosabb feladatok. Nemsoká előveszem. Nem nagy munka, a szükséges rutinok megvannak. Megjegyzem, az online útvonaltervezőnknek is van olyan funkciója, amely összegyűjti egy megjelölt pont körüli geoládákat és megmondja, a lekérdező melyiket [nem] találta meg. Primitívebb a GeoMap-nél, mert a multi és segédpontokat nem mutatja. Aki társasággal megy, megadhatja útitársai neveit is, ha itt regisztrálva vannak, egyből azt is megmondja melyikük melyik ládát [nem] találta meg. Tervezésre kiváló. Csak ezt a funkciót kell kiterjeszteni a megtervezett útvonal (vagy feltöltött track) melletti ládák kigyűjtésével. Szólok, ha megvan. a geomap is lassan frissül, de ez még elviselhető Kizárt. A GeoMap a szerveren dolgozik, mint az API, mint az útvonaltervező, mint a többi processz, közvetlenül hozzáfér az adatbázishoz. 3. ...7db ládaoldalt nyitottam meg. A videó hossza több, mint 7 perc... nginx-re váltás után hasonlót tapasztaltunk a Garmin térképgenerálásnál, két-háromszorosára ugrott a futási idő. Szerencsére ebben az esetben az üzemeltető szív, nem a felhasználó. [előzmény: (2584) eFeS, 2019.08.30 09:44:19]

petrot81 hozzászólásai | válasz erre | 2019.08.30 12:07:46 (2586) A caches.geo fájl (tehát az adatlap) html tartalmának lekérése a sok. Nem a böngésző darál, az csak vár. A szerveren való tartalom összeállítás a ludas. https://www.dropbox.com/s/ji66shyncncd3rj/Screenshot%202019-08-30%2012.06.10.png?dl=0 [előzmény: (2585) eFeS, 2019.08.30 11:34:25]

eFeS hozzászólásai | válasz erre | 2019.08.30 11:34:25 (2585) Megtettem a "teszt" videók megtekintését is, ezt egy másik gépről (Corei5, 8GB RAM). Itt is Linux+Chrome párossal. A Chromeban minden bővítményt kikapcsoltam, minden háttér programot lenyomtam. Közben figyeltem a terhelést is. 0.3 körüli értékről indultam, majd ez felment majdnem 2.0-ig, mire mindent megnyitott. Aztán szépen elkezdett lefelé menni a terhelés. A teljes folyamat 6 percet vett igénybe. https://www.tatrai.hu/geocaching/gchu_ladak_betoltese2-190830.mp4 [előzmény: (2580) R.Guszty, 2019.08.28 19:01:38]

Lapozás: előző | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | ... | következő

Egy lapon megjelenő sorok száma: 50 --- 10 20 50 100 200 500

új hozzászólás | témák listája