Doppellistings abgleichen -- cmanager
Moderator: mic@
-
following
Heute kam die aktuelle OKAPI-Wochenstatistik rein. Die OKAPI-Anfragen von cmanager haben sich seit der Vorwoche um 80% erhöht - damit steht das Programm nun auf Platz 2 hinter c:geo. Gleichzeitig hat sich die Serverlast durch cmanager um 95% verringert und ist nun vernachlässigbar. Prima.
-
Samsung1
[quote="following"]
Heute kam die aktuelle OKAPI-Wochenstatistik rein. Die OKAPI-Anfragen von cmanager haben sich seit der Vorwoche um 80% erhöht - damit steht das Programm nun auf Platz 2 hinter c:geo. Gleichzeitig hat sich die Serverlast durch cmanager um 95% verringert und ist nun vernachlässigbar. Prima.
[/quote]
hihi... sehr schick!
Heute kam die aktuelle OKAPI-Wochenstatistik rein. Die OKAPI-Anfragen von cmanager haben sich seit der Vorwoche um 80% erhöht - damit steht das Programm nun auf Platz 2 hinter c:geo. Gleichzeitig hat sich die Serverlast durch cmanager um 95% verringert und ist nun vernachlässigbar. Prima.
[/quote]
hihi... sehr schick!
So, mit der neuen Version "w" hat es nun geklappt.
Aber einige Anmerkungen dazu von mir:
a) Das neue Programm startete zwar, aber meckerte über die zu große Heap Size.
Also habe ich es von 4096 auf 2048 heruntergedreht. Allerdings scheint auch
diese Größe der cmanager nicht zu mögen, nur sagt er das erst bei einem neuen
Start und NICHT schon beim Setzen des Wertes. Der Wert, der dann letzten Endes
funktioniert hat, war 1024.
b) Das Abarbeiten einer gpx-Datei von ca. 11000 Funden hat recht lange gedauert (2h).
Kann man hier noch was beschleunigen?
c) Nun muss man bei jedem Doppellisting auf die oc-Zeile doppelklicken und
das Loggen bestätigen. Das dauert bei den über 400 gefundenen eine Weile.
Hier wäre es nett, wenn man entweder die sicheren Fälle (Algorithmus bei 90%)
automatisch loggen kann. Und weiterhin wäre es nicht schlecht, wenn es neben
dem "Return" auch ein "Next" gäbe, so daß man gleich im nächsten Doppellisting
landet. Wenn dann noch der Übertragungsbutton auf der gleichen Position liegt,
kann man viel schneller die Logs übertragen.
d) Anscheinend gibt es ja keine Möglichkeit, die myfinds.gpx nur ab einem bestimmten
Datum erstellen zu lassen. Oder mit anderen Worten... diese Datei wird bei jedem
User mit der Zeit immer größer. Und damit das Handling vom cmanager immer
schwergängiger. Oder habe ich da was übersehen?
Ansonsten ein tolles Tool, daß um Welten besser ist als ocprop.
Dickes DANKE dafür!!!
Aber einige Anmerkungen dazu von mir:
a) Das neue Programm startete zwar, aber meckerte über die zu große Heap Size.
Also habe ich es von 4096 auf 2048 heruntergedreht. Allerdings scheint auch
diese Größe der cmanager nicht zu mögen, nur sagt er das erst bei einem neuen
Start und NICHT schon beim Setzen des Wertes. Der Wert, der dann letzten Endes
funktioniert hat, war 1024.
b) Das Abarbeiten einer gpx-Datei von ca. 11000 Funden hat recht lange gedauert (2h).
Kann man hier noch was beschleunigen?
c) Nun muss man bei jedem Doppellisting auf die oc-Zeile doppelklicken und
das Loggen bestätigen. Das dauert bei den über 400 gefundenen eine Weile.
Hier wäre es nett, wenn man entweder die sicheren Fälle (Algorithmus bei 90%)
automatisch loggen kann. Und weiterhin wäre es nicht schlecht, wenn es neben
dem "Return" auch ein "Next" gäbe, so daß man gleich im nächsten Doppellisting
landet. Wenn dann noch der Übertragungsbutton auf der gleichen Position liegt,
kann man viel schneller die Logs übertragen.
d) Anscheinend gibt es ja keine Möglichkeit, die myfinds.gpx nur ab einem bestimmten
Datum erstellen zu lassen. Oder mit anderen Worten... diese Datei wird bei jedem
User mit der Zeit immer größer. Und damit das Handling vom cmanager immer
schwergängiger. Oder habe ich da was übersehen?
Ansonsten ein tolles Tool, daß um Welten besser ist als ocprop.
Dickes DANKE dafür!!!
-
following
[quote="mic@"]
c) Nun muss man bei jedem Doppellisting auf die oc-Zeile doppelklicken und
das Loggen bestätigen. Das dauert bei den über 400 gefundenen eine Weile.
Hier wäre es nett, wenn man entweder die sicheren Fälle (Algorithmus bei 90%)
automatisch loggen kann. [/quote]
Ich finde das gut, dass jedes Log bestätigt werden muss. Ein Tool das unbeaufsichtigt hunderte von Logs bei OC einstellt würde mich nervös machen ... man stelle sich nur vor, dass sich in einer neuen Version ein Bug einschleicht und dann lassen 10 Leute mit zusammen 50.000 GC-Funden das Ding laufen ...
c) Nun muss man bei jedem Doppellisting auf die oc-Zeile doppelklicken und
das Loggen bestätigen. Das dauert bei den über 400 gefundenen eine Weile.
Hier wäre es nett, wenn man entweder die sicheren Fälle (Algorithmus bei 90%)
automatisch loggen kann. [/quote]
Ich finde das gut, dass jedes Log bestätigt werden muss. Ein Tool das unbeaufsichtigt hunderte von Logs bei OC einstellt würde mich nervös machen ... man stelle sich nur vor, dass sich in einer neuen Version ein Bug einschleicht und dann lassen 10 Leute mit zusammen 50.000 GC-Funden das Ding laufen ...
Und hier das letzte Update:
e) Originalzitat "Nach ca. 300 logs ist das Programm abgestürzt. War nichts mehr zu sehen... hab
jetzt aus gemacht. Werde in ein zwei Wochen eh noch mal ne neue PQ durchjagen. Dann sollten
da nur noch so 150 angezeigt werden..."
Falls Du die gpx-Datei zu Testzwecken benötigst, dann kann ich versuchen,
sie auf ein Google Drive hochzuladen. Sie ist ca. 50MB groß.
e) Originalzitat "Nach ca. 300 logs ist das Programm abgestürzt. War nichts mehr zu sehen... hab
jetzt aus gemacht. Werde in ein zwei Wochen eh noch mal ne neue PQ durchjagen. Dann sollten
da nur noch so 150 angezeigt werden..."
Falls Du die gpx-Datei zu Testzwecken benötigst, dann kann ich versuchen,
sie auf ein Google Drive hochzuladen. Sie ist ca. 50MB groß.
-
Samsung1
[quote="Slini11"]
Nebenbei: Der github-Link im ersten Post scheint nicht mehr zu funktionieren?
[/quote]
Danke, ist korrigiert.
[quote="mic@"]
So, mit der neuen Version "w" hat es nun geklappt.
Aber einige Anmerkungen dazu von mir:
a) Das neue Programm startete zwar, aber meckerte über die zu große Heap Size.
Also habe ich es von 4096 auf 2048 heruntergedreht. Allerdings scheint auch
diese Größe der cmanager nicht zu mögen, nur sagt er das erst bei einem neuen
Start und NICHT schon beim Setzen des Wertes. Der Wert, der dann letzten Endes
funktioniert hat, war 1024.
[/quote]
b) Das Abarbeiten einer gpx-Datei von ca. 11000 Funden hat recht lange gedauert (2h).
Kann man hier noch was beschleunigen?
[/quote]
Ich sehe aktuell kein Optimierungspotential im Algorithmus mehr. Was genau ist langsam? Die Abfrage gegen die Okapi?
[quote="mic@"]
c) Nun muss man bei jedem Doppellisting auf die oc-Zeile doppelklicken und
das Loggen bestätigen. Das dauert bei den über 400 gefundenen eine Weile.
Hier wäre es nett, wenn man entweder die sicheren Fälle (Algorithmus bei 90%)
automatisch loggen kann. Und weiterhin wäre es nicht schlecht, wenn es neben
dem "Return" auch ein "Next" gäbe, so daß man gleich im nächsten Doppellisting
landet. Wenn dann noch der Übertragungsbutton auf der gleichen Position liegt,
kann man viel schneller die Logs übertragen.
[/quote]
Automatisch möchte ich nicht. Das kann m.E. nach zu schnell schief gehen. Ein Next-Button wäre eine Überlegung - wobei der u.U. auch zum Durch hasten verleiten könnte...
[quote="mic@"]
d) Anscheinend gibt es ja keine Möglichkeit, die myfinds.gpx nur ab einem bestimmten
Datum erstellen zu lassen. Oder mit anderen Worten... diese Datei wird bei jedem
User mit der Zeit immer größer. Und damit das Handling vom cmanager immer
schwergängiger. Oder habe ich da was übersehen?
[/quote]
Das ist wohl leider korrekt. Da könnte man sich vielleicht mal bei der Plattform beschweren, der man Geld bezahlt
.
[quote="mic@"]
e) Originalzitat "Nach ca. 300 logs ist das Programm abgestürzt. War nichts mehr zu sehen... hab
jetzt aus gemacht. Werde in ein zwei Wochen eh noch mal ne neue PQ durchjagen. Dann sollten
da nur noch so 150 angezeigt werden..."
Falls Du die gpx-Datei zu Testzwecken benötigst, dann kann ich versuchen,
sie auf ein Google Drive hochzuladen. Sie ist ca. 50MB groß.
[/quote]
Nach einem Neustart sollte der nächste Durchgang dank des lokalen Caches recht zügig gehen. (Relativ zum originalen Durchgang
). Ohne eine konkrete Beschreibung, bei welchem Klick (Beim Loggen welchen Caches?) es kracht, suche ich mich da vermutlich nur tot :|
[quote="mic@"]
Ansonsten ein tolles Tool, daß um Welten besser ist als ocprop.
Dickes DANKE dafür!!!
[/quote]
Danke ebenso
Nebenbei: Der github-Link im ersten Post scheint nicht mehr zu funktionieren?
[/quote]
Danke, ist korrigiert.
[quote="mic@"]
So, mit der neuen Version "w" hat es nun geklappt.
Aber einige Anmerkungen dazu von mir:
a) Das neue Programm startete zwar, aber meckerte über die zu große Heap Size.
Also habe ich es von 4096 auf 2048 heruntergedreht. Allerdings scheint auch
diese Größe der cmanager nicht zu mögen, nur sagt er das erst bei einem neuen
Start und NICHT schon beim Setzen des Wertes. Der Wert, der dann letzten Endes
funktioniert hat, war 1024.
[/quote]
- Das Problem ist leider (Java) systembedingt. Daher auch der Hinweis im Einstellungsfenster. Ohne Neustart des Programms geht es nicht.
- Du bist nicht auf 2er Potenzen begrenzt. Du kannst dort auch Werte wie 1234 eingeben .
- Wie bereits oben geschrieben: 64bit VM installieren!
b) Das Abarbeiten einer gpx-Datei von ca. 11000 Funden hat recht lange gedauert (2h).
Kann man hier noch was beschleunigen?
[/quote]
Ich sehe aktuell kein Optimierungspotential im Algorithmus mehr. Was genau ist langsam? Die Abfrage gegen die Okapi?
[quote="mic@"]
c) Nun muss man bei jedem Doppellisting auf die oc-Zeile doppelklicken und
das Loggen bestätigen. Das dauert bei den über 400 gefundenen eine Weile.
Hier wäre es nett, wenn man entweder die sicheren Fälle (Algorithmus bei 90%)
automatisch loggen kann. Und weiterhin wäre es nicht schlecht, wenn es neben
dem "Return" auch ein "Next" gäbe, so daß man gleich im nächsten Doppellisting
landet. Wenn dann noch der Übertragungsbutton auf der gleichen Position liegt,
kann man viel schneller die Logs übertragen.
[/quote]
Automatisch möchte ich nicht. Das kann m.E. nach zu schnell schief gehen. Ein Next-Button wäre eine Überlegung - wobei der u.U. auch zum Durch hasten verleiten könnte...
[quote="mic@"]
d) Anscheinend gibt es ja keine Möglichkeit, die myfinds.gpx nur ab einem bestimmten
Datum erstellen zu lassen. Oder mit anderen Worten... diese Datei wird bei jedem
User mit der Zeit immer größer. Und damit das Handling vom cmanager immer
schwergängiger. Oder habe ich da was übersehen?
[/quote]
Das ist wohl leider korrekt. Da könnte man sich vielleicht mal bei der Plattform beschweren, der man Geld bezahlt
.[quote="mic@"]
e) Originalzitat "Nach ca. 300 logs ist das Programm abgestürzt. War nichts mehr zu sehen... hab
jetzt aus gemacht. Werde in ein zwei Wochen eh noch mal ne neue PQ durchjagen. Dann sollten
da nur noch so 150 angezeigt werden..."
Falls Du die gpx-Datei zu Testzwecken benötigst, dann kann ich versuchen,
sie auf ein Google Drive hochzuladen. Sie ist ca. 50MB groß.
[/quote]
Nach einem Neustart sollte der nächste Durchgang dank des lokalen Caches recht zügig gehen. (Relativ zum originalen Durchgang
). Ohne eine konkrete Beschreibung, bei welchem Klick (Beim Loggen welchen Caches?) es kracht, suche ich mich da vermutlich nur tot :|[quote="mic@"]
Ansonsten ein tolles Tool, daß um Welten besser ist als ocprop.
Dickes DANKE dafür!!!
[/quote]
Danke ebenso
-
following
Die OKAPI-Suchabfrage braucht nur noch wenige Millisekunden pro Cache; der cmanager braucht wesentlich länger. Finde ich aber auch gut so. Wenn die Abfragen in vollem OKAPI-Tempo reinkämen, hätten wir punktuell wieder Probleme mit der Systemlast. Und es würde dazu verleiten, den Abgleich öfter laufen zu lassen, was ebenfalls die die Last vervielfacht.Samsung1 hat geschrieben:Ich sehe aktuell kein Optimierungspotential im Algorithmus mehr. Was genau ist langsam? Die Abfrage gegen die Okapi?mic@ hat geschrieben: b) Das Abarbeiten einer gpx-Datei von ca. 11000 Funden hat recht lange gedauert (2h).
Kann man hier noch was beschleunigen?
Man kann die Datei kürzen, indem man sie sequenziell einliest und in eine neue Datei umkopiert, wobei alle Logs bis Datum X verworfen werden. Braucht kein volles XML-Parsing, da genügt ein simples Textparsing nach ein paar Tags.Das ist wohl leider korrekt. Da könnte man sich vielleicht mal bei der Plattform beschweren, der man Geld bezahltmic@ hat geschrieben: d) Anscheinend gibt es ja keine Möglichkeit, die myfinds.gpx nur ab einem bestimmten
Datum erstellen zu lassen. Oder mit anderen Worten... diese Datei wird bei jedem
User mit der Zeit immer größer. Und damit das Handling vom cmanager immer
schwergängiger. Oder habe ich da was übersehen?
Zuletzt geändert von following am 24.02.2016, 12:59, insgesamt 1-mal geändert.
-
Samsung1
[quote="following"]
[quote="Samsung1"]
[quote="mic@"]
b) Das Abarbeiten einer gpx-Datei von ca. 11000 Funden hat recht lange gedauert (2h).
Kann man hier noch was beschleunigen?
[/quote]
Ich sehe aktuell kein Optimierungspotential im Algorithmus mehr. Was genau ist langsam? Die Abfrage gegen die Okapi?
[/quote]
Die OKAPI-Suchabfrage braucht nur noch wenige Millisekunden pro Cache; der cmanager braucht wesentlich länger. Finde ich aber auch gut so. Wenn die Abfragen in vollem OKAPI-Tempo reinkämen, hätten wir punktuell wieder Probleme mit der Systemlast. Und es würde dazu verleiten, den Abgleich öfter laufen zu lassen, was ebenfalls die die Last vervielfacht.
[/quote]
Ja, also ich meinte den Prozess des Abgleichens mit der Okapi durch cmanager. Ich wollt damit nicht sagen, dass die Okapi an sich langsam ist. Alternativ ist das Laden der gpx ja auch ein ziemlicher Flaschenhals... Ich weiß jetzt nicht, an welcher Stelle der Schuh drückt
[quote="Samsung1"]
[quote="mic@"]
b) Das Abarbeiten einer gpx-Datei von ca. 11000 Funden hat recht lange gedauert (2h).
Kann man hier noch was beschleunigen?
[/quote]
Ich sehe aktuell kein Optimierungspotential im Algorithmus mehr. Was genau ist langsam? Die Abfrage gegen die Okapi?
[/quote]
Die OKAPI-Suchabfrage braucht nur noch wenige Millisekunden pro Cache; der cmanager braucht wesentlich länger. Finde ich aber auch gut so. Wenn die Abfragen in vollem OKAPI-Tempo reinkämen, hätten wir punktuell wieder Probleme mit der Systemlast. Und es würde dazu verleiten, den Abgleich öfter laufen zu lassen, was ebenfalls die die Last vervielfacht.
[/quote]
Ja, also ich meinte den Prozess des Abgleichens mit der Okapi durch cmanager. Ich wollt damit nicht sagen, dass die Okapi an sich langsam ist. Alternativ ist das Laden der gpx ja auch ein ziemlicher Flaschenhals... Ich weiß jetzt nicht, an welcher Stelle der Schuh drückt
[quote="Samsung1"]Das Problem ist leider (Java) systembedingt. Daher auch der Hinweis im Einstellungsfenster. Ohne Neustart des Programms geht es nicht.[/quote]
Moment... das Programm merkt nur beim Start, daß irgendwas mit der HeapSize falsch eingestellt ist?
Aber wenn ich es im laufenden Betrieb ändere, dann merkt es das nicht?!?
Klingt für mich etwas unlogisch... aber ich bin kein Java-Experte.
Aber falls dem wirklich so ist, dann wäre es wohl sinnvoll, daß JEDE Änderung der HeapSize
ein zwanghaftes Beenden des Programmes auslöst, damit man danach weiss, ob man überhaupt
mit dem neuen Wert arbeiten kann.
[quote="Samsung1"]Wie bereits oben geschrieben: 64bit VM installieren![/quote]
Danke für den Tiip, werde ich beim nächsten Mal berücksichtigen,
[quote="Samsung1"]Was genau ist langsam?[/quote]
Der Abgleich an sich.
Bei meiner Geocaching-Freundin hatte die gpx Datei mehr als 10000 Einträge.
Nach meinem Gefühl geschah der Abgleich im Sekundentakt und dauert ca. 2h.
Das fand ich etwas heftig, mein Wunsch wären ca. 10 Vergleiche pro Sekunde gewesen.
Dann wäre das Ganze dann in 12min gegessen gewesen.
[quote="Samsung1"]Automatisch möchte ich nicht.[/quote]
Also wenn alles grün ist (Cachename gleich, Koordinaten gleich, Owner gleich,
Verlinkung OC-->GC vorhanden), warum sollte dann der Owner noch sein OK geben?
[quote="Samsung1"]Ohne eine konkrete Beschreibung, bei welchem Klick (Beim Loggen welchen Caches?) es kracht, suche ich mich da vermutlich nur tot :| [/quote]
Ich vermute mal, daß war ein reines Speicherproblem und hat nichts mit dem zu untersuchenden
Listing zu tun. Und da der Absturz wohl nur bei einer extremen gpx-Datei auftrat (wer hat schon mehr
als 10000 Funde zusammen?), ist es nicht nötig, den Fehler zu lokalisieren. Vielleicht behebt schon
der Einsatz der 64bit VM das Problem...
Moment... das Programm merkt nur beim Start, daß irgendwas mit der HeapSize falsch eingestellt ist?
Aber wenn ich es im laufenden Betrieb ändere, dann merkt es das nicht?!?
Klingt für mich etwas unlogisch... aber ich bin kein Java-Experte.
Aber falls dem wirklich so ist, dann wäre es wohl sinnvoll, daß JEDE Änderung der HeapSize
ein zwanghaftes Beenden des Programmes auslöst, damit man danach weiss, ob man überhaupt
mit dem neuen Wert arbeiten kann.
[quote="Samsung1"]Wie bereits oben geschrieben: 64bit VM installieren![/quote]
Danke für den Tiip, werde ich beim nächsten Mal berücksichtigen,
[quote="Samsung1"]Was genau ist langsam?[/quote]
Der Abgleich an sich.
Bei meiner Geocaching-Freundin hatte die gpx Datei mehr als 10000 Einträge.
Nach meinem Gefühl geschah der Abgleich im Sekundentakt und dauert ca. 2h.
Das fand ich etwas heftig, mein Wunsch wären ca. 10 Vergleiche pro Sekunde gewesen.
Dann wäre das Ganze dann in 12min gegessen gewesen.
[quote="Samsung1"]Automatisch möchte ich nicht.[/quote]
Also wenn alles grün ist (Cachename gleich, Koordinaten gleich, Owner gleich,
Verlinkung OC-->GC vorhanden), warum sollte dann der Owner noch sein OK geben?
[quote="Samsung1"]Ohne eine konkrete Beschreibung, bei welchem Klick (Beim Loggen welchen Caches?) es kracht, suche ich mich da vermutlich nur tot :| [/quote]
Ich vermute mal, daß war ein reines Speicherproblem und hat nichts mit dem zu untersuchenden
Listing zu tun. Und da der Absturz wohl nur bei einer extremen gpx-Datei auftrat (wer hat schon mehr
als 10000 Funde zusammen?), ist es nicht nötig, den Fehler zu lokalisieren. Vielleicht behebt schon
der Einsatz der 64bit VM das Problem...
-
Samsung1
[quote="mic@"]
Moment... das Programm merkt nur beim Start, daß irgendwas mit der HeapSize falsch eingestellt ist?
Aber wenn ich es im laufenden Betrieb ändere, dann merkt es das nicht?!?
Klingt für mich etwas unlogisch... aber ich bin kein Java-Experte.
Aber falls dem wirklich so ist, dann wäre es wohl sinnvoll, daß JEDE Änderung der HeapSize
ein zwanghaftes Beenden des Programmes auslöst, damit man danach weiss, ob man überhaupt
mit dem neuen Wert arbeiten kann.
[/quote]
Korrekt. Man kann die Heapgröße nicht während des Betriebs ändern. (Ja, schön ist irgendwie anders). Daher Trick 17: cmanager starte sich am Anfang selber ein zweites mal mit dem vom Benutzer definierten Heap.
Ein zwangsmäßiges Beenden wäre wohl sinnvoll. War ich in der Vergangenheit zu faul zu und dachte, der Hinweis in den Einstellungen tut es auch
. Ist dann jetzt auf der Todo.
[quote="mic@"]
[quote="Samsung1"]Was genau ist langsam?[/quote]
Der Abgleich an sich.
Bei meiner Geocaching-Freundin hatte die gpx Datei mehr als 10000 Einträge.
Nach meinem Gefühl geschah der Abgleich im Sekundentakt und dauert ca. 2h.
Das fand ich etwas heftig, mein Wunsch wären ca. 10 Vergleiche pro Sekunde gewesen.
Dann wäre das Ganze dann in 12min gegessen gewesen.
[/quote]
Okay. Vielleicht lässt sich da noch was mit parallelen Anfragen machen. Bremse ist vermutlich die Netzwerkseite Verzögerung, da für jeden Cache neue Verbindungen aufgebaut werden.
[quote="mic@"]
[quote="Samsung1"]Automatisch möchte ich nicht.[/quote]
Also wenn alles grün ist (Cachename gleich, Koordinaten gleich, Owner gleich,
Verlinkung OC-->GC vorhanden), warum sollte dann der Owner noch sein OK geben?
[/quote]
Jo. Und dann ist mir ein Fehler im Programm durch gerutscht und es werden mal eben mit einem Klick 300 falsche Logs in die DB geblasen, die sich vermutlich nicht ohne Schmerzen zurückrudern lassen - wenn sie denn überhaupt sofort als falsch auffallen. Die Verantwortung würde ich gerne schön bei jedem selbst belassen.
Moment... das Programm merkt nur beim Start, daß irgendwas mit der HeapSize falsch eingestellt ist?
Aber wenn ich es im laufenden Betrieb ändere, dann merkt es das nicht?!?
Klingt für mich etwas unlogisch... aber ich bin kein Java-Experte.
Aber falls dem wirklich so ist, dann wäre es wohl sinnvoll, daß JEDE Änderung der HeapSize
ein zwanghaftes Beenden des Programmes auslöst, damit man danach weiss, ob man überhaupt
mit dem neuen Wert arbeiten kann.
[/quote]
Korrekt. Man kann die Heapgröße nicht während des Betriebs ändern. (Ja, schön ist irgendwie anders
). Daher Trick 17: cmanager starte sich am Anfang selber ein zweites mal mit dem vom Benutzer definierten Heap.Ein zwangsmäßiges Beenden wäre wohl sinnvoll. War ich in der Vergangenheit zu faul zu und dachte, der Hinweis in den Einstellungen tut es auch
. Ist dann jetzt auf der Todo.[quote="mic@"]
[quote="Samsung1"]Was genau ist langsam?[/quote]
Der Abgleich an sich.
Bei meiner Geocaching-Freundin hatte die gpx Datei mehr als 10000 Einträge.
Nach meinem Gefühl geschah der Abgleich im Sekundentakt und dauert ca. 2h.
Das fand ich etwas heftig, mein Wunsch wären ca. 10 Vergleiche pro Sekunde gewesen.
Dann wäre das Ganze dann in 12min gegessen gewesen.
[/quote]
Okay. Vielleicht lässt sich da noch was mit parallelen Anfragen machen. Bremse ist vermutlich die Netzwerkseite Verzögerung, da für jeden Cache neue Verbindungen aufgebaut werden.
[quote="mic@"]
[quote="Samsung1"]Automatisch möchte ich nicht.[/quote]
Also wenn alles grün ist (Cachename gleich, Koordinaten gleich, Owner gleich,
Verlinkung OC-->GC vorhanden), warum sollte dann der Owner noch sein OK geben?
[/quote]
Jo. Und dann ist mir ein Fehler im Programm durch gerutscht und es werden mal eben mit einem Klick 300 falsche Logs in die DB geblasen, die sich vermutlich nicht ohne Schmerzen zurückrudern lassen - wenn sie denn überhaupt sofort als falsch auffallen. Die Verantwortung würde ich gerne schön bei jedem selbst belassen.
-
Samsung1
Generell, was Bugs und Featurewünsche angeht, dürft ihr die auch sehr gerne hier einstellen: https://github.com/RoffelKartoffel/cmanager/issues . Dort gehen sie auf jeden Fall nicht "verloren"
-
Samsung1
Ein kurzes Update: Aktuell ist jetzt Version 0.2.27 . Änderungen, die eingeflossen sind, sind unter anderem:
- Speicherbedarf beim Laden reduziert
- Liste der Cache lässt sich nach Funddatum sortieren. Bei Bedarf lassen sich hier Cache vor einem Abgleich löschen.
- Abgleich von bis zu 10 Cachen parallel. Bitte Bescheid geben, falls die Datenbank das nicht mag
Wow, die Version 0.2.27 fliegt ja richtig, da muss man sich ja fast schon anschnallen.
Trotzdem noch einige Hinweise:
a) Warum zippst Du den cmanager? Die Ersparnis des jar-Files zum zip waren nur wenige Bytes.
b) Wenn man aus der Liste der Kandidaten ein oc-Listing anklickt und das Log erstellen läßt,
dann merkt sich das der cmanager nicht. Man könnte also nach Return wieder (versehentlich)
auf dasselbe oc-Listing klicken, und es wird wieder eine Logübertragung angeboten.
c) Mein Vorschlag, nach Logübertragung gleich den nächsten Kandidaten vorgesetzt zu bekommen,
wurde leider noch nicht umgesetzt. Das würde einen möglichen Fehler (siehe b) verhindern helfen.
d) Wenn Dir die Buchstaben ausgehen, dann beginne doch einen 0.3.a statt 0.2.27
Danke für Deine Arbeit, Mic@
Trotzdem noch einige Hinweise:
a) Warum zippst Du den cmanager? Die Ersparnis des jar-Files zum zip waren nur wenige Bytes.
b) Wenn man aus der Liste der Kandidaten ein oc-Listing anklickt und das Log erstellen läßt,
dann merkt sich das der cmanager nicht. Man könnte also nach Return wieder (versehentlich)
auf dasselbe oc-Listing klicken, und es wird wieder eine Logübertragung angeboten.
c) Mein Vorschlag, nach Logübertragung gleich den nächsten Kandidaten vorgesetzt zu bekommen,
wurde leider noch nicht umgesetzt. Das würde einen möglichen Fehler (siehe b) verhindern helfen.
d) Wenn Dir die Buchstaben ausgehen, dann beginne doch einen 0.3.a statt 0.2.27
Danke für Deine Arbeit, Mic@