Filter suchbar & Letzte Aktualisierung

ich finde es etwas verwirrend, dass bei der filterauswahl suchbar auch archivierte caches auftauchen. gefühlsmässig ist da entweder der begriff oder der filter falsch.

bei der letzten aktualisierung via pq wird der zeitstempel von seattle eingetragen. bei der letzten aktualisiserung via spider die lokale zeit.

beim einlesen einer pq wird immer der zeitstempel der pq eingetragen auch wenn sich an den daten nichts geändert hat. das ist vor allem beim einlesen der myfinds pq recht lästig, da anschliessend alle wegpunkte nicht nur einen neuen last modified timestamp haben, sondern auch tatsächlich einen anderen inhalt (den timestamp). das bringt bei mir eine menge unnötiger "syncronisationen" zwischen der lokalen platte und dem pocketpc.

Das dumme ist an dieser Stelle, dass die Ewe-Datumsroutinenen wohl nicht in der Lage sind, Zeitzoneninformationen zu verarbeiten. Zumindest hat das bei mir nie funktioniert.
Müsste man also manuell machen, was dann bedeuten würde, dass man irgendwo noch die eigene Zeitzone hinterlegen müsste... Oder hat jemand ne bessere Idee?

Gruß,
E.

greiol schrieb:

ich finde es etwas verwirrend, dass bei der filterauswahl suchbar auch archivierte caches auftauchen. gefühlsmässig ist da entweder der begriff oder der filter falsch.

Zum Vergrößern anklicken....

Hier geht es um deaktivierte Caches. Hier kann man die Übersetzung gerne anpassen.

greiol schrieb:

beim einlesen einer pq wird immer der zeitstempel der pq eingetragen auch wenn sich an den daten nichts geändert hat.

Zum Vergrößern anklicken....

Hier geht es ja auch um das letzte Aktualisierungsdatum und nicht um die letzte Änderung. Dies soll dazu dienen, dass man erkennt, welche Caches schon länger nicht aktualisiert wurden, so dass man danach auswählen kann, welche man mal wieder aktualisieren sollte.

MiK schrieb:

greiol schrieb:

beim einlesen einer pq wird immer der zeitstempel der pq eingetragen auch wenn sich an den daten nichts geändert hat.

Zum Vergrößern anklicken....

Hier geht es ja auch um das letzte Aktualisierungsdatum und nicht um die letzte Änderung. Dies soll dazu dienen, dass man erkennt, welche Caches schon länger nicht aktualisiert wurden, so dass man danach auswählen kann, welche man mal wieder aktualisieren sollte.

Zum Vergrößern anklicken....

mir ist klar worum es geht, aber es sorgt halt auch dafür dass die seit jahren archivierten events jedesmal wegen des neuen zeitstempels durch die gegend kopiert werden obwohl sich nichts daran geändert hat. im moment ändern sich damit bei mir jede woche 2500+ dateien die alle erst mal syncronisiert sein wollen. und da der alte pda keine sdhc karten mag, ist das eine recht zeitraubende und in dem fall auch zumeist völlig überflüssige geschichte.

mir persönlich wäre es deutlich lieber wenn der zeitstempel nur gesetzt würde wenn sich auch wirklich etwas am cache gtan hat (status, beschreibung oder logs geändert). so erkennt man auch, wenn sich bei einem cache über wochen oder monate nichts tut und sinnlose sync aktionen bleiben aus.

Das ist aber so für die Spider-Nutzung nicht sinnvoll. Wenn das bei PQ-Nutzung stört, dann setzen wir besser beim PQ-Import gar keinen Zeitstempel. Bei PQ-Nutzung, wird ja sowieso immer "alles" aktualisiert und das Datum ist nicht so hilfreich.

MiK schrieb:

Das ist aber so für die Spider-Nutzung nicht sinnvoll. Wenn das bei PQ-Nutzung stört, dann setzen wir besser beim PQ-Import gar keinen Zeitstempel. Bei PQ-Nutzung, wird ja sowieso immer "alles" aktualisiert und das Datum ist nicht so hilfreich.

Zum Vergrößern anklicken....

wir können das bei spider und gpx import durchaus unterschiedlich handhaben, aber wir müssen es nicht direkt ganz rauswerfen, da auch bei einer normalen pq die archivierten ja nicht mit drin sind (die my finds ist ein spezialfall). ein update nur bei änderungen scheint mir jedoch durchaus begrüssenswert. und wenn hierzulande ein cache wochenlang keine updates bekommt ohne deaktiviert oder archiviert zu werden, ist er ohnehin eine gesonderte betrachtung wert, weil vermutlich mal wieder "vergessen" wurde die dnfs zu loggen.

Ich finde wir sollten in einem Datenfeld nicht unterschiedliche Sachen speichern, je nachdem, wie die Daten in CW kommen. Falls wir die letzte Änderung auch noch aufgenommen werden soll, dann sollten wir dem ein eigenes Datenfeld spendieren.

MiK schrieb:

IFalls wir die letzte Änderung auch noch aufgenommen werden soll, dann sollten wir dem ein eigenes Datenfeld spendieren.

Zum Vergrößern anklicken....

...was ja das hier angesprochene Problem nicht löst, dass sich haufenweise Dateien ändern, nur weil sich ein Timestamp unnötigerweise geändert hat.

Gruß,
E.

Natürlich war das in Zusammenhang mit dem Vorschlag bei PQs Aktualisierungsdatum nicht zu setzen gemeint.

Dann versteht ich entweder die eine oder die andere Seite nicht... Ich habe das Problem jetzt so verstanden: Wenn ich über eine PQ 500 Caches aktualisiere, aber inhaltliche Datenänderungen gibt es nur bei 15 davon, so will die Synchronisation anschließend dennoch alle 500 aktualisieren, weil sich dort eben das Aktualisierungsdatum geändert hat. Das Problem bleibt doch bestehen, auch wenn man jetzt ein weiteres Feld einführt...

Was mich grad wundert: Gab das denn vor der Änderung, die das Aktualisierungsdatum setzt, keine Probleme? Dann müsste der Cache ja schon mitbekommen haben, ob er sich geändert hat oder nicht und nur im Änderungsfall die Datei neu geschrieben haben. Wenn das der Fall ist, könnte man dieses Verhalten ja nutzen, um das Aktualisierungsdatum nur im Änderungsfall neu zu schreiben. Damit wäre das Import-Verhalten für PQs sowas wie "Import ignorieren wenn keine Daten geändert".

Gruß,
E.

Wir haben das Datenfeld, in der die letzte Aktualisierung gespeichert wird. Beim Spider-Betrieb ist das so sinnvoll, da immer nur eine kleine Zahl an Caches automatisch aktualisiert wird. Oder man aktualisiert eine Handvoll von Hand. So hat man einen Überblick über die Caches, die man mal wieder aktualisieren sollte.

Beim PQ-Import werden aber immer alle Caches auf den aktuellen Stand gebracht. Da dadurch alle Caches geändert werden, ist dies sehr ungünstig, wenn man ein Synchronisierungstool benutzt. Deswegen wäre es evtl. besser, wenn beim PQ-Import das Aktualisierungsdatum nicht gesetzt wird.

Wenn die PQ-Nutzer darüber hinaus ein Interesse daran haben, dass wir das Datum der letzten Änderung speichern, brauchen wir dafür ein neues DAtenfeld. Das hat mit obiger Problematik aber direkt erst mal nichts zu tun.

Ich fände es ausgesprochen ungünstig, wenn das Datum der letzten Aktualisierung beim PQ-Import nicht mehr gespeichert würde.
Dieses Datum kann nämlich sehr gut dazu verwendet werden, um innerhalb eines regelmäßig per PQ aktualisierten Profils archivierte Caches auszusortieren.

Gegenvorschlag: Das Datum der letzten Aktualisierung lediglich in der Index.xml speichern und die Cache.xml unberührt lassen, falls sich inhaltlich nichts geändert hat.

Daran hatte ich auch schon gedacht. Allerdings kopieren wir die Zeile aus der index.xml zur Zeit in die cache.xml, um den Index neu aufbauen zu können. Aber vielleicht sollten wir da für diesen Wert eine Ausnahme machen.

Die Ausnahme in diesem Fall dürfte nicht allzu schmerzlich sein...
Wenn man den Index neu erstellen muss sind die korrekten Werte dieser Spalte nach dem Ersten Aktualisieren/PQ einlesen sowieso wieder vorhanden.