ocprop.pl findet zuviele OC-Only-Caches

[Pegasus37]

Für den Cache OCFB30 Der Lewitz-Radrundweg habe ich mehrere Stationen als Wegpunkte angelegt. Ocprop ist nun der Meinung, dass jeder einzelne Wegpunkt ein neuer Cache ist und legt im Ordner hidden die Caches UNKNOWN-OCFB30-01, ...-02 usw. an.
Bisher behelfe ich mir mit dem manuellen Löschen der entsprechenden Ordner, aber vielleicht kann einer der Entwickler sich das Problem mal ansehen.
Danke.

[Schrottie]

Dieses Problem habe ich seit Februar: http://forum.geoclub.de/viewtopic.php?p ... 4#p1072904

[Megachip]

Kommt mir bekannt vor

Code: Alles auswählen

Habe einen neuen OC-only Cache gefunden: UNKNOWN (OCDE5C-1).

Ein Fehler ist aufgetreten: Undefined subroutine &main::ERROR called at script/ocprop.pl line 4144.

Das trifft dann wohl auch auf folgende Topics zu:
http://forum.geoclub.de/viewtopic.php?f=103&t=70060

[Megachip]

gibt es hier keine edit Funktion?
http://forum.geoclub.de/viewtopic.php?f=103&t=69327

[Pegasus37]

Für das erste Problem ist ja schon eine Lösung angegeben:
Bekanntmachen der ERROR-Funktion aus dem Log-Modul

Code: Alles auswählen

use Log::Log4perl qw(:easy);

Zusammen mit den anderen hier angebotenen Lösungen habe ich das Aufrufscript um die entsprechenden Hinweise ergänzt und nun läuft es wieder.

Code: Alles auswählen

#!/bin/bash
GEOLOGDIR=~/geolog
LOG=$GEOLOGDIR/cronjob.log
./geolog.pl -bs >> $LOG 2>&1
./ocprop.pl -b >> $LOG 2>&1
rm -r ./hidden/UNKNOWN_OCFB30*
rm ./hidden/*/logbook.json
./geolog.pl -cg >> $LOG 2>&1

Das Ganze hilft zwar nicht bei der Exe-Version, aber dafür gibt es wohl im Moment noch keine Lösung.

[Megachip]

Die Dateierweiterung pl ist nicht erlaubt.

Anbei mein Workaround:

Das Skript prüft nun, ob es sich bei dem Wegpunkt um einen "Waypoint" handelt und ignoriert ihn dann.

Bitte Testen. Die exe konnte ich leider wgn fehlender Module nicht bauen

[geomitast]

Das Thema besteht nun schon seit 2006...

Ich habe aktuell mit der ocprop.pl (2.21) unter Windows das selbe Problem.
Ich vermute, dass ich auf die Frage soll der Cache in OC (OC10A9F) bearbeitet werden mit "nein" falsch beantwortet habe. Ich habe das Listing nach dem Hochladen erneut in OC bearbeitet und gesichert. Nun findet eine ocprop einen OConly-Cache UNKNOWN-OC10A9F-1.
Durch Löschen des Ordners unter "hidden" ist er weg, aber das nervt auf Dauer ;-)

Vielleicht kennt ja jemand eine dauerhafte Lösung.

Ach ja! Ich habe das Listing um 3 Wegpunkte ergänzt.

[geomitast]

Ich habe nun noch etwas rumgetestet.
Der Fehler liegt zu 100% an den zusätzlichen Wegpunkten in OC.
Ich habe die "Zusätzlichen Wegpunkte" wieder rausgenommen und das ocprop-Script läuft wieder fehlerfrei!

Die Wegpunkte habe ich an die Beschreibung angefügt.

Vielleicht kann man ja diesen Bug in zukünftigen Versionen beheben und Wegpunkte werden ignoriert.

[Pegasus37]

Ich habe dazu folgenden Workaround in den cronjob eigebaut:

Code: Alles auswählen

#!/bin/bash
GEOLOGDIR=/home/www/geolog
LOG=~/cronjob.log
cd $GEOLOGDIR
./geolog.pl -bs >> $LOG 2>&1
./ocprop.pl -b >> $LOG 2>&1
rm -r ./hidden/UNKNOWN*
rm ./hidden/*/logbook.json
./geolog.pl -cq >> $LOG 2>&1

geolog wird zuerst aufgerufen, um die aktuellen Funde abzugleichen, dann startet ocprop und lädt die dazugehörigen OC-Caches herunter. Da ich auch einen Cache mit mehreren Unterpunkten habe, kommen die UNKNOWN-Einträge an, werden aber sofort wieder gelöscht. Zusätzlich werden die Cookies gelöscht, da die auch zu Problemen geführt haben. Zum Schluss läuft noch mal geolog, aktualisiert die Statistik und lädt sie auf den Server hoch.

HTH
P37

[geomitast]

@Pegasus37
Wie funktioniert der Workaround genau für die .pl-Version unter Windows???

Vielen Dank
geomitast