Doppellistings abgleichen -- cmanager

[mic@]

Dazu einige Fragen:

a) Wenn man von sagen wir mal 100 Caches in der MyFinds gpx ausgeht, wie schnell sind die beim normalen cmanager abgearbeitet
und wie schnell sind die bei einem cmanager, wo die Parallelität abgeschaltet wäre, abgearbeitet?

b) Müsste nicht alle cmanager Nutzer von diesem Problem betroffen sein?
Oder ist es bloß problematisch, wenn man den cmanager mit zig-tausenden Funden füttert?

[FriedrichFröbel]

a) Wenn man von sagen wir mal 100 Caches in der MyFinds gpx ausgeht, wie schnell sind die beim normalen cmanager abgearbeitet
und wie schnell sind die bei einem cmanager, wo die Parallelität abgeschaltet wäre, abgearbeitet?

Ich kann hier keine absoluten und auch keine genauen Zahlen nennen, da das von verschiedenen Faktoren abhängt. Aktuell gibt es 10 Threads, sodass je nach gewählter Anzahl Threads der vermutlich Maximalfaktor trivial berechnet werden kann, ohne auf konkrete Werte verweisen zu müssen. Meine kurzen Tests für die genannten 30 Caches warfen mit 2 Threads teilweise keinen Fehlerdialog. Ohne jegliche Parallelität wäre es am sichersten, aber auch am langsamsten. Die weiteren Einschränkungen bezüglich kompatibler Listengrößen etc. liegen nicht unter meiner Kontrolle.

b) Müsste dieser Fehler dann nicht alle cmanager Nutzer betreffen, oder ist es bloß zum Fehler geworden,
wenn man den cmanager mit zig-tausenden Funden füttert?

Wie gesagt: Ich konnte den Fehler auch mit 30 Caches reproduzieren. Im ungünstigsten Fall betrifft das alle cmanager-Benutzer. Meines Erachtens ist das jetzige Auftreten allerdings nicht durch Änderungen meinerseits zu erklären, sondern möglicherweise (wie bereits erwähnt) durch eventuelle neue/verschärfte Sicherheitsmaßnahmen auf Seiten OC, was sich auch auf die OKAPI auswirken würde/könnte. (So wie auch die OKAPI in letzter Zeit nur sehr selten Fulldumps liefert.)

[rennschnecke60]

Hallo,
ich antworte direkt, rennschnecke60 hier:
hier der detaillierte Fehler aus dem DOS-Aufruf:

Code: Alles auswählen

Mai 22, 2023 7:43:28 PM org.apache.http.impl.execchain.RetryExec execute
INFORMATION: Retrying request to {s}->https://www.opencaching.de:443
org.apache.http.NoHttpResponseException: www.opencaching.de:443 failed to respond
        at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:141)
        at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)
        at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
        at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
        at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:157)
        at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
        at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
        at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
        at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)
        at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
        at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
        at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
        at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
        at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108)
        at cmanager.network.ApacheHttp.get(ApacheHttp.java:53)
        at cmanager.okapi.Okapi.completeCacheDetails(Okapi.java:203)
        at cmanager.oc.OcUtil.findSingleGeocache(OcUtil.java:173)
        at cmanager.oc.OcUtil.lambda$findOnOc$0(OcUtil.java:67)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
        at java.base/java.lang.Thread.run(Thread.java:1623)

[rennschnecke60]

Guten Abend,
ich habe das Problem für mich gelöst.
Aus meiner GPX Datei habe ich alle Events und Celebration Events gelöscht und dann normal den Vorgang durchlaufen lassen.
Jetzt funktioniert es.
Mich würde es trotzdem interessieren, warum das so ist.

Gruß
Manuela aka rennschnecke60

[FriedrichFröbel]

Event-Caches sollten im Zusammenhang mit der OKAPI keine besondere Behandlung erfahren - die relevante Filterung anhand des Eventdatums erfolgt im cmanager selbst. Daher kann ich mir den Effekt nicht ohne weitere Beeinflussung erklären. Beispiele hierfür wären ein großer Anteil an Eventcaches in der GPX-Datei, eine Beeinflussung durch die lokale Speicherung leerer Ergebnisse auf Seiten des cmanager oder Änderungen am Netzwerk.

[rennschnecke60]

Ich habe tatsächlich nur die Löschung der Events vorgenommen. Bei der Durchsicht der Logs ist aufgefallen, dass ich ein Event übersehen habe. Das war das Brockenevent. Das ist dann auch als Doppellog angezeigt worden. Warum und woran es nun gelegen hat, kann ich nicht beschreiben.

[mic@]

Hier noch ein kleines Feedback von einer Apple-Userin:

# Wenn ich den cmanager öffne sieht es zunächst so (Bild1) aus. Das Fenster im Hintergrund läst sich verschieben,
# das weiße Feld bleibt wo es ist. Auch nach längerem Warten, ich dachte es braucht vielleicht etwas Ladezeit, tut sich nichts.
#
# Ich muss ihn ein paar mal hintereinander öffnen, dann ist das weiße Rechteck nicht mehr da. Dann kann ich die Anmeldung
# bei OC und GC machen (Bild 2 & 3)
#
# Wenn ich dann aber die zip laden will, wird mir im Öffnen Dialogfeld nichts angezeigt, obwohl die zip im entsprechenden Ordner
# liegt. Siehst du oberhalb des cmanagers (Bild 4)

[FriedrichFröbel]

Wie schon mehrfach zuvor erwähnt - ich habe keine Ahnung von Apple und eventuellen Eigenheiten hinsichtlich Berechtigungen etc. Ich kann daher aktuell nur empfehlen, für die Dateiablage verschiedene Verzeichnisse durchzuprobieren, bis die Datei sichtbar ist.

[untitled1]

Ich bin die zitierte Userin. Das hatte ich schon erfolglos versucht.
Da ich aber kein Freund von "mich ärgern" bin hab ich ziemlich schnell aufgegeben und mir mit meinem alten Labtop beholfen. Das hat wunderbar funktioniert.

Gruß untitled1

[mic@]

Ich kann daher aktuell nur empfehlen, für die Dateiablage verschiedene Verzeichnisse durchzuprobieren, bis die Datei sichtbar ist.

Ok, dann frage ich mal allgemein in die Runde.
Gibt es hier eine(n) cmanager-Nutzer(in) auf iOS Basis?
Und falls ja, welches Verzeuchnis ist bei Apple nutzbar?

[untitled1]

Wenn das eigentliche Ziel bereits erreicht ist, kann man so ein Problem ja viel entspannter angehen.
Das Problem mit dem weißen Rechteck und dem wiederholten Starten besteht noch, aber ich habe
nun doch noch ein paar Verzeichnisse gefunden auf die er zugreift. In meinem Fall z.B. der Benutzer
Ordner.

Ein Unterschied zwischen den Ordnern bzw. eine Gemeinsamkeit der Ordner die sich einlesen lassen
oder nicht kann ich allerdings nicht erkennen.

Für alle Ordner besteht grundsätzlich eine Schreib & Leseberechtigung

Vielleicht weiß ja jemand oder hat eine Idee wie die Zusammenhänge da sind.

Gruß untitled1

[mic@]

Guten Morgen,
ist dieses Problem hier bekannt?

Das Programm öffnet sich hinter dem Datei-Explorer und lässt sich nicht nach vorne bringen.

bad.jpg

Edition Windows 11 Home
Version 23H2
Installiert am ‎15.‎06.‎2023
Betriebssystembuild 22631.2861
Leistung Windows Feature Experience Pack 1000.22681.1000.0


ver :
Microsoft Windows [Version 10.0.22631.2861]


Java-Version :
java version "1.8.0_391"
Java(TM) SE Runtime Environment (build 1.8.0_391-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.391-b13, mixed mode)

[mic@]

Guten Abend,
habe gerade eine neue Nutzerin live bei ihren ersten cmanager Gehversuchen begleitet.
Dabei haben wir folgendes erlebt:

Wenn sie den cmanager doppelklickt, dann blinkt er nur kurz auf (0.1sec) und verschwindet wieder.
Wenn sie den cmanager über die Kommandozeile startet (java -jar cm-0.7.0.jar), dann erscheint der cmanager.

Installiert hat sie das offizielle Oracle JDK17 (17.0.10 2024-01-16 LTS)
Der PC nutzt Windows 10.0.19045.4046

Es klappt ja über den Umweg mit einem Batchfile, aber warum funktioniert der Doppelklick aus Windows nicht ?!
Ist das falsche Binary mit dem jar verknüpft?!

Schönen Gruß, Mic@

[FriedrichFröbel]

Wenn sie den cmanager doppelklickt, dann blinkt er nur kurz auf (0.1sec) und verschwindet wieder.
Wenn sie den cmanager über die Kommandozeile startet (java -jar cm-0.7.0.jar), dann erscheint der cmanager.

Installiert hat sie das offizielle Oracle JDK17 (17.0.10 2024-01-16 LTS)
Der PC nutzt Windows 10.0.19045.4046

Es klappt ja über den Umweg mit einem Batchfile, aber warum funktioniert der Doppelklick aus Windows nicht ?!
Ist das falsche Binary mit dem jar verknüpft?!

Ich meine mich zu erinnern, dass unter Umständen standardmäßig bei einem Doppelklick der -jar-Parameter fehlt. Das lässt sich möglicherweise irgendwo konfigurieren/anpassen/prüfen, aber über die Kommandozeile oder mit einem Doppelklick auf eine automatisierte Skriptdatei lässt sich zumindest relativ einfach garantieren, dass der Aufruf korrekt ist.

[mic@]

Ich meine mich zu erinnern, dass unter Umständen standardmäßig bei einem Doppelklick der -jar-Parameter fehlt. Das lässt sich möglicherweise irgendwo konfigurieren/anpassen/prüfen, aber über die Kommandozeile oder mit einem Doppelklick auf eine automatisierte Skriptdatei lässt sich zumindest relativ einfach garantieren, dass der Aufruf korrekt ist.

Mich wundert dabei nur, dass es bei mir ganz normal per Doppelklick klappt. Und bei ihr nicht !?!
Und wir beide arbeiten unter Windows. Nur sie hat ein neueres Java, denn meines ist nur

-->

java version "12.0.1" 2019-04-16
Java(TM) SE Runtime Environment (build 12.0.1+12)
Java HotSpot(TM) 64-Bit Server VM (build 12.0.1+12, mixed mode, sharing)