search

2Abendsegler / GClh

GC little helper II - Some little things to make life easy (on www.geocaching.com). Powerful, configurable tool to improve and expand the geocaching pages.
GNU General Public License v2.0
60 stars 38 forks source link

Autovisit TBs stopped working? #1288

Closed MagpieFourtyTwo closed 3 years ago

MagpieFourtyTwo commented 4 years ago

Describe the bug Always had to activate "Autovisit" just once, and then it stayed as it is, but since the latest update it is not persistent anymore, although I activate it again and again on every new log.

To Reproduce

  1. Open a new log
  2. Activate "[X] Autovisit" on any (over here: all) TBs
  3. Post log
  4. Open next log
  5. Check "[X] Autovisit" state

Expected behavior "[X] Autovisit" should be activated, but it is not.

Desktop:

Additional context Checked manual export of GClh settings, too, and "autovisit" seems to be active for my TBs - nevertheless the GUI option is not activated in the log. BTW; There are still a lot of obviously outdated "autovisit" entries (true and false) in the settings. Can these hassle-free be removed? And if so, why does GClh still keep them, although the corresponding TBs have been dropped a long time ago and are not in my inventory anymore ...?

2Abendsegler commented 4 years ago

Moin,

ich kann das Problem im Moment nicht nachstellen. Wenn ich das Autovisit Kennzeichen im alten Log Formular aktiviere, ist es beim nächsten Aufruf des Log Formulars automatisch aktiviert und "Action" steht auf "Visited", sofern es sich um einen relevanten Log Status handelt, wie beispielsweise "Found it".

In Version 0.10.3 hatte die Autovisit Funktionalität nicht mehr funktioniert. Ich habe mit Issue #1205 repariert. Womöglich hat es nur bei mir nicht funktioniert, bei anderen aber durchaus. Ich weiß auch nicht.

Bitte deaktiviere mal alle anderen Scripte und alle Add-ons bis auf Tampermonkey und versuch es nochmal. Vielleicht kannst du dann gegebenenfalls auch versuchen herauszufinden, womit der GClh im Konflikt ist. Dann können wir gezielt nachsehen.

MagpieFourtyTwo commented 4 years ago

Hmm, bei mir hat es zwischenzeitlich genau ein Mal funktioniert - und danach wieder nicht mehr. Leider habe ich jetzt keine neuen Logs mehr zum Testen. Daher die Frage: Könnte es sein, dass es einen Unterschied macht, ob man über [Log geocache] im Listing oder [Compose Log] bei den Drafts (aka Field Notes) kommt? Letzteres ist mein normaler Weg und auf dem tut es (gerade wieder) nicht ...

Abgesehen davon habe ich, um die als Fehlerquelle auszuschliessen, noch ein paar Versuche unternommen, die "autovisit" Einträge los zu werden - es aber nicht geschafft. Egal was ich mache, die kommen immer wieder. Wo holt GClh die immer wieder her? staun

Meine "Aufräumversuche":

  1. GClh Config II => Reset => "[X] Reset dynamic and unused data" Ergebnis: Nach Klick auf [reset] läuft der Spinner los, macht eine Viertelumdrehung und bleibt stehen. Firefox bleibt augenscheinlich stehen und muss per Taskmanager beendet werden.
  2. GClh Config II => Reset => "[X] Reset to standard configuration" Ergebnis: Nach Klick auf [reset] läuft der Spinner los ... für ewig ... Nach Klick auf [close] (bei immer noch laufendem Spinner) ist die Config immer noch vorhanden
  3. Tampermonkey => "Dashboard" => "GC little helper II" => [Edit] => "Storage" Config-Zeile auf "CONFIG": "{}" geändert => [Save] ... jetzt war zumindest die Config endlich mal weg Testweise noch mal 1. probiert: Geht nun, mit Meldung "nothing to change" (oder so) Testweise noch mal 2. probiert: Bleibt immer noch hängen und FF muss abgeschossen werden

Danach habe ich dann eine von Hand "gesäuberte" Config manuell importiert ... und schwubbs waren die autovisits (ca. 150 Stück) wieder da. Ausserdem kreiselt der Spinner bei 1. wieder ewig und bei 2. bleibt FF immer noch stehen ...

Das alles übrigens mit GClh II als einzigem in Tampermonkey aktivem Script.

MagpieFourtyTwo commented 4 years ago

Gerade noch mal alle anderen AddOns deaktiviert ... kein Unterschied bzgl. 1. und 2. Autovosit kann ich dann morgen noch mal testen, wenn der nächste Log kommt. ;)

2Abendsegler commented 4 years ago

@MagpieFourtyTwo

Vermutlich kannst du keine Autovisits mehr speichern. Es sieht dann so aus, als ob das Log Formular die Daten nicht korrekt aufbereitet. Faktisch ist ein Autovisit aber gar nicht gesetzt.

Die Autovisits und die defekte Reset Funktionalität könnten darauf hindeuten, dass in deiner Konfiguration korrupte Daten enthalten sind. Ich möchte mir das gerne ansehen.

Kannst du bitte deine Homekoordinaten direkt im GClh abändern und speichern. Bitte ändere sonst nichts. Kannst du bitte anschließend deine GClh Konfiguration manuell exportieren und in eine .txt Datei packen, sofern beim Speichern der Datei keine Meldungen auftauchen. Schick mir bitte die Datei an meine Mailbox. Falls du die Adresse nicht hast, gib bescheid, ich schick sie dir dann.

LG

2Abendsegler commented 4 years ago

@MagpieFourtyTwo Änderung: Kannst du bitte deine Homekoordinaten direkt im GClh abändern und speichern. Bitte ändere sonst nichts. Kannst du bitte anschließend deine GClh Konfiguration über Tampermonkey aus dem "Speicher" kopieren und in eine .txt Datei packen, sofern beim Speichern der Datei keine Meldungen auftauchen.

MagpieFourtyTwo commented 4 years ago

Gerne - auch wenn ich nicht wirklich glaube, dass es an der Config liegt, weil das [reset] ja auch mit (von Hand) gelöschter Config nicht ging ... nun denn, ich bin gespannt. ;)

Arnos99 commented 4 years ago

Bei mir tritt das gleich Problem auf. Ich kann es nicht 100% sagen, aber gefühlt seit dem Update auf GClh 0.10.4 Nun hab ich mal alle möglichen Dinge probiert und muß feststellen, dass es bei mir der Eintrag von cookiebot.com, im Add-on uBlock Origin ist. Wenn ich diesen Filter entferne, funktioniert die Autovisit Funktion wieder. Mit Filter wird die Einstellung aus dem Speicher von Tampermonkey ( \"autovisit_12345\":true,\"autovisit_67890\":true,), nicht ins Log-Formular übergeben. Keine schöne Lösung für mich, würde den Filter gerne behalten.

Win10 64-Bit Firefox 73.0.1 (64-Bit) GC little helper II (v0.10.4)

2Abendsegler commented 4 years ago

@Arnos99 @MagpieFourtyTwo Danke euch Beiden für die Fehlermeldung.

Ich werde euch die Vorgängerversion zum Testen aufbereiten.

@Arnos99 Klar, der Eintrag von cookiebot.com soll weiter funktionieren. Das werden wir wohl auch hinbekommen. 😀

Den Fehler konnte ich auch bereits nachvollziehen, ganz selten werden bei mir die Autovisits nicht gesetzt, wenn cookiebot.com gesetzt ist.

@MagpieFourtyTwo Danke für die Config!

Ich habe gerade die Resetfunktionalität überarbeitet, so dass sie schneller läuft, das war nämlich das Problem bei "Reset dynamic and unused data". Mit jedem weiteren Config Eintrag gings langsamer voran. Nichts weiter. Beruhigt mich sehr! 😅

Die zweite Sache mit "Reset to standard configuration" lief auf einen Fehler weil die Datei mit der Standard Konfiguration nicht ordnungsgemäß gelesen und aufbereitet werden konnte. Es waren fehlerhafte Einträge in der Datei. (Anstatt " wurden teils ' verwendet.)

Und nun noch ein paar Antworten, um die Falten auf deiner Stirn zu beseitigen. 😁

Can these hassle-free be removed? And if so, why does GClh still keep them, although the corresponding TBs have been dropped a long time ago and are not in my inventory anymore ...?

Eine solche Funktionalität ist einfach nicht entwickelt. Eigentlich sollten 1000 Autovisit Flags auch nicht weiter stören. Mit der Reset Funktionalität "Reset dynamic and unused data" kann man aber alle nicht mehr verwendeten Daten entfernen.

Ich möchte die Autovisits nicht automatisch entfernen, sobald sie aus dem Inventar entfernt sind, weil damit auch die Tracking-Codes verloren gehen. Klar, normalerweise benötigt man sie nicht mehr, es sei denn jemand konnte es nicht abwarten den Trackable zu loggen bevor man ihn selbst eingeloggt hat. Mit den vorhandenen Autovisit Daten kann man ihn sich wieder nehmen, erklären was abgegangen ist und ihn ordnungsgemäß im Cache einloggen.

Grundsätzliches zum Import: Beim Import werden nur die importierten Parameter neu gesetzt. Parameter die nicht importiert werden bleiben auf ihrem alten Wert. Die Autovisit Kennzeichen gehören zu den tempörären Daten, die auch dann nicht entfernt werden, wenn du auf die Standard Konfiguration gehst. Soweit ist also alles in Ordnung.

Deinen Fehler konnte ich bisher nicht reproduzieren.

2Abendsegler commented 4 years ago

Hier könnt ihr temporär zu diesem Thema die Vorgängerversion v0.10.3 installieren. Hier kommt ihr wieder zurück auf v0.10.4.

2Abendsegler commented 4 years ago

Könnt ihr bitte mal testen ob der Fehler damit noch besteht?

Arnos99 commented 4 years ago

v0.10.3 installiert und Problem gelöst. Auch mit blockierten Cookiebot, läuft die Autovisit Funktion. Lieben Dank für die schnelle Reaktion. :-)

2Abendsegler commented 4 years ago

... bei mir funktioniert es aber nicht mit dieser Version. Dubios!

MagpieFourtyTwo commented 4 years ago

Ich möchte die Autovisits nicht automatisch entfernen, sobald sie aus dem Inventar entfernt sind, weil damit auch die Tracking-Codes verloren gehen

Ich war halt verwirrt, dass sie selbst nach einem Reset plötzlich wieder da waren ... das liess den Glauben an ein wirklich durchgeführtes Reset deutlich bröckeln.

Aber, ja, den Ansatz finde ich gut. Wobei es dann natürlich sinnvoll wäre, wenn das a) dokumentiert und b) vielleicht sogar per UI einsehbar sowie c) die TB-Codes in zeitlicher Reihenfolge sortiert wären und/oder ihr Eintrag auch den letzten "Buchungstag" enthalten würde, sonst könnte die Suche schon mal etwas mühsam werden ... ;)

... bei mir funktioniert es aber nicht mit dieser Version.

Bei mir auch nicht. Also, zumindest nicht, solange uBlock cookiebot.com blockt. Gebe ich das frei *gääähn* ;) funktioniert es in beiden Versionen. Blocke ich es wieder, geht's wieder nicht, ebenfalls in beiden. Also, jetzt im Moment zumindest nicht ... das scheint nicht deterministisch zu sein: am WE hatte ich beim Loggen (mit 0.10.4) plötzlich den Fall, dass bei einem Cache die [X]e wieder alle gesetzt waren und die TBs von alleine auf "Visit" standen. Da dachte ich schon an Selbstheilung. Aber das Vergnügen war von kurzer Dauer, beim nächsten war's schon wieder weg.

2Abendsegler commented 4 years ago

Aber, ja, den Ansatz finde ich gut. Wobei es dann natürlich sinnvoll wäre, wenn das a) dokumentiert und b) vielleicht sogar per UI einsehbar sowie c) die TB-Codes in zeitlicher Reihenfolge sortiert wären und/oder ihr Eintrag auch den letzten "Buchungstag" enthalten würde, sonst könnte die Suche schon mal etwas mühsam werden ... ;)

Alles gute Ideen, ja. Für die seltenen Fälle, dass man den Tracking Code nochmal benötigt aber vermutlich zu viel Aufwand. Wenn der Trackable Code zusammen mit dem Tracking Code gespeichert werden würde, ist natürlich auch eine Automatik denkbar.

Die Tracking Codes sind heute quasi in der Reihenfolge des Setzens des Autovisit Kennzeichens sortiert. Wenn ich also zu einem gerade abgelegten Trackable den passenden Tracking Code suche, so wie in meinem Beispiel, dann steht er ziemlich weit unten.

Vermutlich müssen wir in der Autovisit Funktionalität einiges umstellen um es wieder sauber und verlässlich zu machen. Das hängt wohl hauptsächlich mit der mittlerweile auch hier eingezogenen asynchronen Verarbeitung zusammen.

Vielleicht bekommen wir es dann auch im neuen Log Formular ans Laufen. Hatten wir schon mal erfolglos versucht. Mittlerweile sind wir aber etwas schlauer was die asynchrone Verarbeitung angeht.

Workaround für dich könnte sein, das Log Formular hinten generisch aus dem uBlock Origin auszuklammern. Also "Whitelist" Eintrag mit "geocaching.com/seek/log.aspx*".

Arnos99 commented 4 years ago

Merkwürdig ist es schon, dasss es bei Euch nicht funktioniert. Ich habe gerade noch ein paar Caches geloggt und Autovisit der TBs funktioniert einwandfrei. In meiner Whitelist ist kein Eintrag der Geocaching.com betrifft.

2Abendsegler commented 4 years ago

Ja, das ist es, aber es ist nicht der erste Fall. Vermutlich hängt es mit der asynchonen Verarbeitung zusammen. Je nachdem welche Scripte oder Add-ons noch verarbeitet werden müssen kommt der GClh früher oder später zum Zuge. Und GS liefert die Daten ja auch nicht immer identisch. Ganz selten geht es auch bei mir. Und bei MagpieFourtyTwo gingst ja auch mal.

MagpieFourtyTwo commented 4 years ago

Workaround für dich könnte sein, das Log Formular hinten generisch aus dem uBlock Origin auszuklammern. Also "Whitelist" Eintrag mit "geocaching.com/seek/log.aspx*".

Jupp, scheint zu tun. Werde es weiter beobachten. Danke!

Arnos99 commented 4 years ago

Ich hab gerade mal geschaut, der GClh wird bei mir als erstes Script ausgeführt, danach erst die anderen. Falls es hilft.

MagpieFourtyTwo commented 4 years ago

Bei mir auch. Mehr noch: Für die Tests hatte ich die anderen zudem deaktiviert.

2Abendsegler commented 4 years ago

Build back to v0.10.3.

    <li>
        <strong>Fix:</strong> [Workaround] Autovisit TBs stopped working. [<a href="https://github.com/2Abendsegler/GClh/issues/1288" title="Issue 1288">1288</a> / <a href="https://www.geocaching.com/profile/?u=2Abendsegler" title="Thanks to 2Abendsegler">2Abendsegler</a>]<br>
        <img src="../images/0.10.5/Screen08.jpg" alt="Screen08.jpg"><br>
        Workaround when using uBlock Origin: Exclude the old log form with an entry of the whitelist of uBlock Origin.<br>
        <img src="../images/0.10.5/Screen09.jpg" alt="Screen09.jpg"><br><br>
    </li>

Screen08

Screen09

MagpieFourtyTwo commented 4 years ago

I'm afraid I have to reopen the issue ... although it did work this afternoon, after applying the described Whitelist entry, it again does not right now. In the very same FF, of course. :/

Perhaps this latest observation may help a bit to find the real reason fo failure: So, Autovisit fails, no matter if ... a) other scripts are active or not b) cookiebot is allowed or not and even if c) uBlock is active or completely disabled. In any case Autovisit's X'es stays away until - and that's new for me - until I press F5: After the page has reloaded, everything is perfectly fine. In any constellation of a) to c).

But now for the strangest part: The absolute same applies to \F5 ... And this is the moment, I'm completely out. Have no clue at all ... *örgs*

MagpieFourtyTwo commented 4 years ago

Verd... wieder verpeilt, dass man hier ja deutsch spricht - sorry. ;)

2Abendsegler commented 4 years ago

Danke für die Info.

it again does not right now

Ja, das ist das Dilemma. Mal geht es, mal geht es nicht. Bei mir ging es ja die ganze Zeit schon nicht, bzw. ich kann zusehen wie visited gesetzt wird und dann wieder verschwindet.

Wenn sich das Aktualisieren der Seite anders verhält als das erste Laden der Seite, dann ist das ein weiteres gutes Indiz dafür, dass wir uns in einem asynchronen Umfeld befinden. Das Einzige was hilft ist asynchron mitzuspielen. Das Bedarf aber etwas mehr Aufwand. Dafür habe ich bereits Issue #1301 aufgemacht. Damit kann man sich ein paar Tage beschäftigen. 😮

Man kann im Moment die v0.10.3 (nur fürs Autovisit Thema auf dieser Version) oder die v0.10.4 verwenden. Für die beiden Versionen kann man den Blocker mit und ohne Log Formular auf der Whitelist versuchen, man kann mit F5 arbeiten (funktioniert bei mir mit v.0.10.4) oder man kann den Logstatus von Found auf DNF und wieder zurück ändern, was immer funktionieren sollte.

Mehr hab ich im Moment nicht anzubieten. 😓

2Abendsegler commented 4 years ago

Scheinbar wurden auch aktuell Änderungen am alten Log Formular vorgenommen. Das könnte auch ein Grund sein warum alles anders ist als erwartet.

Dafür scheinen die Seiten viel schneller aufgebaut zu werden.

capoaira commented 3 years ago

@MagpieFourtyTwo, @Arnos99 Ich habe mich gerade an #1301 gesetzt und würde in diesem Zuge auch gleich hier drüber gucken. Allerdings kann ich den Fehler nicht reproduzieren. So habe ich das verstanden:

Könntet ihr nochmal versuchen den Fehler nachzustellen und dann ein Screeshot von der console schicken?

MagpieFourtyTwo commented 3 years ago

Könntet ihr nochmal versuchen den Fehler nachzustellen und dann ein Screeshot von der console schicken?

Leider nein - ich habe cookiebot zwar nach wie vor per uBlock geblockt, und das unverändert, seitdem der damals die Seite so elends langsam gemacht hat, aber schon seit einiger Zeit "leider" kein Problem mehr mit AutoVisit gehabt ... oder zumindest nicht dass es mir aufgefallen wäre.

Hab daher jetzt auch noch mal die letzten 30 Tage meines ständigen Begleiter-TBs geprüft, aber der hat auch jeden Tag mindestens ein Log, das dürfte also passen ...

capoaira commented 3 years ago

Das höhrt sich doch auch gut an. Evtl. hat GS intern etwas überarbeitet, sodass cookiebot schneller läuft.

MagpieFourtyTwo commented 3 years ago

Ob der schneller läuft oder nicht kann ich nicht sagen, weil ich es wie gesagt eh geblockt habe. Von daher hat es bei mir eh von Anfang an immer maximale Höchstgeschwindigkeit gehabt. ;)

2Abendsegler commented 3 years ago

Gefixed mit Issue #1301. Kommt mit der nächsten Version. Close Issue.