• 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

JonDo

Geocacher
Moin arbor95

Ich weis ja das Du gut bist, aber…
Mit so einer schnell Lösung hätte ich nicht gerechnet.
Das ist einfach spitzenmäßig.
Habe recht herzlichen Dank

Dann mach ich mich mal ans aktualisieren.

Mit freundlichen Grüßen
JonDo
 

JonDo

Geocacher
Moin arbor95

Wie ich gesehen habe, bist Du ja wieder fleißig am Updaten.
Ich habe da mal eine Frage zu CW 1.3.5182
Macht es viel Arbeit, wenn Du dabei Dir mal die Funktion des „Nicht gefunden“ eintrages anschaust?

Anfrage CW.jpg


Wenn es mehr wie einen Eintrag gibt, z.B. Parkplatz, Wegpunkt, Virtuelle Station… verhält der CW sich anders bei Gefunden als bei Nicht gefunden.

Bei Gefunden wird der Eintrag in der Zeile „Finde mich in Norden VII“ bauch bei den Wegpunkten berücksichtigt.

Bei Nicht Gefunden wir der Eintrag in der Zeile „Norddeich-Parcours“ in den Wegpunkten nicht berücksichtigt.

Auch beim Aktualisieren solcher eintrage verhält der CW sich unterschiedlich.

Bei Gefunden bleit der Status unverändert. Das ist gut so

Bei Nicht Gefunden wird Datum und Uhrzeit gelöscht!

Wenn es möglich wäre das hier anzupassen, das würde mir sehr helfen, denn das muß ich dann nicht mehr korrigieren.

Mit freundlichen Grüßen
Jon Do
 

arbor95

Geoguru
Fleissig eher nicht, es ging halt darum zu testen, ob der Server von Pfeffer wieder korrekt eingerichtet ist.
Aber es freut mich, dass ausser mir und ColleIsarco wenigstens noch ein Anwender von CachWolf existiert.

Die Änderung kann ich gleich mal probieren. Das sollte eigentlich möglich sein.
 

arbor95

Geoguru
"Auch beim Aktualisieren solcher eintrage verhält der CW sich unterschiedlich.
Bei Gefunden bleit der Status unverändert. Das ist gut so
Bei Nicht Gefunden wird Datum und Uhrzeit gelöscht!"
Sollte in der nächsten Version klappen.
Es gibt dafür übrigens eine Einstellung, die sich unter Import/Speicherung von Logs/ versteckt: "Uhrzeit beibehalten". Ohne Haken steht dann nur gefunden bzw. nicht gefunden, wenn ein entsprechender Log bei GC existiert.

Gerade noch kurz vor halb committed. Der build brauchte fast 6 Minuten. Jetzt steht schon die aktualisierte Version zur Verfügung.

Die Übernahme der DNFs auf die Wegpunkte habe ich nicht eingebaut.
Ich glaube, das braucht man nicht wirklich, oder?
 

mhsd

Geocacher
arbor95 schrieb:
Aber es freut mich, dass ausser mir und ColleIsarco wenigstens noch ein Anwender von CachWolf existiert.
Ihr seid nicht alleine. ;-) Ich bin eher der stille und zufriedene Nutzer. Immer wenn ich CacheWolf nutze funktioniert es fehlerfrei, oder es existiert bereits ein Update. Vielen lieben Dank dafür, daß Ihr Euch so kontinuierlich um das Programm kümmert. Ich möchte es nicht missen!
 

Gavriel

Geocacher
Ich möchte das Programm auch nicht missen. Es gibt kein anderes, mit dem man seine Offline-Datenbank (mit angefangenen Mysterylösungen etc.) so bequem samt Programm von einem PC zum anderen mitnehmen kann.
ein Spitzen Tool :)
 

JonDo

Geocacher
Moin arbor95

Hat soweit wieder sensationell geklappt. Hab vielen Dank dafür.
Du hast recht diese Funktion für nicht gefunden brauche ich auch nicht.

Jedoch schön wäre, wenn bei Gefunden, auch die Wegpunkte wieder Statusmäßig gelöscht werden, wenn man den Eintrag im Cache löscht.

Anbei wieder mal ein Beispiel


Gefunden.jpg


Nach ein Fehler, der bislang nur bei Java auftritt.
Bei längerem Aktualisieren, öffnet sich ein Fenster in grau über dem CW.
In der oberen Ecke steht 3 x Fehler, ansonsten ist das Fenster leer.

Das Fenster kann dann geschlossen werden, taucht aber immer wieder auf. Irgendwann so nach 3-10 mal stürzt das Programm ab.

Nach einem Neustart baue ich den Index neu auf, sicher ist sicher, und starte den Vorgang erneut. Dann läuft es meist ohne Probleme.

Hast Du dafür eine Erklärung?

Bei der Windows Version ist das bislang nicht ausgetaucht.

Mit freundlichen Grüßen
JonDo
 

arbor95

Geoguru
Der Status der zugehörigen Wegpunkte wird bisher bewusst nicht zurückgesetzt, da man ja die Wegpunkte schon gefunden haben könnte. (Aber das hat mich auch schon mal genervt. Kommt ja glücklicherweise nicht so häufig vor. Ich habe dann auch schon mal den Cache gelöscht und neu heruntergeladen.)

Ich arbeite auch immer mit der Java - Version (nicht mehr so häufig), aber auch grössere Aktualisierungen (nur die mache ich noch) sind bisher immer ohne Murren durchgelaufen.

Um welche Fehler/Meldungen handelt es sich denn? Könnte es sich um eine Meldung bezüglich nicht ausreichendem Memory handeln? Startest du das jar direkt oder mit Memory - Zuweisung?
 

JonDo

Geocacher
Moin arbor95

Anbei mal die Fehlermeldung

Fehler.jpg

Bezüglich Java

Das ist eine Frage, die ich so schnell nicht beantworten kann.

Wenn ich mich recht erinnere, habe ich bei Java nichts explizite eingestellt
Beim ersten Starten über Öffnen mit… Java ausgewählt und gefreut, das es lief.

Anbei mal die entsprechenden Einstellungen.

Java.jpg

Wenn ich auf Standardwerte wiederherstellen gehen Wird wieder sehr viel Speicher reserviert.
Was müßte denn da stehen damit der CW optimal versorgt wird?

Mit freundlichen Grüßen
JonDo
 

arbor95

Geoguru
Es gibt eine Datei namens cachewolf.bat (cachewolf klein geschrieben). Diese sollte zum Start verwendet werden. Darin stehen die passenden Parameter für die Speicherplatzreservierung der CacheWolf.jar - Datei . (Also so: start javaw -Xms64M -Xmx1024M -cp CacheWolf.jar ewe.applet.Applet CacheWolf.CacheWolf -c pref.xml)

Wenn du "Öffnen mit" für die CacheWolf.jar - Datei mal definiert hast, also du auf CacheWolf.jar einen Doppelklick machst, dann werden die Standardeinstellungen zum Start genommen (ich glaube -Xmx256M) und dann kann es vermutlich zu so etwas kommen, wie du beschrieben hast.
Starte cachewolf.bat mit Doppelklick.

Die Einstellungen im Java Control Panel sind da nicht relevant.
 

JonDo

Geocacher
Moin arbor95

Danke für Deine Ausführungen

Ich hab nmal im Link nachgeschaut, was ich da Starte und Du hast recht, die Datei hat die Endung CacheWolf.jar
Da war die Anpassung ja nicht so schwierig, habe einfach die Zeiger auf die Datei
cachewolf.bat
geändert. Nun bin mal gespannt, ob der Fehler weg ist.
Ach jeden Fall super erklärt.
Danke für Deine schnelle Hilfe. Und die die Anpassung im CW.

Mit freundlichen Grüßen
 

spaziergaenger

Geowizard
arbor95 schrieb:
...
Aber es freut mich, dass ausser mir und ColleIsarco wenigstens noch ein Anwender von CachWolf existiert.
...
Auch ich nutze den Cachewolf regelmäßig und gern und wollte mich an dieser Stelle auch mal bei allen bedanken, die das Programm pflegen und am Laufen halten.
 

JonDo

Geocacher
Moin arbor95
Leider taucht der Fehler trotzdem weiter auf. Manchmal ohne Absturz, manchmal mit Absturz. Darum habe ich mir mal die Log Datei im CW angeschaut und zumindest noch etwas gefunden, wo der CW nicht ganz rundläuft.

Die meisten Fehlermeldungen konnte ich nicht entschlüsseln, jedoch den letzten
Anhang anzeigen Log_Teil.zip

Im Cache: GC3NE08

Soll ein Bild geladen werden, was aber vom CW nicht eichtig geladen wird. Nach http fehlt noch das s (https)

http://www.bahnbilder.de//1024/die-ganze-anlage-macht-einen-500446.jpg

Your browser sent a request that this server could not understand.
Reason: You're speaking plain HTTP to an SSL-enabled server port.
Instead use the HTTPS scheme to access this URL, please.

https://www.bahnbilder.de//1024/die-ganze-anlage-macht-einen-500446.jpg

Könntest Du das vielleich auch bitte berücksichtigen?
Das wäre prima.

Mit freundlichen Grüßen
 

arbor95

Geoguru
Ohne jetzt etwas im Programm überprüft zu haben:
Wie soll ich das berücksichtigen, wenn der Link auf http:// lautet und kein sog. redirect als Antwort kommt?
Da gibt es primär 2 bis 4 Lösungsmöglichkeiten: 1) der Link wird auf der Webseite (gc) korrigiert. 2) der aufgerufene Webserver (bahnbilder.de, o.a.) korrigiert das automatisch (da sie keinen http mehr anbietet kann sie auch automatisch auf https umschalten) 3) der aufgerufene Webserver schickt eine redirect-Meldung (Nr 3xx) zurück an den Aufrufer. 4) wäre dann deine (meine) Lösung .
 

arbor95

Geoguru
Bei der nähere Überprüfung läßt sich feststellen, dass der Webserverver sich wie Fall 3 verhält und eine Meldung 301 zurückschickt und damit die korrekte Adresse siehe:
Request http://www.bahnbilder.de/1024/die-ganze-anlage-macht-einen-500446.jpg returned status-code: 301
kommt dann mit https*Rattenschwanz zurück.

Leider kommt dann ein Fehler im folgenden Programmbereich, in dem sich ColleIsarco bestens auskennt:
java.lang.UnsupportedClassVersionError
at gro.bouncycastle.asn1.ASN1InputStream.createPrimitiveDERObject(ASN1InputStream.java:451)
at gro.bouncycastle.asn1.ASN1InputStream.buildObject(ASN1InputStream.java:192)
at gro.bouncycastle.asn1.ASN1InputStream.readObject(ASN1InputStream.java:281)
at gro.bouncycastle.asn1.ASN1InputStream.buildEncodableVector(ASN1InputStream.java:201)
at gro.bouncycastle.asn1.ASN1InputStream.buildDEREncodableVector(ASN1InputStream.java:212)
at gro.bouncycastle.asn1.ASN1InputStream.buildObject(ASN1InputStream.java:181)
at gro.bouncycastle.asn1.ASN1InputStream.readObject(ASN1InputStream.java:281)
at gro.bouncycastle.asn1.ASN1InputStream.buildEncodableVector(ASN1InputStream.java:201)
at gro.bouncycastle.asn1.ASN1InputStream.buildDEREncodableVector(ASN1InputStream.java:212)
at gro.bouncycastle.asn1.ASN1InputStream.buildObject(ASN1InputStream.java:184)
at gro.bouncycastle.asn1.ASN1InputStream.readObject(ASN1InputStream.java:281)
at gro.bouncycastle.asn1.ASN1InputStream.buildEncodableVector(ASN1InputStream.java:201)
at gro.bouncycastle.asn1.ASN1InputStream.buildDEREncodableVector(ASN1InputStream.java:212)
at gro.bouncycastle.asn1.ASN1InputStream.buildObject(ASN1InputStream.java:181)
at gro.bouncycastle.asn1.ASN1InputStream.readObject(ASN1InputStream.java:281)
at gro.bouncycastle.asn1.ASN1InputStream.buildEncodableVector(ASN1InputStream.java:201)
at gro.bouncycastle.asn1.ASN1InputStream.buildDEREncodableVector(ASN1InputStream.java:212)
at gro.bouncycastle.asn1.ASN1InputStream.buildObject(ASN1InputStream.java:181)
at gro.bouncycastle.asn1.ASN1InputStream.readObject(ASN1InputStream.java:281)
at gro.bouncycastle.asn1.ASN1InputStream.buildEncodableVector(ASN1InputStream.java:201)
at gro.bouncycastle.asn1.ASN1InputStream.buildDEREncodableVector(ASN1InputStream.java:212)
at gro.bouncycastle.asn1.ASN1InputStream.buildObject(ASN1InputStream.java:181)
at gro.bouncycastle.asn1.ASN1InputStream.readObject(ASN1InputStream.java:281)
at gro.bouncycastle.crypto.tls.TlsUtils.readASN1Object(TlsUtils.java:671)
at gro.bouncycastle.crypto.tls.Certificate.parse(Certificate.java:121)
at gro.bouncycastle.crypto.tls.TlsClientProtocol.handleHandshakeMessage(TlsClientProtocol.java:172)
at gro.bouncycastle.crypto.tls.TlsProtocol.processHandshakeQueue(TlsProtocol.java:463)
at gro.bouncycastle.crypto.tls.TlsProtocol.processRecord(TlsProtocol.java:380)
at gro.bouncycastle.crypto.tls.RecordStream.readRecord(RecordStream.java:229)
at gro.bouncycastle.crypto.tls.TlsProtocol.safeReadRecord(TlsProtocol.java:603)
at gro.bouncycastle.crypto.tls.TlsProtocol.blockForHandshake(TlsProtocol.java:278)
at gro.bouncycastle.crypto.tls.TlsClientProtocol.connect(TlsClientProtocol.java:107)
at gro.cachewolf.tls.TlsSocket.<init>(TlsSocket.java:64)
at CacheWolf.utils.HttpConnection$2.doRun(HttpConnection.java:797)
at ewe.sys.TaskObject.run(TaskObject.java:150)
at ewe.sys.mThread.run(mThread.java:250)
at ewe.sys.Coroutine.run(Coroutine.java:145)
java.lang.UnsupportedClassVersionError
at gro.bouncycastle.asn1.ASN1InputStream.createPrimitiveDERObject(ASN1InputStream.java:451)
at gro.bouncycastle.asn1.ASN1InputStream.buildObject(ASN1InputStream.java:192)
at gro.bouncycastle.asn1.ASN1InputStream.readObject(ASN1InputStream.java:281)
at gro.bouncycastle.asn1.ASN1InputStream.buildEncodableVector(ASN1InputStream.java:201)
at gro.bouncycastle.asn1.ASN1InputStream.buildDEREncodableVector(ASN1InputStream.java:212)
at gro.bouncycastle.asn1.ASN1InputStream.buildObject(ASN1InputStream.java:181)
at gro.bouncycastle.asn1.ASN1InputStream.readObject(ASN1InputStream.java:281)
at gro.bouncycastle.asn1.ASN1InputStream.buildEncodableVector(ASN1InputStream.java:201)
at gro.bouncycastle.asn1.ASN1InputStream.buildDEREncodableVector(ASN1InputStream.java:212)
at gro.bouncycastle.asn1.ASN1InputStream.buildObject(ASN1InputStream.java:184)
at gro.bouncycastle.asn1.ASN1InputStream.readObject(ASN1InputStream.java:281)
at gro.bouncycastle.asn1.ASN1InputStream.buildEncodableVector(ASN1InputStream.java:201)
at gro.bouncycastle.asn1.ASN1InputStream.buildDEREncodableVector(ASN1InputStream.java:212)
at gro.bouncycastle.asn1.ASN1InputStream.buildObject(ASN1InputStream.java:181)
at gro.bouncycastle.asn1.ASN1InputStream.readObject(ASN1InputStream.java:281)
at gro.bouncycastle.asn1.ASN1InputStream.buildEncodableVector(ASN1InputStream.java:201)
at gro.bouncycastle.asn1.ASN1InputStream.buildDEREncodableVector(ASN1InputStream.java:212)
at gro.bouncycastle.asn1.ASN1InputStream.buildObject(ASN1InputStream.java:181)
at gro.bouncycastle.asn1.ASN1InputStream.readObject(ASN1InputStream.java:281)
at gro.bouncycastle.asn1.ASN1InputStream.buildEncodableVector(ASN1InputStream.java:201)
at gro.bouncycastle.asn1.ASN1InputStream.buildDEREncodableVector(ASN1InputStream.java:212)
at gro.bouncycastle.asn1.ASN1InputStream.buildObject(ASN1InputStream.java:181)
at gro.bouncycastle.asn1.ASN1InputStream.readObject(ASN1InputStream.java:281)
at gro.bouncycastle.crypto.tls.TlsUtils.readASN1Object(TlsUtils.java:671)
at gro.bouncycastle.crypto.tls.Certificate.parse(Certificate.java:121)
at gro.bouncycastle.crypto.tls.TlsClientProtocol.handleHandshakeMessage(TlsClientProtocol.java:172)
at gro.bouncycastle.crypto.tls.TlsProtocol.processHandshakeQueue(TlsProtocol.java:463)
at gro.bouncycastle.crypto.tls.TlsProtocol.processRecord(TlsProtocol.java:380)
at gro.bouncycastle.crypto.tls.RecordStream.readRecord(RecordStream.java:229)
at gro.bouncycastle.crypto.tls.TlsProtocol.safeReadRecord(TlsProtocol.java:603)
at gro.bouncycastle.crypto.tls.TlsProtocol.blockForHandshake(TlsProtocol.java:278)
at gro.bouncycastle.crypto.tls.TlsClientProtocol.connect(TlsClientProtocol.java:107)
at gro.cachewolf.tls.TlsSocket.<init>(TlsSocket.java:64)
at CacheWolf.utils.HttpConnection$2.doRun(HttpConnection.java:797)
at ewe.sys.TaskObject.run(TaskObject.java:150)
at ewe.sys.mThread.run(mThread.java:250)
at ewe.sys.Coroutine.run(Coroutine.java:145)
 

arbor95

Geoguru
Einfach ausgedrückt: ColleIsarco sollte noch etwas Code von bouncycastle übernehmen bezüglich Interpretation von IA5_STRING!
 

JonDo

Geocacher
Das hört sich an, als wenn Du, Ihr eine Idee habt, wie das abzuändern ist.
Ich Freue mich auf die Lösung.
Mit freundlichen Grüßen
 

arbor95

Geoguru
Ich habe den Code mal aktiviert. Das Bild wird jetzt heruntergeladen.
(Leider wird es nicht in der Beschreibung angezeigt, aber das wäre eine andere Baustelle)
 

JonDo

Geocacher
Moin arbor95

Gerade habe ich das neue Update 1.3.5184 probiert und das Bild wird wie von Dir bereits geschrieben nicht in der Beschreibung angezeigt, aber im Export wird es berücksichtigt.
Das ist doch schon mal die halbe Miete
Schön und schnell gemacht, das freut mich und bestimmt auch alle anderen Nutzer
Dankeschön.

Mit freundlichen Grüßen
 

ColleIsarco

Geowizard
äh ja, äh, also, da war ziemlich Druck hinter der BC-Anpassung, deswegen hatte ich mich seinerseit auf das Wesentliche konzentriert und alles Unnütze mit Exceptions abfangen lassen. Da gibt noch die ein oder andere Baustelle... und wie heißt es so schön: Nichts hält länger als ein Provisorium.
My Bad!

(Und dann war ich auch noch unterwegs...)

Trotzdem Gruß und Entschuldigung für die Unannehmlichkeiten.
 
Oben