Problem mit Cachewolf und Web'n'Walk Box von T-Mobile

Hi,
erstmal vielen Dank an die Entwickler für ihre gute Arbeit. Ich nutze Cachewolf in der Windowsversion auf einem Notebook unter Vista. Funktioniert prima. Aktualisieren, Filtern... klappt alles. Danke!

Nun habe ich aber folgendes Problem:
Wenn ich CW auf meinem PC unter Vista installiere (Intel Q6600) - egal ob das aktuellste Nightly Build oder die Version von meinem Laptop passiert folgendes:
- Beim Spidern (und auch bei einem späteren Aktualisieren) werden gefundene Caches nicht erkannt. Auch bei einem späteren Aktualisieren nicht.
- Beim Filtern wird kein einziger Cache mehr angezeigt, wenn ich nur einen (!) Haken unter "Typen" oder "Addi Wpt" wegnehme - egal welchen. Andere Filter funzen.
- Wenn ich einen Cache auswähle, dann auf den Reiter "Details" klicke bekomme ich folgende Exception:
------->-------
java.lang.NumberFormatException
at ewe.sys.Convert.parseInt(Convert.java:<native method>)
at ewe.sys.Convert.parseInt(Convert.java)
at CacheWolf.DetailsPanel.transType(DetailsPanel.java:235)
at CacheWolf.DetailsPanel.setDetails(DetailsPanel.java:193)
at CacheWolf.MainTab.onEnteringPanel(MainTab.java:205)
at CacheWolf.MainTab.onEvent(MainTab.java:120)
at ewe.ui.Control.postEvent(Control.java)
at ewe.ui.CardPanel.selectAndPaint(CardPanel.java)
at ewe.ui.CardPanel.select(CardPanel.java)
-------<-------
Die Exception tritt nicht bei Addi Wpts in der Liste auf. Nur bei den Caches.

Wenn ich die Profile vom Notebook übernehme, funzen die solange, bis ich sie einmal aktualisiert habe. Dann treten die gleichen Probleme auf.

Woran kann das liegen? Bin so langsam ratlos.

Unterschiede sind:
Notebook: JRE 1.4 / PC JRE 1.6
Notebook: Zugriff über Proxy, PC: direkter Zugriff
Braucht CW spezielle Berechtigungen? Die Verzeichnise habe ich komplett freigegeben.

Viele Grüße
Tom

Arbeitest du mit der Win32- oder der JAR-Version?

Probier doch mal die jeweils andere aus, vielleicht läuft die ja?

Ansonsten wüsste ich nicht, dass CW mit anderen Verzeichnissen als dem Programm- und dem Profilverzeichnis arbeitet. Für diese (Programm- und Profilverzeichnis incl. Unterverzeichnissen) wird aber auf jeden Fall Schreibzugriff benötigt.

mit der Win32. Ich hab das aktuellste Jar ausprobiert - gleicher Effekt. Die Exception im Fenster ist jetzt
--------->-------------
java.lang.NumberFormatException: For input string: ""
at java.lang.NumberFormatException.forInputString(Unknown Source)
at java.lang.Integer.parseInt(Unknown Source)
at ewe.sys.Convert.parseInt(Convert.java)
at ewe.sys.Convert.parseInt(Convert.java)
java.lang.NumberFormatException: For input string: ""
at java.lang.NumberFormatException.forInputString(Unknown Source)
at java.lang.Integer.parseInt(Unknown Source)
at ewe.sys.Convert.parseInt(Convert.java)
at ewe.sys.Convert.parseInt(Convert.java)
at CacheWolf.DetailsPanel.transType(DetailsPanel.java:235)
at CacheWolf.DetailsPanel.setDetails(DetailsPanel.java:193)
at CacheWolf.MainTab.onEnteringPanel(MainTab.java:205)
at CacheWolf.MainTab.onEvent(MainTab.java:120)
at ewe.ui.Control.postEvent(Control.java)
at ewe.ui.CardPanel.selectAndPaint(CardPanel.java)
at ewe.ui.CardPanel.select(CardPanel.java)
at ewe.ui.mTabbedPanel.select(mTabbedPanel.java)
at ewe.ui.mTabbedPanel.selectAndExpand(mTabbedPanel.java)
at ewe.ui.TabsPanel.penPressed(mTabbedPanel.java)
at ewe.ui.Control.onPenEvent(Control.java)
at ewe.ui.Control.onEvent(Control.java)
at ewe.ui.Control.postEvent(Control.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)
---------<-------------

Ich glaube, ich bin bei der Suche etwas weiter. Mit dem PC bin ich über eine Web'n'Walk Box und T-Mobile im Internet. Und was machen die? Sie leiten offensichtlich alle Anfragen über einen Proxy, der dann aus

<img src="../images/WptTypes/check.gif"

folgendes macht

<img src="http://1.2.3.13/bmi/www.geocaching.com/images/WptTypes/check.gif"

Außerdem ist auch sonst jede Menge Müll in den Seiten :zensur:

Damit kommt CW vermutlich nicht klar. Mit dem Laptop bin ich über einen Tunnel mit einem andern Netzwerk verbunden, hier schlägt dieser Mist nicht zu.

Nachvollziehen lässt dich das, wenn man im Mozilla eine Suche nach Caches startet (man muss aber vermutlich über T-Mobile eingewählt sein!). Beim normalen ersten Aufruf kommt die kaputte URL heraus, wenn man die Seite mit Shift-Reload lädt (Pragma: no-cache / Cache-Control: no-cache) kommt die korrekte URL.

Ist das nicht total finster ???

Jetzt ist nur noch die Frage: Kann ich CW so umkonfigurieren, dass er damit klarkommt oder gibt es eine Möglichkeit, dass CW die Seiten quasi mit Shift-Reload aufruft?

Viele Grüße
Tom

Da werden wohl die Bilder auf deren Proxy runtergerechnet um die Bandbreite der mobilen Verbindung zu schonen.
Man müsste sich genau die Unterschiede zwischen der Originalseite und der geänderten Seite anschauen. Je nachdem, wie viel das ist, ist es evtl. mit kleineren Änderungen getan.

Speichere mal beide Seiten ab, zippe sie und poste sie dann hier. Vielleicht kannst Du es mit einer kleineren Änderung in Deiner spider.def zum Laufen bekommen.

Hallo Mik,
ich hab mal beide Varianten in das Zip gepackt.

Alternativ habe ich meinen Privoxy jetzt so konfiguriert, dass er für geocaching.com jetzt immer die komplette Seite erzwingt.
Im Browser klappt das wunderbar, leider kommt CW mit der Proxy-URL localhost (oder 127.0.0.1) und Port 8118 nicht klar. Da bekomme ich die Fehlermeldung "Login nicht möglich. Falscher Name oder Passwort?" Ich denke aber, dass das an der Proxy-Config liegt. Ich forsche hier mal noch ein bisschen.

Viele Grüße
Tom

Hallo MiK,

ich hab mal noch ein bischen probiert. Den Privoxy hab ich soweit, dass er für gc.com die Seiten ausliefert, ohne den T-Mobile-Cache/Proxy zu nutzen. Das funzt leider nur für den Browser.
Wenn ich CW auf den Privoxy konfiguriere (127.0.0.1:8118) funktioniert die Anmeldung nicht. CW-Log:
-------->--------
12.06.2008/20:24: [login]:Fetching login page
12.06.2008/20:24: [fetch]:Using proxy: 127.0.0.1 / 8118
12.06.2008/20:24: [fetch]:Cookie Zeug: Cookie: ASP.NET_SessionId=r05tks5501y4scalr3z5to45; userid=a5a8b1e5-e8ca-4fa7-9faa-126592a4bf0d
12.06.2008/20:24: [login]:Viewstate not found before login
12.06.2008/20:24: [login]:Eventvalidation not found before login
12.06.2008/20:24: [login]:Logging in as XXXXXXXX
12.06.2008/20:24: [fetch]:Cookie Zeug: Cookie: ASP.NET_SessionId=r05tks5501y4scalr3z5to45; userid=a5a8b1e5-e8ca-4fa7-9faa-126592a4bf0d
12.06.2008/20:24: [login]:Login failed. Wrong Account or Password?
--------<--------
Hier muss ich wohl noch ein bischen arbeiten.

Der Cache/Proxy von T-Mobile scheint auch über mehrer Adressen erreichbar zu sein. 1.2.3.01 - bis 13 hab ich schon gesehen. Teilweise auch mehrere unterschiedliche in einer Seite (siehe wrong.txt im zip)

Ich werde mal ne Anfrage an T-Mobile schicken. Mal sehen, was sie sagen.

Grüße
Tom

TomTom schrieb:

Hallo Mik,
ich hab mal beide Varianten in das Zip gepackt.

Zum Vergrößern anklicken....

Das ist aber nicht die Cachseite, sondern die Cachliste. Egal, versuche mal folgende Änderungen in Deiner spider.def:


Damit könnte es gehen.

Vielleicht könnten auch andere noch testen, ob es bei ihnen mit diesen zwei Zeilen Änderung funktioniert. Auch bei normalem Internetzugang. Bei ein paar positiven Rückmeldungen, kann es morgen noch in den RC2.

Edit: Ich habe die geänderte Variante mal angehängt.

Scheint zu funktionieren. Ich habe aber ehrlich gesagt nicht ganz verstanden, wo jetzt genau das Proglem lag.
Mit der geänderten spider.def habe ich probiert: Ganz normaler Spidervorgang, Markierte aktualisieren, gefundene Caches aktualisieren.

Gruß, maierkurt

Hallo

Hab auch mit der geänderten "spider.def" gespidert. Sah alles korrekt aus.

Morgendliche Grüsse
loMB

maierkurt schrieb:

Scheint zu funktionieren. Ich habe aber ehrlich gesagt nicht ganz verstanden, wo jetzt genau das Proglem lag.

Zum Vergrößern anklicken....

Der Proxy ändert das HTML ab, so dass die Verweise auf Bilder nun auf deren Server Zeigen anstatt auf den relativen lokalen Pfad. Dieser relative Pfad (..) war Teil der RegExen, die den Cachetyp und die Attribute ausliest. Diesen Teil habe ich dort entfernt, deswegen werden Typ und Attribute nun auch bei umgelenkten Links erkannt. Es könnte aber sein, dass es dadurch jetzt Fehlerkennungen beim Parsen gibt, deswegen ist es gut, wenn das noch einmal von einigen Leuten getestet wird.

Mein morgendliches Aktualisieren (keine Angst - nur die neuen, per GPX reingekommenen) hat die geänderte spider.def jedenfalls ohne Probleme überstanden. Sowohl Bilder als auch Attribute wurden klaglos übernommen...

Hallo MiK,

die neue Spider.def funktioniert für das Einlesen und Aktualisieren. Es gibt keine Abstürze/Exceptions mehr beim Umschalten auf die Detailseite. Weiterhin werden Bilder, Typ, Größe und Attribute richtig angezeigt.
Was nicht funktioniert, ist das Erkennen von gefundenen Caches und die Anzeige von Icons in den Logs. Hängt das zusammen?

Ich hänge Dir dazu mal noch eine Cacheseite und die entsprechende Ansicht in CW an. Evtl. schlägt ja
iconExStart = http://www.geocaching.com/images/icons/
fehl. Hier steht in der Seite
http://1.2.3.11/bmi/www.geocaching.com/images/icons/icon_smile.gif

Viele Grüße
Tom

Es wäre gut gewesen, wenn Du das passende Original dazu gepackt hättest.

Versuche es mal mit:

hatte ich vorher schon probiert, da kommt aber der Parser durcheinander. Siehe Bild. Das Original hab ich mal noch angehängt.

Tom.

Das Problem ist, dass im Original nur die Logicons mit dieser Sequenz anfangen. In der Proxy-Variante trifft das Muster auch auf andere Icons zu. Daran lässt sich jetzt auf den ersten Blick so einfach nichts ändern.

Welche Einschränkungen konntest Du dadurch nun genau feststellen?

mit der neuen spider.def momentan nur die, dass gefundene nicht gefiltert werden können und die Logs halt aussehen wie gezeigt.
Evtl. lässt sich das in einer späteren Version ergänzen? Mit den jetzigen Einschränkungen kann ich leben.
Wenn Du noch Tests oder Seiten brauchst, melde Dich!

Tom

Ich denke, dann lass ich das für die 1.0 erstmal so. Auf "gefunden" muss man dann eben von Hand setzen. Und in den Logs fehlen ja nur die Icons (erster Screenshot).
Alles weitere wird man dann nach dem Release sehen.