Eigene Funde spidern

[MKW]

Mit StatWolf hat greiol für mich endlich den Anlaß geschaffen, meine knapp 5000 Funde zu spidern. Denn ich bin kein PM und wenn des Spidern der eigene Funde voll umfänglich funktioniert, fällt noch ein Argument weg, eines zu werden.

Hier mein erster Erfahrungsbericht:
Ich benutze die Java-Version 1.0.1783 auf einem Mac.
Die ersten 1500 Caches waren in 200-300er Schritten schnell und fast problemlos(s.u.) zu laden.
Ab ca. 1500 Caches in der Datei mußte ich die Anzahl der zu ladenden Caches auf 150 beschränken, ab 2000 auf 100.
Über ca. 2400 komme ich nicht hinaus.
Zwar kann ich von Hand erstellte loc-Datein laden und aktualisieren, aber dann fehlen die archivierten Caches.

Was sich als störend erweist, sind zwei "Funktionen".
Zum einen das schon angesprochene Laden der TB-Informationen. Zum anderen werden alle bereits in der Datei befindlichen Caches aktualisiert. Entweder bleibt der Spider wegen Speicherproblemen schon beim Aktualisieren dieser jüngeren Caches hängen bevor zum Laden der älteren kommt. Oder, falls man das Aktualisieren ablehnt, passiert nichts mehr.

Ich dachte, der Menu-Punkt "Eigene Funde laden" dient dazu, für non-PMs eine Möglichkeit zu schaffen, um sich mit den gängigen Tools oder dem StatWolf Statistiken zu erstellen. Dafür ist es nicht notwendig, jedes Mal alle bereits vorhandenen Caches inkl. der TB-Informationen zu aktualisieren.
Vielleicht nützt eine kleine Änderung der Routine: der User entscheidet sich vor dem Spidern, ob die jüngeren Caches aktualisiert oder TB-Infos geladen werden sollen, so wie es jetzt schon für Bilder der Fall ist.
Außerdem wäre es gut, wenn man neben der maximalen Anzahl ein "bis"-Datum als Grenze eingeben könnte. So kann man seine letzten Funde nachtragen ohne daß der Spider bis zur letzten Seite durchläuft.

Für non-PM gibt es ein weiteres, für den CW leider unlösbares Problem. Es sind Caches, die seit dem eigenen Fund zu PM-Caches geworden sind. Hier kann der Spider nicht auf die Detailinformationen zugreifen.
Hier hilft es zur Zeit nur, diese Caches mit Hilfe der log.txt zu erkennen und diese Caches von Hand einzupflegen. Dabei merkt man schmerzlich, daß es keine Möglichkeit gibt, den D- und den T-Wert eines Caches zu erfassen.

Ich würde mich freuen, wenn diese Haken beseitigt würden.

 

[greiol]

Ich benutze die Java-Version 1.0.1783 auf einem Mac.
Die ersten 1500 Caches waren in 200-300er Schritten schnell und fast problemlos(s.u.) zu laden.
Ab ca. 1500 Caches in der Datei mußte ich die Anzahl der zu ladenden Caches auf 150 beschränken, ab 2000 auf 100.
Über ca. 2400 komme ich nicht hinaus.

hast du schon versucht der jvm mehr speicher zuzuweisen?
dazu müsst du cachewolf allerdings auf einer commandozeile starten. der aufrufsieht dann so aus:

java -Xms=512m -Xmx=512m jar CacheWolf.jar

das würde der jvm ein halbes GB zuweisen. den wert kannst du auch höher setzen (kommt auf die speichermenge an die du hast). über 2048 würde ich allerdings nicht gehen. das speicherproblem an sich wurde zwar schon erkannt, eine lösung liegt jedoch noch nicht vor.

Zum einen das schon angesprochene Laden der TB-Informationen.

ja, hier müssen wir uns noch einig werden wo wir das nun ausknipsen

Außerdem wäre es gut, wenn man neben der maximalen Anzahl ein "bis"-Datum als Grenze eingeben könnte. So kann man seine letzten Funde nachtragen ohne daß der Spider bis zur letzten Seite durchläuft.

das müsste jemand bewerten der den spider vernünftig kennt.

Für non-PM gibt es ein weiteres, für den CW leider unlösbares Problem. Es sind Caches, die seit dem eigenen Fund zu PM-Caches geworden sind. Hier kann der Spider nicht auf die Detailinformationen zugreifen.

daran können wir leider auch nichts ändern, daten die nicht angezeigt werden fehlen leider später.

Hier hilft es zur Zeit nur, diese Caches mit Hilfe der log.txt zu erkennen und diese Caches von Hand einzupflegen. Dabei merkt man schmerzlich, daß es keine Möglichkeit gibt, den D- und den T-Wert eines Caches zu erfassen.

in einer alten version betünde die möglichkeit das mit einem texteditor in der index.xml nachzutragen (ok, ist nicht wirklich angenehm). mit dem neuen binären format wird das aber deutlich schwieriger.
meinungen von DEV?

ich finde es interessant zu sehen wie CW reagiert wenn er mal einem stresstest unterzogen wird. danke für den erfahrungsbericht.

 

[MiK]

Zum anderen werden alle bereits in der Datei befindlichen Caches aktualisiert. Entweder bleibt der Spider wegen Speicherproblemen schon beim Aktualisieren dieser jüngeren Caches hängen bevor zum Laden der älteren kommt. Oder, falls man das Aktualisieren ablehnt, passiert nichts mehr.

Das kann ich mir im Moment nicht vorstellen. Zum einen werden vorhandene Caches nur aktualisiert, wenn sich etwas ändert und man diese Funktion ausgewählt hat (entweder in den Einstellungen oder durch Bestätigen des Dialogs. Zum anderen werden die Aktualisierungen immer erst nach dem Laden der neuen Caches durchgeführt. Wenn das bei Dir wirklich so ist, läuft da bei Dir irgendetwas schief. Kannst Du mal das Log eines solchen Vorgangs posten? Am besten mit einer nicht zu großen Menge an Caches.

Außerdem wäre es gut, wenn man neben der maximalen Anzahl ein "bis"-Datum als Grenze eingeben könnte. So kann man seine letzten Funde nachtragen ohne daß der Spider bis zur letzten Seite durchläuft.

Die Liste, die CW durchläuft beginnt mit den neuesten Caches. Wenn man also 10 angibt, dann werden die neuesten 10 noch nicht geladenen Caches geladen. Ist das bei Dir nicht so? Wie ich bei GC eine Anfrage mit Datumsgrenzen machen soll, weiß ich nicht. Ich kann immer nur die Liste beginnend mit den neuesten von Anfang an durchgehen.

 

[MKW]

hast du schon versucht der jvm mehr speicher zuzuweisen?
dazu müsst du cachewolf allerdings auf einer commandozeile starten. der aufrufsieht dann so aus:

java -Xms=512m -Xmx=512m jar CacheWolf.jar

Leider gibt das diese Fehlermeldung:

Invalid initial heap size: -Xms=512m
Could not create the Java virtual machine.

Was tun?

 

[MKW]

Das kann ich mir im Moment nicht vorstellen. Zum einen werden vorhandene Caches nur aktualisiert, wenn sich etwas ändert und man diese Funktion ausgewählt hat (entweder in den Einstellungen oder durch Bestätigen des Dialogs. Zum anderen werden die Aktualisierungen immer erst nach dem Laden der neuen Caches durchgeführt. Wenn das bei Dir wirklich so ist, läuft da bei Dir irgendetwas schief. Kannst Du mal das Log eines solchen Vorgangs posten? Am besten mit einer nicht zu großen Menge an Caches.

Anbei ein Log.txt.
Er ist so entstanden:
"Spider alle Funde von geocaching.com" - Anzahl 10 - keine Bilder
"3 neue Caches gefunden" In Wirklichkeit müßten es mehr sein. Von meinen 4800 Founds sind bis jetzt 2450 in der DB. Bei den 3 gefundenen handelt es sich um PM-Caches, die ich noch nicht von Hand eingepfegt habe (s.o.)
"157 Cachebeschreibungen müssen aktualisiert werden" - Ja! In der Hoffnung, daß, wenn mal alle Caches aktualisiert sind, auch wieder weitere "alte" Caches geladen werden.
Bei Cache Nr. 105 hat sich der Spider aufgehängt.

Die Liste, die CW durchläuft beginnt mit den neuesten Caches. Wenn man also 10 angibt, dann werden die neuesten 10 noch nicht geladenen Caches geladen. Ist das bei Dir nicht so? Wie ich bei GC eine Anfrage mit Datumsgrenzen machen soll, weiß ich nicht. Ich kann immer nur die Liste beginnend mit den neuesten von Anfang an durchgehen.

Diese Liste ist nach dem Funddatum sortiert. Dann müßte man doch abbrechen können, wenn das eingegebene Datum erreicht ist.

 

[MiK]

Anbei ein Log.txt.
Er ist so entstanden:
"Spider alle Funde von geocaching.com" - Anzahl 10 - keine Bilder
"3 neue Caches gefunden" In Wirklichkeit müßten es mehr sein. Von meinen 4800 Founds sind bis jetzt 2450 in der DB. Bei den 3 gefundenen handelt es sich um PM-Caches, die ich noch nicht von Hand eingepfegt habe (s.o.)
"157 Cachebeschreibungen müssen aktualisiert werden" - Ja! In der Hoffnung, daß, wenn mal alle Caches aktualisiert sind, auch wieder weitere "alte" Caches geladen werden.
Bei Cache Nr. 105 hat sich der Spider aufgehängt.

Es ist bekannt, das speziell die Java-Version ein Problem beim Spider vieler Caches hat. Spätestens um die 100 ist wegen Speicherproblemen Schluss. Schalte doch einfach das Aktualisieren mal in den Preferences ganz ab (oder klicke auf "nein"). Das hat direkt mit Deinem Problem erst einmal nichts zu tun. Vielleicht kannst Du auch mal die 3 PM Caches noch einfügen. Dann würde mich einmal interessieren, wie weit Du kommst und ob nach einer bestimmten Zahl Caches im Profil nichts mehr kommt. Es scheint mir ein bisschen so, als würden nicht alle Seiten der Liste durchlaufen.

Diese Liste ist nach dem Funddatum sortiert. Dann müßte man doch abbrechen können, wenn das eingegebene Datum erreicht ist.

Sowas könnte man irgendwie einbauen. Dann müsste man aber einiges ändern und könnte nicht größtenteils existierenden Code verwenden. Für was sollte diese Beschränkung gut sein?

 

[MiK]

Hab mal noch ein bisschen Dein Log analysiert: Anscheinend werden nicht alle Seiten Deiner Liste durchlaufen, sondern irgendwann abgebrochen. Der Grund dafür ist mir aber noch nicht klar. Seltsamerweise entspricht die Reihenfolge der Caches im Log nicht der Reihenfolge, wie ich sie angezeigt bekomme (innerhalb eines Tages). Irgendwann am 27.7.07, an dem Du anscheinend einiges gefunden hast, bricht das ganze dann auch ab.

Ich möchte jetzt nicht alles laden, um das nachvollziehen zu können. Vielleicht kannst Du mal das Profil packen und mir schicken (E-Mail-Adresse per PN).

Edit: Die 157 zu aktualisierenden Caches kommen übrigens hauptsächlich (bis auf 3) daher, dass sie in der DB sind, aber beim Spidern nicht wieder auftauchen. Um diesen Widerspruch aufzuheben, werden sie zum Aktualisieren vorgeschlagen. Die Logik ist also eher umgedreht, als Deine Vorgehensweise: Erst muss das vollständige Laden funktionieren: Dann funktioniert auf die Aktualisierungslogik.

 

[greiol]

Leider gibt das diese Fehlermeldung:

Invalid initial heap size: -Xms=512m
Could not create the Java virtual machine.

Was tun?

versuchs mal ohne das =
eventuell habe ich da was verwechselt. sorry.

 

[MKW]

Es ist bekannt, das speziell die Java-Version ein Problem beim Spider vieler Caches hat. Spätestens um die 100 ist wegen Speicherproblemen Schluss. Schalte doch einfach das Aktualisieren mal in den Preferences ganz ab (oder klicke auf "nein"). Das hat direkt mit Deinem Problem erst einmal nichts zu tun. Vielleicht kannst Du auch mal die 3 PM Caches noch einfügen. Dann würde mich einmal interessieren, wie weit Du kommst und ob nach einer bestimmten Zahl Caches im Profil nichts mehr kommt. Es scheint mir ein bisschen so, als würden nicht alle Seiten der Liste durchlaufen.

So sieht es aus. Ich habe das Aktualisieren in den Einstellungen abgeschaltet. Dann läuft er durch, mosert die 3 PM-Caches an und hört auf. Es wird nicht ein "neuer" Cache geladen.
Das Found-Profil kann ich Dir leider nicht mailen. Es ist gezipt 85 MB groß und mein Mail-Provider akzeptiert max. 50MB Anhänge.

Diese Liste ist nach dem Funddatum sortiert. Dann müßte man doch abbrechen können, wenn das eingegebene Datum erreicht ist.

Sowas könnte man irgendwie einbauen. Dann müsste man aber einiges ändern und könnte nicht größtenteils existierenden Code verwenden. Für was sollte diese Beschränkung gut sein?

Wenn eines schönen Tages mal alle alten Founds im Profil enthalten sind, dann möchte ich nur noch die "neuen" hinzufügen. Wenn ich nur die Anzahl limitieren kann, dann müßte ich genau wissen, wieviele Caches dazu gekommen sind, sonst geht der Spider die Liste bis zum Ende (>240 Seiten) durch. Viel einfacher wäre es, wenn ich grob das Datum der letzten Aktualisierung angebe und der Spider dann schon nach der z.B. fünften Seite der Liste abbrechen und die Einzelcaches laden kann.
So wie bis jetzt schon der max-Wert als Abbruchkriterium genutzt wird, müßte doch auch das Funddatum, das ja auch schon in der Liste enthalten ist, als Abbruchkriterium funktionieren.

 

[MiK]

Das Found-Profil kann ich Dir leider nicht mailen. Es ist gezipt 85 MB groß und mein Mail-Provider akzeptiert max. 50MB Anhänge.

Dann muss ich mal schauen, ob ich Dir eine andere Upload-Möglichkeit zur Verfügung stellen kann.

So wie bis jetzt schon der max-Wert als Abbruchkriterium genutzt wird, müßte doch auch das Funddatum, das ja auch schon in der Liste enthalten ist, als Abbruchkriterium funktionieren.

Ich kann es mir mal anschauen, ob das einfach integrierbar ist ohne viel Code duplizieren zu müssen. Im Moment musste nur an wenigen kleinen Stellen zwischen Umkreis-Spidern und Funde-Spidern unterschieden werden.

 

[greiol]

Wenn eines schönen Tages mal alle alten Founds im Profil enthalten sind, dann möchte ich nur noch die "neuen" hinzufügen.

das klassische vorgehen wäre da die als gefunden markierten caches im katuellen profil in das profil mit den gefundenen zu verschieben. datumsbasiertes spider könnte natürlich auch eine option sein.

 

[MiK]

Stimmt. Das ist natürlich weiterhin der Weg der Wahl für das spätere Pflegen dieses Profils. Nur so bleiben auch sämtliche Informationen erhalten, die man beim Suchen ergänzt hat.

Die Funktion sollte auch eher dabei helfen initial ein solches Profil aufzubauen, wenn man bisher nicht so vorgegangen ist.

 

[MKW]

Stimmt. Das ist natürlich weiterhin der Weg der Wahl für das spätere Pflegen dieses Profils. Nur so bleiben auch sämtliche Informationen erhalten, die man beim Suchen ergänzt hat.

Ach, so! Ich verstehe. Mein Interesse gilt nur der Erstellung der Statistik. Deswegen möchte ich am liebsten pro Cache nur einen Wegpunkt. Alle AddiWPs und Bilder brauche ich dafür nicht. Entweder könnte man das beim Spidern direkt unterdrücken und so Zeit und traffic sparen. Oder ich lösche die "überflüssigen" Dateien nachher von Hand im Finder.
Genau genommen brauche ich nur die index.xml.

 

[MiK]

Die Addis kosten beim Spidern nicht viel, da dafür keine extra Seite geladen werden muss. Die Bilder kannst Du ja jetzt schon abwählen.

 

[MKW]

Wieso kann man das Laden der Bilder beim Aktualisieren nicht abschalten?

 

[MiK]

Wieso kann man das Laden der Bilder beim Aktualisieren nicht abschalten?

Weil man beim Aktualisieren im Moment gar nichts einstellen kann.

 

[MiK]

Ich habe die Anfeindungen mal abgetrennt und auf die Wiese verschoben.