I mě to nefungovalo. Stránky padaly do chybové hlášky 500, což je v naprosté většině vyčerpání php procesů na straně hostingu. Zkrátka - přetížený server.
naprostá blbost i u toho PHPka, v naprosté většině to je chyba v PHPku, prd vyčerpání.
Publikováno 06 říjen 2016 - 20:44
I mě to nefungovalo. Stránky padaly do chybové hlášky 500, což je v naprosté většině vyčerpání php procesů na straně hostingu. Zkrátka - přetížený server.
naprostá blbost i u toho PHPka, v naprosté většině to je chyba v PHPku, prd vyčerpání.
Publikováno 06 říjen 2016 - 21:42
Mám poslední dobou pocit, že na "Website" fórum GS kašle, poslední rok se tam jejich lackeys prakticky nevyjadřují. Vážněji Groundspeak bere individuální stížnosti po e-mailu, tak kdo zvládáte, napište jim za sebe e-mail ohledně tohoto problému. Já to udělám zítra.
SW: a:Drake 6
HW: Ulefone PowerArmor 18t (Android 12), Qstarz BT-Q818XT bluetooth GPS modul
"When you go to hide a geocache, think of the reason you are bringing people to that spot. If the only reason is for the geocache, then find a better spot." – briansnat
Publikováno 06 říjen 2016 - 21:54
asi už to spravili, aspoň na profilu
Publikováno 07 říjen 2016 - 6:47
naprostá blbost i u toho PHPka, v naprosté většině to je chyba v PHPku, prd vyčerpání.
Pokud by se chyba projevila při všech načteních stránky, pak ano, měl bys pravdu. Ale v případě, kdy se chyba objeví občas, jde vždy o vyčerpání prostředků serveru (hostingu). Kdyby byla chyba v kódu, hláška se objeví vždy a všem.
Jo a asi programování dost rozumíš, tak si jistě dokážeš opravit v profilu odkaz na svůj profil na GC
Publikováno 07 říjen 2016 - 7:38
Jen poznámka na okraj: Nejedná se o PHP ale microsoftí .NET.
Publikováno 07 říjen 2016 - 13:31
Pokud by se chyba projevila při všech načteních stránky, pak ano, měl bys pravdu. Ale v případě, kdy se chyba objeví občas, jde vždy o vyčerpání prostředků serveru (hostingu). Kdyby byla chyba v kódu, hláška se objeví vždy a všem.
Jo a asi programování dost rozumíš, tak si jistě dokážeš opravit v profilu odkaz na svůj profil na GC
Není to tak, stránky se skriptama nejsou statický, stačí jedna z chyb někde okolo - např. DB, špatný prostředí (stačí i blbě zavedená sešna), ... těch chyb může být fakt hodně. Už jsme zažili i to, že na jendom PC v poho, na druhým 500, vše stejně, jen trošku jiná věc z historického hlediska. Kdyby bylo vyčerpáno, tak spíš spadne jiná chybka. Ale jako jo, může to být i tím, že padla DB nebo tak něco.
Publikováno 10 říjen 2016 - 19:48
Víc toho píšu ve vlákně o Statoru, ale i zde upozorňuji, že zeměmluví inženýři modifikují HTML kód v profilu. Tedy nejen že filtrují některé tagy, ale pustili se do jeho překopávání. Např. skrývají výstupy některých počítadel: http://www.geocachin...r-141/?p=533253
Publikováno 18 říjen 2016 - 19:37
Tak po delší době klidu opět neklikatelná mapa
Edit: ve 20:55 po 2 hodinách funkčnost obnovena
Tento příspěvek byl upraven od mirek454: 18 říjen 2016 - 19:57
Publikováno 22 říjen 2016 - 18:20
Tak jsem si dnes všimnul zajímavé věci. Keš má 6 logů a pak teprve publikační. A nezdá se mi, že by těch 6 bylo předpublikačních. Pochopitelně jsou všechny z jednoho dne, ale zdá se mi, že se jim to nějak divně řadí. Nebo měl reviewer špatně nastavené hodiny a datum se bere odtud? Spíš si myslím, že pořadí by mělo být podle toho, kdy log dorazí, pokud si uživatel nepřepíše datum na jindy. Datum nastavit lze, čas pokud vím, ne.
Publikováno 22 říjen 2016 - 18:55
Tak jsem si dnes všimnul zajímavé věci. Keš má 6 logů a pak teprve publikační. A nezdá se mi, že by těch 6 bylo předpublikačních. Pochopitelně jsou všechny z jednoho dne, ale zdá se mi, že se jim to nějak divně řadí. Nebo měl reviewer špatně nastavené hodiny a datum se bere odtud? Spíš si myslím, že pořadí by mělo být podle toho, kdy log dorazí, pokud si uživatel nepřepíše datum na jindy. Datum nastavit lze, čas pokud vím, ne.
Mělo, ale není...některé typy logů mají přednost před jinými
Publikováno 22 říjen 2016 - 19:41
Tak jsem si dnes všimnul zajímavé věci. Keš má 6 logů a pak teprve publikační...
Bohuzel tam opravdu maji nejakou chybu. Jakmile je kes nacasovana, tak jim to razeni blbne. Uz to dela cca tyden :-(
Martin > Madbin > Voyager Reviewer
Publikováno 22 říjen 2016 - 20:25
Tento příspěvek byl upraven od zvedavkanocni: 22 říjen 2016 - 20:26
Publikováno 22 říjen 2016 - 20:50
u eventů s omezenou kapacitou může být poškozený člověk, který se přihlásil před jiným, ale jeho log se zobrazí později a tak už na něj místo nezbyde
No tak pokud se nepletu, tohle by se mělo řešit podle okamžiku doručení do mailové schránky ownera a tam by to mělo být na vteřinu přesně.
Publikováno 22 říjen 2016 - 21:18
No, mě bylo divné, když v prvním logu píšou, že vyrazili, když to píplo, a teprve šestý log byl publikační, od reviewera. Hledal jsem, kdy to bylo publikováno, myslel jsem, že mi publikační log jako vždycky sežral GCLh, vypnul jsem opici, ale pořád jsem ho neviděl, až jsem pak zjistil, že je nahoře.
Publikováno 23 říjen 2016 - 0:29
Když si dočteš celý můj komentář, nenapsala jsem už v něm totéž, co ty teď? .-)No tak pokud se nepletu, tohle by se mělo řešit podle okamžiku doručení do mailové schránky ownera a tam by to mělo být na vteřinu přesně.
Publikováno 23 říjen 2016 - 8:42
Ve sporných případech určitě ano, ale na oficiálních stránkách by to mělo být v pořadí, jak to přišlo. Ale když se dá datum nastavit jiný (logicky, aby se daly logovat třeba keše nalezené o dovolené bez netu), tak to nikdy nebude zcela správně, hodina už se nastavit nedá. Hodnotit pořadí přihlášených je asi bohužel nutno dělat v mailové schránce, na webu se lze snadno zařadit dříve. Ale zrovna ty eventy, o které je zájem, bývají obsazeny během prvního dne.
Mě bylo vždycky jedno, v jakém pořadí jsou logy. Jestli můj bude před nebo za nějakým, mi je jedno, pokud sedí den. Ale FI log před publikačním jsem vždycky chápal, že někdo nalezl před publikováním. Že logoval sice po publikování, ale nastavil datum nálezu. Nebo WN, že owneři vkládají coin, aby jim to podle něj předčasně nenašli BF hledači, co sledují coiny.
Tento příspěvek byl upraven od mpik: 23 říjen 2016 - 8:47
Publikováno 23 říjen 2016 - 19:52
No tak pokud se nepletu, tohle by se mělo řešit podle okamžiku doručení do mailové schránky ownera a tam by to mělo být na vteřinu přesně.
Dovolím si parafrázi klasické věty: "Cesta mailu jsou nevyzpytatelné". Ve hře je mnoho komponent a vůbec není jisté, že první log zajistí první doručení mailu do ownerovy schránky: Web jistě běží na několika serverech. Je i dost pravděpodobné, že budou mí více mailových serverů. Potom každý mail si hledá vlastní cestu internetovou džunglí. Poslední dobou to již nebývá časté ale občas mail může běžet 10 minut i více a není to chyba.
Publikováno 23 říjen 2016 - 20:16
Tohle už kvůli rychlosti obsazování eventů řeším od srpna. Občas sedím u stroje zrovna, když začnou chodit logy. A dějou se věci.
Přihlásí se první tři a najednou se ten třetí začne posouvat nahoru a nahoru a další přihlašování se na stránce zařazují před něj, tedy dolů. Třeba deset nicků. Pak to chvíli funguje správně a další přihlášený třeba za dvě hodiny se dostane najednou na první či druhé místo, zkrátka úplně dolů. Děs, běs a hrůza.
A není to žádným zpožděním mailu, protože koukám na ten listing a pravidelně obnovuji stránku.
Dobrovolník si myslí, že ví, co je správné, a dělá to. Aktivista si myslí, že ví, co je správné, a nutí to dělat ty ostatní.
Publikováno 23 říjen 2016 - 20:23
Každou chvíli se mi stane, že se zaloguiji a můj log se objeví až za někým, kdo už byl zalogovaný dříve.
0 uživatelů, 11 návštěvníků 0 anonymních uživatelů