BE 970 und folgende (Spiderprobleme)

MiK · 23 Okt. 2007

@Inder: Funktioniert es bei Dir auch, wenn Du zwei Aktualisierungsvorgänge in einer Session machen willst? Das scheint ja das Problem von lahmer zu sein.

Inder · 23 Okt. 2007

Gerade getestet:

Haken bei "allways login to GC" gesetzt.
3 Caches aktualisieren lassen
3 weitere aktualisiert
Ein wenig herumgeblättert, TB-Verwaltung aufgerufen
3 weiter aktualisiert

Keine Probleme

Ich äußere mal den Verdacht, dass lahmer evtl. die "datfiles" nicht auf den letzten Stand aktualisiert hat?!

lagrange · 24 Okt. 2007

Nabend.
Ich habe gerade von 978 auf komplett auf 987 aktualisiert, da ich ein kleines Problem beim Import von GPX hatte.
Nun mit der 987 hab ich beim Import unter Dateityp *.gpx *.zip *.loc entdeckt und daraufhin einfach mal die Zip-Dateien von GC direkt ohne entpacken ausprobiert. Das klappt anscheinend einwandfrei.
Ich weiß aber nicht, ob es eine beliebige gezippte Datei (von OC z.B.) sein kann oder ob da die zweite kleinere GPX (nur mit den Wegpunkten) mit drin sein muss. Die Konsole spuckt beim Versuch eine GPX-Datei zu importieren folgendes aus:

Code:

ewe.util.zip.ZipException: Zip format error: Missing End of Central Directory
        at ewe.util.zip.ZipFile.<init>(ZipFile.java)
        at ewe.util.zip.ZipFile.<init>(ZipFile.java)
        at CacheWolf.GPXImporter.doIt(GPXImporter.java:114)
        at CacheWolf.MainMenu.onEvent(MainMenu.java:299)
        at ewe.ui.Control.postEvent(Control.java)
        at ewe.ui.MenuState.onEvent(MenuState.java)
        at ewe.ui.Control.sendToListeners(Control.java)
        at ewe.ui.Control.postEvent(Control.java)
        at ewe.ui.Menu.postEvent(Menu.java)
        at ewe.ui.Menu.onEvent(Menu.java)
        at ewe.ui.Control.sendToListeners(Control.java)
        at ewe.ui.Control.postEvent(Control.java)
        at ewe.ui.Menu.postEvent(Menu.java)
        at ewe.ui.Control.notifyAction(Control.java)
        at ewe.ui.Menu.penReleased(Menu.java)
        at ewe.ui.Control.penClicked(Control.java)
        at ewe.ui.Control.onPenEvent(Control.java)
        at ewe.ui.Menu.onPenEvent(Menu.java)
        at ewe.ui.Control.onEvent(Control.java)
        at ewe.ui.Menu.onEvent(Menu.java)
        at ewe.ui.Control.postEvent(Control.java)
        at ewe.ui.Menu.postEvent(Menu.java)
        at ewe.ui.Window.doPostEvent(Window.java)
        at ewe.ui.Window$windowThread.run(Window.java)
        at ewe.sys.mThread.run(mThread.java)
        at ewe.sys.Coroutine.run(Coroutine.java)

Drum bitte ich um Überprüfung.

Weiterhin kann ich auf meinem Linux-System die Caches nicht "Im Browser online/offline öffnen". Habe als Befehlszeile angegeben "/usr/bin/firefox" (OHNE die Anführungsstriche) was auch korrekt ist.
Folgender Fehler wird ausgespuckt:

Code:

Cannot start Browser!
ewe.io.IOException: Cannot run program ""/usr/bin/firefox"": java.io.IOException:
error=2, No suchfile or directory
There are two possible reasons: bla falscher Pfad, bla Bug in ewe

Übrigens vielen Dank für dieses geniale Programm, ist eine wahre Leistung, was Ihr da vollbringt, und das ganze dazu noch in OpenSource und Plattformunabhängig. Einfach traumhaft!

Einen kleinen Verbesserungsvorschlag habe ich dann aber doch noch, auch wenn ich mir vorstelle, dass dies sicher kaum zu machen ist.
Und zwar kopiere ich meinen Profilordner ca. 1x die Woche von der Speicherkarte, die ich am Computer und im PPC nutze, auf die Festplatte und eine andere Speicherkarte. Da sich mittlerweile über 6000 Dateien im Profil befinden, kam mir die Idee ob man das ganze nicht einfach in einen TAR-Ball schieben könnte und darin live arbeitet? Das würde die Backups und Kopieraktionen wesentlich beschleunigen.

Gruß Sebastian

MiK · 24 Okt. 2007

lagrange schrieb:
Weiterhin kann ich auf meinem Linux-System die Caches nicht "Im Browser online/offline öffnen". Habe als Befehlszeile angegeben "/usr/bin/firefox" (OHNE die Anführungsstriche) was auch korrekt ist.
Folgender Fehler wird ausgespuckt:

Code:

Cannot start Browser! ewe.io.IOException: Cannot run program ""/usr/bin/firefox"": java.io.IOException: error=2, No suchfile or directory There are two possible reasons: bla falscher Pfad, bla Bug in ewe

Leider trifft da zweiteres zu. Das ist ein Bug in EWE, wegen dem wir keine externen Programme aufrufen können.

lagrange schrieb:
Einen kleinen Verbesserungsvorschlag habe ich dann aber doch noch, auch wenn ich mir vorstelle, dass dies sicher kaum zu machen ist.
Und zwar kopiere ich meinen Profilordner ca. 1x die Woche von der Speicherkarte, die ich am Computer und im PPC nutze, auf die Festplatte und eine andere Speicherkarte. Da sich mittlerweile über 6000 Dateien im Profil befinden, kam mir die Idee ob man das ganze nicht einfach in einen TAR-Ball schieben könnte und darin live arbeitet? Das würde die Backups und Kopieraktionen wesentlich beschleunigen.

Das wäre einer Überlegung wert. Aber nur, wenn EWE dafür schon etwas zur Verfügung stellt, um in tar oder unkomprimierten zip zu arbeiten.

Kappler · 24 Okt. 2007

Einen kleinen Verbesserungsvorschlag hätte ich noch zum Aktualisieren:

Beim Aktualisieren mehrerer Caches wäre es schön, wenn über den Fortschritt informiert würde:
Entweder über einen Fortschrittsbalken oder über eine Textdarstellung der Form:

1.Zeile: Loading gc... (wie bisher)
2.Zeile: 12/125

Platz müsste in dem kleinen Dialog dafür eigentlich sein...

MiK · 24 Okt. 2007

Kappler schrieb:
Beim Aktualisieren mehrerer Caches wäre es schön, wenn über den Fortschritt informiert würde:
Entweder über einen Fortschrittsbalken oder über eine Textdarstellung der Form:

1.Zeile: Loading gc... (wie bisher)
2.Zeile: 12/125

Hört sich sinnvoll an. Werde ich mir mal anschauen.

UUS · 24 Okt. 2007

Erstmal vorneweg: ein tolles Tool, auf das ich als nicht Premium Member nicht mehr verzichten möchte. Vielen Dank.

Ich habe mal ein wenig mit der Version 987 herumprobiert und mir sind ein paar Sachen aufgefallen, die nicht funktionieren:

- Beim Spidern werden alle Bilder wie gewünscht geladen, wenn der gleiche Cache aktualisiert wird, sind die Bilder weg. Nach dem Löschen und neu spidern sind die Bilder dann aber wieder da. Bei der 978 ging das Aktualisieren noch. Habe die Windows Version incl. neuer spider.def getestet.

- Beim HTML-Export funktionieren die Variablen SHORTTYPE, SHORTSIZE und STATUS nicht.

- Beim Spidern des Caches GCR5ZV Ruhrpott-Megacache I: Acht Kostbarkeiten hört das spidern nach der ersten von 8 Stage Beschreibungen auf.

Gruß
Uwe.

MiK · 24 Okt. 2007

MiK schrieb:
Kappler schrieb:

Beim Aktualisieren mehrerer Caches wäre es schön, wenn über den Fortschritt informiert würde:
Entweder über einen Fortschrittsbalken oder über eine Textdarstellung der Form:

1.Zeile: Loading gc... (wie bisher)
2.Zeile: 12/125

Zum Vergrößern anklicken....

Hört sich sinnvoll an. Werde ich mir mal anschauen.

Ist jetzt in r988 drin.

Kappler · 24 Okt. 2007

MiK schrieb:
Ist jetzt in r988 drin.

Super...

Danke schön!

MiK · 24 Okt. 2007

UUS schrieb:
- Beim Spidern werden alle Bilder wie gewünscht geladen, wenn der gleiche Cache aktualisiert wird, sind die Bilder weg. Nach dem Löschen und neu spidern sind die Bilder dann aber wieder da. Bei der 978 ging das Aktualisieren noch. Habe die Windows Version incl. neuer spider.def getestet.

Also bei einem Test blieben bei mir gerade die Bilder erhalten. Liegt vielleicht am Cache. Bei welchem ist es bei Dir aufgetreten?

UUS schrieb:
- Beim Spidern des Caches GCR5ZV Ruhrpott-Megacache I: Acht Kostbarkeiten hört das spidern nach der ersten von 8 Stage Beschreibungen auf.

Tja, da hast Du wahrscheinlich das gleiche Problem: Der Cache ist Premium Member only. Deswegen kann ich auch nicht testen, ob es damit noch weitere Probleme gibt.

UUS · 24 Okt. 2007

Hallo MiK,

MiK schrieb:
UUS schrieb:

- Beim Spidern werden alle Bilder wie gewünscht geladen, wenn der gleiche Cache aktualisiert wird, sind die Bilder weg. Nach dem Löschen und neu spidern sind die Bilder dann aber wieder da. Bei der 978 ging das Aktualisieren noch. Habe die Windows Version incl. neuer spider.def getestet.

Zum Vergrößern anklicken....

Also bei einem Test blieben bei mir gerade die Bilder erhalten. Liegt vielleicht am Cache. Bei welchem ist es bei Dir aufgetreten?

Das die Bilder verloren gehen, passiert eigentlich bei jedem Cache, der welche enthält, exemplarisch wären z.B. GC16FR3 und GC15BZM. Wenn ich dann wieder die 978er-EXE Dattei nehme und neu aktualisiere, sind die Bilder wieder da.

MiK schrieb:
UUS schrieb:

- Beim Spidern des Caches GCR5ZV Ruhrpott-Megacache I: Acht Kostbarkeiten hört das spidern nach der ersten von 8 Stage Beschreibungen auf.

Zum Vergrößern anklicken....

Tja, da hast Du wahrscheinlich das gleiche Problem: Der Cache ist Premium Member only. Deswegen kann ich auch nicht testen, ob es damit noch weitere Probleme gibt.

Ich glaube nicht, dass der Cache ein "Premium Member only" ist, denn ich kann mir die Beschreibung im Browser ohne Einschränkungen ansehen. Das Spidern hört einfach vor der Trennlinie zur 2-ten Stage auf.

--

Gruß
Uwe.

MiK · 24 Okt. 2007

UUS schrieb:
Das die Bilder verloren gehen, passiert eigentlich bei jedem Cache, der welche enthält, exemplarisch wären z.B. GC16FR3 und GC15BZM. Wenn ich dann wieder die 978er-EXE Dattei nehme und neu aktualisiere, sind die Bilder wieder da.

Ich habe es gerade mal mit GC16FR3 getestet. Die beiden Bilder bleiben bei mir erhalten.

UUS schrieb:
Ich glaube nicht, dass der Cache ein "Premium Member only" ist, denn ich kann mir die Beschreibung im Browser ohne Einschränkungen ansehen. Das Spidern hört einfach vor der Trennlinie zur 2-ten Stage auf.

Da hattest Du einen Fehler im Waypoint. Du meinst also GCP5ZV. Zuerst fällt mir dort auf, dass überhaupt keine Additional Waypoints angegeben sind. Aber Du hast recht: Die Cachebeschreibung wird nicht vollständig extrahiert. Das liegt daran, dass der Owner mitten in der Beschreibung schon "Additional Hints" gibt. Da müsste man mal schauen, warum die Regex an dieser Stelle nicht greedy ist.

MiK · 24 Okt. 2007

MiK schrieb:
Aber Du hast recht: Die Cachebeschreibung wird nicht vollständig extrahiert. Das liegt daran, dass der Owner mitten in der Beschreibung schon "Additional Hints" gibt. Da müsste man mal schauen, warum die Regex an dieser Stelle nicht greedy ist.

Naja, wenn man es greedy machen würde, hätte man dann vielleicht ein ähnliches Problem, wenn sowas in den Logs auftauchen würde. Spidern ist eben keine exakte Wissenschaft.

Aber für diesen Cache ist Dir erstmal geholfen, wenn Du diese Zeile in der spider.def entsprechend erweiterst:

Code:

longDescRex        = <span\ id="LongDescription">((?s).*?)<strong>Additional\ Hints \\(</strong>

UUS · 24 Okt. 2007

MiK schrieb:
Ich habe es gerade mal mit GC16FR3 getestet. Die beiden Bilder bleiben bei mir erhalten.

Ich habe mir eine frische Installation ohne Settings gebaut und das Problem mit den Bildern nach der Aktualisierung besteht bei der 987 immer noch.

Nach dem Spidern des Caches werden die Bilder angezeigt und sind auch in der GC16FR3.xml eingetragen. Nach dem Aktualisieren des Caches liegen die Bilder interessanterweise noch im Profil-Verzeichnis, sind aber nicht mehr in der GC16FR3.xml eingetragen und werden auch nicht mehr angezeigt.

Ich wüsste nicht, wo ich einen Fehler gemacht hätte. Kann aber natürlich trotzdem irgendwie an meiner Dusseligkeit liegen. Aber ich kann das Verhalten reproduzieren.

MiK schrieb:
Da hattest Du einen Fehler im Waypoint. Du meinst also GCP5ZV. Zuerst fällt mir dort auf, dass überhaupt keine Additional Waypoints angegeben sind. Aber Du hast recht: Die Cachebeschreibung wird nicht vollständig extrahiert. Das liegt daran, dass der Owner mitten in der Beschreibung schon "Additional Hints" gibt. Da müsste man mal schauen, warum die Regex an dieser Stelle nicht greedy ist.

Sorry, da habe ich mich natürlich im Waypoint vertippt. Asche auf mein Haupt.

MiK schrieb:
MiK schrieb:

Aber Du hast recht: Die Cachebeschreibung wird nicht vollständig extrahiert. Das liegt daran, dass der Owner mitten in der Beschreibung schon "Additional Hints" gibt. Da müsste man mal schauen, warum die Regex an dieser Stelle nicht greedy ist.

Zum Vergrößern anklicken....

Naja, wenn man es greedy machen würde, hätte man dann vielleicht ein ähnliches Problem, wenn sowas in den Logs auftauchen würde. Spidern ist eben keine exakte Wissenschaft.

MiK schrieb:
Aber für diesen Cache ist Dir erstmal geholfen, wenn Du diese Zeile in der spider.def entsprechend erweiterst:

Code:

longDescRex = <span\ id="LongDescription">((?s).*?)<strong>Additional\ Hints \\(</strong>

Super, vielen Dank, das sieht wirklich besser aus.

--

Gruß
Uwe.

lahmer · 25 Okt. 2007

MiK schrieb:
Also eigentlich sollte seit 981 das "Always login" beim Aktualisieren wieder ignoriert werden. Es sollte eigentlich beim Aktualisieren keinen Unterschied machen, ob der Haken gesetzt ist oder nicht.

Es sollte dann eigentlich nur beim ersten Cache ein login erfolgen und später in dieser Session nicht mehr.

Vielleicht kann ich mir das heute Abend mal genauer anschauen. Im Moment fällt mir dazu nichts mehr ein.

Hab jetzt nochmal auf die 986 aktualisiert und der Fehler ist weg... mir ist völlig unklar, was ich jetzt anders gemacht habe als beim ersten Mal, aber hiermit ziehe ich meine Fehlermeldung zurück und entschuldige mich für die Panikmache. Und natürlich trotzdem vielen Dank für die schnelle Hilfe.

mirabilos · 26 Okt. 2007

(es geht um .tar.gz)

wallace&gromit schrieb:
Kann man das mit Win-Bordmitteln auspacken oder braucht man dazu noch ne Software? Hab wenig Lust extra was zu installieren!

Sorry deswegen, aber zumindest Windows 2000 hat *kein*
Packprogramm/-format als „Bordmittel“ dabei (na gut, .tar
ohne .gz geht, aber nur mit der Kommandozeile), und tar
(alles hintereinanderschreiben) + gzip (das dann komprimieren)
ist das unter Unix standardisierte Format.

Ich weiß sicher, daß WinZip 8 das entpacken kann.

MiK · 26 Okt. 2007

Einfach zip benutzen, dass jedes vernünftige OS einfach zur Verfügung stellt, wäre ja auch zu einfach.

mirabilos · 26 Okt. 2007

Das ist ein Fremdformat. Jetzt gibt’s tar, das kann man unter
Windows (NT und höher) und Unix/Linux/whatever mit
Bordmitteln entpacken.

MiK · 26 Okt. 2007

Was meinst Du denn mit "Fremdformat"? Nur weil es Dir fremd ist? Glaube mir: tar ist viel mehr Leuten fremd.

mirabilos · 27 Okt. 2007

Naja, es kommt halt auf den Standpunkt an.
Und solange die Snapshots von mir sind, ist
das halt der Standpunkt eines DOS- und
Unix-Nutzers (und unter DOS ist LHarc das
Format der Wahl, ggf. noch ARJ, also komm
mir nicht mit PKZIP ☺)

Sag mal, kann sein, daß Du was gegen mich hast?
Ich hoffe, Du läßt Dich nicht so davon leiten…

BE 970 und folgende (Spiderprobleme)

Geoguru

Geowizard

Geocacher

Geoguru

Geowizard

Geoguru

Geocacher

Geoguru

Geowizard

Geoguru

Geocacher

Geoguru

Geoguru

Geocacher

Geocacher

Geocacher

Geoguru

Geocacher

Geoguru

Geocacher