RCH65

Scheint offenbar seit dem 26. Juli so zu sein: Witzig ist, dass sich gewisse Owner (in einem anderen Thread) darüber wundern, weshalb sie plötzlich Notifications für uralte Logeinträge aus dem Jahr 2002 erhalten (für Reverse-Caches, die archiviert und "gelockt" sind).

Oha.. dann akzeptiert Groundspeak doch noch neue API Anträge? Wenn man nämlich auf die entsprechende Page geht, steht immer noch das hier: Gut zu wissen...

Changes made from version 4.90 to 5.00: Added support for optional MTP interface mode (Setup > System > Interface) Wer nicht weiss, was MTP ist: Über dieses Protokoll verbindet sich in der Regel Euer Mobiltelefon, wenn Ihr es an den USB-Port des PCs anschliesst. Unter anderem kann das angeschlossene Gerät damit normal weiterbetrieben werden und es wechselt nicht in einen "USB-only" Modus. Zudem ist das "Auswerfen" des Geräts vor dem Abziehen der Verbindung nicht mehr notwendig. Bin gespannt, ob das mit dem Oregon dann auch wirklich so funktioniert, wie das die Theorie vorgibt... ich denke, ich upgrade jetzt nicht gerade vor der morgigen Cachertour... Wer mehr wissen will: https://de.wikipedia.org/wiki/Media_Transfer_Protocol Kleiner Nachtrag: Ein Nachteil ist, dass (mindestens unter Windows 7) bei MTP kein Laufwerksbuchstabe zugewiesen wird und der Gerätespeicher nicht in das Dateisystem eingebunden wird. Der Zugriff ist in der Folge nur via Datei-Explorer möglich. Im üblichen "Speichern unter Dialog" eines Programms ist das Gerät dann nicht zu finden. Wer also GPX Dateien via Script (oder ähnlichem) auf das Navi verschiebt, sollte die Finger davon lassen und diese Option nicht aktivieren...

"...and be attainable by a reasonable number of cachers..." Na, damit entfallen wohl definitiv die Challenges, bei denen man mindestens 12 Caches in Chile, 4 in Grönland und 1 auf der ISS gefunden haben muss...

Wenn ich das richtig sehe, sind dies die Änderungen: Ein Checker bei Project.gc.com wird vorausgesetzt - dh ich muss mich vor der Publikation mit der Syntax des verwendeten LUA-Scripts auseinandersetzen und selbst einen Checker basteln (das wird die Anzahl der neuen Challenges wohl etwas reduzieren... ) Der Cache muss an den publizierten Koordinaten sein (war schon so) oder an einem sichtbaren "additional waypoint" (was auch immer der Sinn davon sein könnte...) Der Owner muss die Kriterien selbst erfüllen (war auch schon so) und dies im Listing explizit ausweisen (wurde wohl auch bereits so gehandhabt) Keine Challenges in der Form "nnn Caches in xxx Tagen" mehr... okay damit kann ich leben... Keine Challenges mehr, die sich auf TBs beziehen (auch damit kann ich leben) Keine "relativen" Challenges (mehr als 80% xxx in Region yyy) - war meiner Meinung nach ja auch bereits so (?), da dies ja auch die Suche der "anderen 20%" reduzieren könnte. Damit bleibt im Wesentlichen übrig: Ein Checker, keine zeitbegrenzten Challenges und keine TB-Challenges... Eigentlich hatte ich ja insgeheim auf einen neuen Cache-Typ gehofft (ist ja irgendwie schon etwas "gebastelt", das in den Mysteries zu platzieren)... die Angst vor all den Problemen in den GPS-Geräten und Apps scheint wohl aber zu gross gewesen zu sein...

Ja... das ist leider so. Die "simplen" Dinge wie Helm, Karabiner, Sport-Klettergurt, Reepschnur oder auch mal ein Dynamikseil haben wir in der Regel bei Bächli-Sport gekauft... sobald es aber etwas "spezieller" wird, wie Petzl Croll, Pantine, Statikseil oder einem ausgewachsenen Industrie-Klettergurt ist Ende Gelände...

Nun ja.... so wie's aussieht, wurden die BBCodes ja bei der *Ausgabe* in HTML umgesetzt und weshalb sie diese paar Codezeilen zur Umsetzung von BBC nach HTML entfernt haben, scheint wohl mit dem "Hygienebewusstsein" des Entwickler zu tun zu haben. Eine Umsetzung von BBC nach Markdown hätte also gar nicht stattfinden müssen (was wohl tatsächlich mühsam und unvollständig wäre). Dass sie die *Eingabe* von BBCode/HTML im neuen Editor nicht mehr zulassen wollen, ist sonnenklar - aber weshalb sie die Ausgabe der alten Logs so verunstaltet haben, wird mir für immer ein Rätsel bleiben (oder auch nicht - es ist ja schön, wenn Entwickler einen straffen, aktuellen Quellcode ohne Altlasten haben wollen aber dabei sollte man die Bedürfnisse der Benutzer halt nicht einfach so ignorieren...)

Mit der Änderung zur "Markdown Formatierung" kann ich ja grundsätzlich noch leben - aber die Tatsache, dass die alten Logs nun dermassen verkorkst angezeigt werden, ist schon übel. Geht Groundspeak davon aus, dass ich jetzt alle alten Logs nach den neuen Richtlinien überarbeite? Ich weiss nicht, wieviele Tausend Mal ich , oder verwendet habe... Der WYSIWYG Editor ist wohl eher WYSIWYPMG (what you see is what you probably might get) und die Smilies können auch nicht direkt eingefügt werden. Übel! (auch wenn der Weg Richtung interaktivem Editor grundsätzlich wünschenswert ist).

Dieses Verhalten wurde von Groundspeak am 23.11.15 bestätigt (siehe hier). Scheint offenbar ein unerwarteter Effekt nach dem Umbau eines APIs zu sein.

Erinnert mich irgendwie an 4-Bit CGA mit 16 Farben von 1981...

Hmmm... nicht viel neues.... Changes made from version 4.60 to 4.80:Improved address search. Fixed issue importing adventures from SD cards.

Wenn ich ein aktuelles GPX auf das Navi übertrage (welches die gefundenen Caches logischerweise nicht mehr enthält - sofern im PQ korrekt angegeben), fallen die ominösen Schatzkisten automatisch raus.

Wir setzen seit einigen Wochen ausschliesslich die PicoMaps ein (alle anderen Maps sind raus!) und sind - kurz gesagt - begeistert. Meine persönlichen Highlights: Cacherspezifische POI Auswahl (PP, Trinkwasser, Toiletten etc) - aber keine Bancomaten, Läden etc, welche die ganze Karte "zumüllen" Satte Kontraste: Höhenlinien lassen sich zweifelsfrei von schmalen Pfaden unterscheiden - auch schmalste Wassergräben sind gut erkennbar Strassen mit eingeschränkter Zufahrt (Fahrverbot, Zubringerdienst) in rot - hätte uns früher schon so manchen Umweg erspart... Für Cacher wichtige Objekte wie Zäune und Klippen sind sehr gut erkennbar. CH-Plus und CH-Bigplus Varianten mit umliegendem Grenzgebiet, sodass man nicht gleich ganz D, FR etc installieren muss, wenn man "mal schnell" etwas über die Grenze düst, So macht's wirklich Spass! :-)

Okay, nach der Diskussion also noch eine Abstimmung: Multi! Einige der obigen Antworten dünken mich etwas fragwürdig: Keinen Multi/Mystery, denn die besuche ich nicht... Die Zuweisung eines Cachestyps sollte ja nun wirklich ausschliesslich von dessen Eigenschaften abhängen und nicht von der (Marketing-)Tatsache, dass Multis und/oder Mysteries weniger besucht werden. Ansonsten wäre es ja so, dass "ganz kurze" Multis und "ganz einfache" Mysteries (selbstverständlich nach eigener Einschätzung des Owners) als Tradis deklariert würden? Wäre ja auch schön schräg... PS: Wird's dann auch noch eine Referendumsabstimmung geben, wenn das Ergebnis nicht "passt"?

Ich wurde allerdings schon ziemlich harsch angemacht, als ich in einem Log eine Redewendung benutzte, die auf einen kleinen Cache schliessen lässt. Zitat der Mail: "Bitte ändere sofort Deinen Log beim [...]. In einem Listing sollte man NICHTS verraten,- aber Du verrätst gleich Alles [...] Sonst werde ich den Log löschen, machen mich ziemlich sauer solche Logs wo Cacher immer meinen sie müssen den Nachfolgenden gleich mitteilen was sie alles raus gefunden haben." Für gewisse Owner scheint die fehlende Angabe zur Cachegrösse Teil der Herausforderung zu sein, was ich nachvollziehen kann, wenn es sich um eine atypische Form (wie zB Magnetstreifen) handelt - in allen anderen Fällen nervt es aber doch eher...

Okay... Groundspeak hat das Routing für "meinen" IP-Block geändert... und seit gestern bin ich doch tatsächlich wieder mit voller Geschwindigkeit unterwegs. Ich nehme mal an, das hat tatsächlich mit der Änderung zu tun und nicht mit der Möglichkeit, dass es jetzt zufälligerweise gerade wieder funktioniert... Sie werden die ganze Sache noch einen Moment lang beobachten und dann auch die anderen Blocks umstellen.

Okay, ich habe die Liste der IP-Blocks (von RIPE, nicht von Cablecom). Ist eine ziemlich lange Liste mit 63 (!) IP-Bereichen. Bin ja gespannt, was Groundspeak damit macht - für die Deutschen Telecom haben sie das Routing nur für die 7 grössten Blöcke geändert (und die waren wirklich gross!)

Ich habe vor ein paar Tagen eine entsprechende Note im grünen Forum hinterlegt... und zu meiner grossen Überraschung doch tatsächlich eine Antwort erhalten. Gemäss Groundspeak liegt das Problem nicht am Routing CH->Seattle, sondern in der umgekehrten Richtung Seattle->CH. Der Datenverkehr in diese Richtung ist natürlich massiv grösser, schliesslich muss ja die (unglaublich "fette") Webpage zu uns übermittelt werden. Die Tatsache, dass die Pakete auf dem Rückweg ihr eigenes Routing "suchen" und nicht (wie beim Telefon) durch denselben Draht zurückkommen, geht gerne mal vergessen... Groundspeak sagt, dass vor allen das Routing via AT&T und GTT nach Europa zu bestimmten Zeiten problematisch ist. Offenbar hatten in Deutschland zahlreiche Kunden dasselbe Problem wie wir und Groundspeak hat in der Folge das Routing zur Deutschen Telecom neu konfiguriert, um AT&T bzw GTT zu vermeiden. Hierzu wurde das Routing zu insgesamt 7 grossen IP-Blöcken der Deutschen Telecom geändert. Groundspeak hat mich nun gefragt, in welchem Adressblock wir (ich) denn so unterwegs sind und ich habe ihnen in der Folge "meinen" Adressblock der Cablecom genannt: inetnum: 178.82.0.0 - 178.83.191.255 netname: CABLECOMMAIN-NET descr: Cablecom GmbH descr: DHCP Scopes descr: Zuerich country: CH Wenn ich richtig gerechnet habe, sind darin 114'432 IP-Adressen enthalten und wenn Groundspeak tatsächlich das Routing für diesen Block ändert (hoffentlich bald!), könnten alle Kunden in diesem Block geocaching.com wieder problemlos erreichen (hoffen wir's mal...) Nun dünkt es mich jedoch, dass 114'432 Adressen etwas wenig sind, um alle Cablecom Kunden abzudecken - ich habe deshalb Cablecom kontaktiert, damit sie mir die weiteren Adressblöcke mitteilen, sodass ich das weiterleiten kann und dann hoffentlich auch Cacher in anderen Teilen der Schweiz wieder schnell unterwegs sind. Mal schauen wie's weitergeht... PS: Wer prüfen will, ob seine IP-Adresse im oben erwähnten Block liegt, kann https://www.whatismyip.com/ aufrufen - dort wird Eure (vom Provider zugewiesene) öffentliche Adresse angezeigt. Falls Eure Adresse nicht in diesem Block liegt, könnt Ihr die Adresse hier reinschreiben (oder via PM, wer's diskreter will) - ich kann dann bei RIPE (das ist die Vergabestelle für IP-Adressen in Europa) den entsprechenden Block raussuchen (Plan "B" - falls sich die Cablecom zieren sollte, die Blocks rauszugeben).

Tönt irgendwie nach Geocaching in Nordkorea. Der war vermutlich auch kein Reviewer sondern von der Parteiführung...

Habe soeben eine Antwort vom Cablecom Kundendienst erhalten: Vielen Dank für Ihre Anfrage. Wir haben bereits mehrere Fälle bezüglich geocaching.com. Ich habe auch Ihren Fall an unser Networking weitergeleitet. Es scheint aber in der Tat so zu sein, dass unser Peering Partner teilweise überlastet ist. Networking wird den Fall kontrollieren und sich anschliessend bei Ihnen melden. Vielen Dank für die beiden Traceroutes, dies vereinfacht uns die Fehlersuche. Besten Dank für Ihre wichtige Zusammenarbeit. Mal schauen, wie's weitergeht...

...oder es hat vielleicht schlicht mit der Tatsache zu tun, dass geocaching.com über gewisse Provider (zB Cablecom) seit ein paar Tagen (wieder einmal) extrem schlecht - bzw gar nicht - erreichbar ist: http://www.swissgeocacheforum.ch/forum/topic/12414-gccom-extrem-langsam/

Na, dann werde ich die Cablecom heute Abend wohl noch etwas belästigen... Da ich in der Regel mit Chrome unterwegs bin, habe ich mir extra für den Besuch auf geocaching.com in Firefox schon vor ein paar Tagen einen Proxy eingetragen (der Proxy gilt eben für alle Webpages - ausser mit einem weiteren separaten Plugin mit der gefühlten Nummer 387). Ist jetzt nicht gerade ein Wunder an Speed; funktioniert aber ganz brauchbar: -> Extras -> Einstellungen -> Erweitert -> Taste Einstellungen -> Manuelle Proxy-Konfiguration -> HTTP-Proxy: 212.82.126.32 / Port: 80 / Für alle Protokolle verwenden

Wie erwähnt, das grundsätzliche Problem scheint das Routing des Providers zu geocaching.com zu sein, denn das Problem existiert hier (natürlich abhängig vom Provider) schon weit länger als drei Tage. Da die Datenmenge der APIs im Vergleich zur extrem aufgeblasenen Wegpage geradezu lächerlich klein ist, kommen diese Daten natürlich schnell(er) mal ans Ziel. Wenn ich in meinem endlos drehenden Browser mal den bereits empfangenen HTML-Code anschaue, sehe ich jeweils, dass die ersten paar KBs längst hier sind - aber das reicht halt noch nicht, um die Wegpage anzuzeigen. Im API kannst Du damit natürlich bereits 10 Caches geloggt haben...

Falls Du Dich vom iPhone nicht via WLAN sondern via mobiles Internet verbindest, ist es natürlich gut möglich (bzw äusserst wahrscheinlich), dass der Mobilfunkprovider ein anderes Routing in die USA verwendet als Dein Internetprovider (siehe Post oben "home" vs "office").

Habe diesen Post gerade erst gesehen und unabhängig davon vor ein paar Minuten in einem einschlägigen Thread des Groundspeak Forums etwas darüber geschrieben. Es liegt definitiv nicht an geocaching.com selbst, sondern (bei mir) an Timeouts beim Peering Partner ntt.net. Wenn ich von zuhause aus auf geocaching.com zugreife (Cablecom), ist die Verbindung im Prinzip nicht benutzbar. Gemäss TRACERT ist der Engpass wohl bei "ntt.net" zu suchen (Frankfurt->NYC->Seattle). ..snip.. ae-10.r03.frnkge03.de.bb.gin.ntt.net ae-1.r21.frnkge03.de.bb.gin.ntt.net ae-3.r23.nycmny01.us.bb.gin.ntt.net Timeout Timeout ae-2.r04.sttlwa01.us.bb.gin.ntt.net ae-0.internap.sttlwa01.us.bb.gin.ntt border8.po1-40g-bbnet1.sef.pnap.net www.geocaching.com Sobald ich aber von meinem Büro auf geocaching.com zugreife (zur exakt gleichen Zeit via VPN) ist alles in bester Ordnung - anstelle von ntt.net wird dann der Atlantik aber via zayo.com überquert und wir enden auf einem anderen Gateway bei pnap.net (scheint wohl das RZ zu sein, in dem die Groundspeak Server stehen). ..snip.. xe-1-2-0.mpr1.fra4.de.above.net ae8.mpr1.fra3.de.zip.zayo.com ae4.cr1.ams5.nl.zip.zayo.com ae0.cr1.ams10.nl.zip.zayo.com v142.ae29.cr2.ord2.us.zip.zayo.com ae11.cr1.ord2.us.zip.zayo.com v11.ae29.mpr1.sea1.us.zip.zayo 208.185.125.106.ipyx-072053-008 border8.po2-40g-bbnet2.sef.pnap.net www.geocaching.com So wie's aussieht, müssten die Jungs von pnap.net wohl mal ein paar Worte mit deren Peering Partner ntt.net wechseln... Ist aber trotzdem extrem mühsam! Von meinem Laptop kann ich das Problem ja bequem via VPN umgehen - aber das gilt natürlich nicht für die anderen Geräte im Haushalt. Muss ich jetzt wirklich noch irgend ein Abo bei einem "freien" VPN-Provider lösen, der nicht via ntt.net mit der USA verbunden ist? Grmpfl...