• Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.

Fehler beim Aktualisieren

arbor95

Geoguru
Ja klar gehen die. John Do hat ja selber auch 4 gpx reingezippt, die OK_* heissen und es also sind.
Mal abgesehen davon, ob Garmin das kann:
Ich bin etwas irritiert bei meinen Untersuchungen:
CW erhält ja seine Daten übers Netz und schaltet dabei den UTF-8 Konvertierer für die empfangenen Bytes ein um daraus einen String zu machen. Ob für diese Sequenz dabei wirklich etwas konvertiert wird, oder nicht, habe ich noch nicht geprüft, aber ich habe gesehen, dass in der <cache>.xml für ein so ein Smiley eine 6-Byte Sequenz gespeichert wird, z.B.:
ED A0 BD ED B8 8A . Diese 6 Bytes stehen dann auch in der gpx-Datei, die ich mir im Editor (notepad++) lade. Dann zeigt der Editor diese Bytes mit einem x davor auf schwarzem Hintergrund. Und jetzt kommt die Verwirrung: Nehme diese 6 Bytes in die Zwischablage und füge sie wieder ein, dann wird mir der Smiley angezeigt.
Speichere ich das, dann werden die 4 Bytes F0 9F 98 8A dafür gespeichert, die mir beim Einlesen wieder als Smiley angezeigt werden.
Wer kann mir da Nachhilfe geben?
 

arbor95

Geoguru
Ich nehme mal an, da trifft folgendes zu (Kopie aus Wikipedia):
Die Unicode-Bereiche U+D800 bis U+DBFF und U+DC00 bis U+DFFF sind ausdrücklich keine Zeichen, sondern dienen nur in UTF-16 zur Kodierung von Zeichen außerhalb der Basic Multilingual Plane, sie wurden früher als Low und High surrogates bezeichnet. Folglich sind Bytefolgen, die diesen Bereichen entsprechen, kein gültiges UTF-8. Zum Beispiel wird U+10400 in UTF-16 als D801,DC00 dargestellt, sollte in UTF-8 aber als F0,90,90,80 und nicht als ED,A0,81,ED,B0,80 ausgedrückt werden. Java unterstützt dies seit der Version 1.5.[6] Aufgrund der weiten Verbreitung der falschen Kodierung, insbesondere auch in Datenbanken, wurde diese Kodierung nachträglich als CESU-8 normiert.
 

JonDo

Geocacher
Moin ColleIsarco, moin arbor95
Was wären wir Cacher ohne so fleißige Programmierer die den Cachewolf immer wieder reparieren.
Hab vielen Dank. Klappt exzellent.
Mit freundlichen Grüßen
 

JonDo

Geocacher
Moin ColleIsarco und Ihr anderen fleißigen Programmierer
Nachdem der CW nun etliche Monate problemlos, dank Euch, seine Arbeit verrichtet, gibt es wieder probleme.
Vermutlich gab es wieder mal eine Veränderung bei OpenCaching
Beim Aktualisieren läuft erst alles normal, doch nach dem Fenster

OpenCache.jpg

Seitdem findet der CW kein Ende mehr. Mit andern Worten die Sanduhr läuft und Läuft....
Das könnt Ihr doch bestimmt wieder reparieren.
Mit freundlichen Grüßen
 

ColleIsarco

Geowizard
Hallo JonDo,

gib mir mal bitte die Koordinaten an, an denen du aktualisieren möchtest und ggf. weitere Parameter. Benutzt du die aktuelle Version? Wird auf der Konsole irgendetwas ausgegeben?
Ich schaue mir das mal nächste Woche an.

Schönes WE
ColleIsarco
 

JonDo

Geocacher
Moin ColleIsarco
CW Version 1.3.5498 ist die letzte Version die verfügbar ist.
Java 9.9.1 (Build 9.0.1+11) and64, läuft zum Suchen bei GC prima,
Zentrum N 53° 27.198 E 009° 42.152

Suchen1.jpg

Fängt dann an zu suchen

Suchen2.jpg

und bricht dann mit der Meldung

Suchen3.jpg

ab.
Nach dem Abbrechen - > folgt die Sanduhr

Mit N 53° 32.614 E 009° 57.774
Hat er das Problem komischerweise nicht

Jedoch das gleicht bei
N 53° 30.519 E 009° 35.124

Auch legt er Wegpunkte an (Parkplatz)
OCF103-1 N 53° 24.565 E 009° 49.204
OC12A9A-1 N 53° 34.419 E 009° 54.400
OC267A-1 N 53° 32.846 E 009° 52.424
OCF22C-1 N 53° 28.257 E 009° 58.122
OCF22C-2 N 53° 28.065 E 009° 58.135

die mit einen Achtung Schild versehen sind.
Vermutlich weil diese wohl nicht alle Daten enthalten um diese Exportieren zu können.

Vor dem Export lösche ich diese Wegpunkte.
Das ist aber auch schon früher passiert, das Wegpunkte mit einen Achtung Schild versehen sind.

Hoffentlich findest Du den Fehler und kannst Ihn beseitigen
Mit freundlichen Grüßen
 

arbor95

Geoguru
Mal nur so nebenbei: Wenn ein Wegpunkt mit OC beginnt, dann war das bisher immer ein Cache. Gilt das nicht mehr?
 

ColleIsarco

Geowizard
@arbor: Nein, das gilt nicht mehr, wenn er mit -\d+ endet. Ich bin aber an der Sache mit den Wegpunken aktuell dran, da ist nämlich noch etwas zu machen.

@JonDo: mit den Informationen kann ich etwas anfangen. Ich schaue mir das mal in kürze an. Die Addi-Wegpunkte könnten ein Problem sein, zumindest ist mir da ein Fehler unterlaufen, den ich schon bemerkt habe. Vielleicht gibt es einen Zusammenhang.

Gruß
ColleIsarco
 

ColleIsarco

Geowizard
Ups, wer kommt denn auf die Idee, einen Video-Stream einzubetten?
Da muß ich mal schauen, wie ich da verhindert bekomme, dass der heruntergeladen wird. Kann also etwas dauern.
 

jennergruhle

Geoguru
Na Videos einzubetten ist doch der hippe Sch*iß heutzutage für die Generation YouTube/TikTok. Wer will schon noch Text lesen, wenn man auch Dudel-Videos angucken kann?
Groundspeak fördert das doch auch mit dem Adventure-Labs. Da kann man nur ganz winzigen Text zur Beschreibung angeben, aber für jedes Adventure und nochmal für jede Station extra YouTube-Videos einbetten.
 

ColleIsarco

Geowizard
Na ja, in diesem Fall ist es aber einfach eine WebCam. Die liefert zwar scheinbar manchmal nur Standbilder, aber manchmal eben auch einen Video-Stream und das eben auch wenn CW versucht das "Bild" herunterzuladen.
 

jennergruhle

Geoguru
Ok, das ist bei meinem Webcam-Cache anders. Der hatte früher ein dynamisches JPG eingebettet, und alternativ einen Link zu einer externen Webseite mit Webcam-Frame. Jetzt nur noch externe Weblinks per <a>...</a>. Sowas lädt CW nicht herunter, oder?
 

ColleIsarco

Geowizard
Ich kann dich beruhigen, nur Elemente in einem <IMG->-Tag werden heruntergeladen. So wie du das hier beschreibst, macht das keine Probleme.
 

jennergruhle

Geoguru
OK, das passt. Wobei mir das mittlerweile egal ist, ich nutze ja Cachewolf schon längere Zeit nicht mehr - eigentlich seit ich das Neo FreeRunner (GTA02) nicht mehr zum Cachen nehme...
200px-Freerunner02.gif

War aber damals ein coole Kombination, vor meiner Android-Zeit. Hab damals noch extra gpsdaemon-Support in den CacheWolf eingebaut, um auf dem Neo darüber navigieren zu können. Gibt's das darin noch?
 

JonDo

Geocacher
Moin ColleIsarco
Vielen Dank für dein Engagement für den Cache Wolf, das hilft uns anderen wirklich sehr.
Das auch die CW Version 1.3.5509 noch nicht funktioniert wird Dir ja nicht neu sein, bist Du doch fleißig am Programmieren.
Beim Aufräumen in den Datensätzen habe ich eine Menge Dateien gefunden die eine komischen Dateinahmen aufweisen.
Die meisten können durch umbenennen als Bilder identifiziert werden, nur der Dateiname ist so nicht zulässig.

Anbei die Sammlung.

Anhang anzeigen Fehler-Datei.zip

In OC14332 z.B. hat der Geochecker die Adresse
http://geocheck.org/geocheck_small.php?gid=6286870081c9755-b227-4960-b685-27b2cc0ba374

Daraus macht CW vermutlich Die Datei
oc14332_geocheck_small.php_gid=6286870081c9755-b227-4960-b685-27b2cc0ba374

Da bestimmte Zeichen in einen Dateinahmen nicht zulässig sind wundert es mich gar nicht, das es hier Fehler gibt.

Mein Vorschlag wäre, wenn es denn möglich ist, den Dateinahmen aus dem Cachenamen und einen angehängten Zahl neu zu generieren. Ähnlich wir beim Export der Bilder, Doch habe ich keinen Ahnung ob da dann klappt, da ja auch in der Beschreibung die Bildernamen dann angepaßt werden müssen.

Zumindest nach dem löschen der Dateien läßt sich der CW wieder starten und der Index neu aufbauen.
Hoffentlich helfen diese Informationen weiter.
Mit freundlichen Grüßen
 

ColleIsarco

Geowizard
Eigentlich habe ich an dem Download-Problem noch gar nichts gemacht. Das das mit den Bildern im Text noch Optimierungspotential hat, ist aber auch nicht neu.

Trotzdem erst mal Danke für die Hinweise
Gruß
ColleIsarco
 
Oben