Adressbuch braucht 35 sec zum Öffnen

    Ich arbeite am Arbeitsplatz mit thunderbird. Ich habe ca. 2100 Kontakte gespeichert, in 4 Adressbücher, mit vielen Gruppenunterteilungen. Seit einiger Zeit braucht thunderbird exact 35 sec wenn ich in der Normalansicht auf Adressbuch klicke, um es zu öffnen. Mir scheint, dass ich keine langen Wartezeiten habe, wenn ich in der Verfassen-Ansicht auf KOntakte gehe, aber das möchte ich noch mal testen.

    Ansonsten, habe ich schon alle Einstellungen durchgeklickt, ich finde nichts auffälliges. Wo könnte ich suchen? Ich habe die Version 1.5.0.9 und arbeite sonst mit dem normalen MS. Meine Arbeitskollegin hat genau die gleichen Programme und auch thunderbird, da ist das Problem noch nicht aufgetaucht.

    Ich habe keinen Plan, wo ich da suchen kann... Kann mir jemand helfen?
    Danke!

    Hallo Kommissarinrosa,

    nicht nur Dein Adressbuch, auch wir brauchen manchmal länger. In deiesem Fall um Deinen unbeantworteten Thread zu finden :roll:

    Da Du leider nichts von Deiner Arbeitsumgebung auf dem PC erzählst, weiß ich nicht ob Firewall oder Virenscanner, MS-DOS 3.11 oder Win XP oder Linux Deinen PC beherrschen...
    Ich vermute einen übereifrigen Virenscanner als Triebfeder, der eigentlich sowieso nichts im Profilverzeichnis zu suchen hat.
    https://www.thunderbird-mail.de/hilfe/dokument…blem_regeln.php
    Mit dem Link kommst Du in die gute und lesenswerte Dokumentation und dort zu den Gründen meiner Aussage und den Wegen zum Profilordner, damit Du diese gleich Deinem Virenscanner untersagen kannst.
    Du siehst mich also davon überzeugt, dass hier die Ursache liegt :wink:
    Der Unterschied in der Wartezeit bei den Aktionen "Adressbuch aufrufen" versus "Kontakte anzeigen" liegt vermutlich darin begründet, dass bei Ersterem das Adressverwaltungsprogramm gestartet, beim zweiten Vorgang jedoch nur auf die Adressdatei zugegriffen wird.

    Hallo kommissarinrosa,

    guck mal, wie viele nonascii-Zeilen in deiner Prefs.js stehen. Die 1.5.0.7 hatte damit massive Probleme, und auch die 1.5.0.8 hat da auch noch ziemlich viele dieser Zeilen hinein geschieben. Ich habe dafür auch ein kleines Tool geschrieben, das die Prefs.js bereinigt. Das Tool legt die bereinigte Prefs.js direkt auf C:\ - so kannst du das mal mit der alten und der neuen ausprobieren und vergleichen.

    schöne Grüße

    Toolman

    TB-Version: 128.3.3esr (64-Bit). ESET Smart Security, Windows 11 Pro

    man kann alle nonascii-Zeilen löschen... ist ein Bug der mit 1.5.0.9 behoben wurde.
    Sünndogskind_2 :
    Beispiel für diese Zeilen in der Prefs.js:

    user_pref("ldap_2.servers._nonascii.replication.lastChangeNumber", 0);
    user_pref("ldap_2.servers._nonascii.uri", "moz-abldapdirectory://_nonascii.mab");
    user_pref("ldap_2.servers._nonascii_1.filename", "_nonascii_1.mab");
    user_pref("ldap_2.servers._nonascii_1.replication.lastChangeNumber", 0);
    user_pref("ldap_2.servers._nonascii_1.uri", "moz-abldapdirectory://_nonascii_1.mab");
    user_pref("ldap_2.servers._nonascii_10.filename", "_nonascii_10.mab");
    user_pref("ldap_2.servers._nonascii_10.replication.lastChangeNumber", 0);
    user_pref("ldap_2.servers._nonascii_10.uri", "moz-abldapdirectory://_nonascii_10.mab");
    user_pref("ldap_2.servers._nonascii_11.filename", "_nonascii_11.mab");
    user_pref("ldap_2.servers._nonascii_11.replication.lastChangeNumber", 0);
    user_pref("ldap_2.servers._nonascii_11.uri", "moz-abldapdirectory://_nonascii_11.mab");
    user_pref("ldap_2.servers._nonascii_12.filename", "_nonascii_12.mab");
    user_pref("ldap_2.servers._nonascii_12.replication.lastChangeNumber", 0);
    user_pref("ldap_2.servers._nonascii_12.uri", "moz-abldapdirectory://_nonascii_12.mab");
    user_pref("ldap_2.servers._nonascii_13.filename", "_nonascii_13.mab");
    user_pref("ldap_2.servers._nonascii_13.replication.lastChangeNumber", 0);
    user_pref("ldap_2.servers._nonascii_13.uri", "moz-abldapdirectory://_nonascii_13.mab");
    user_pref("ldap_2.servers._nonascii_14.filename", "_nonascii_14.mab");
    user_pref("ldap_2.servers._nonascii_14.replication.lastChangeNumber", 0);
    user_pref("ldap_2.servers._nonascii_14.uri", "moz-abldapdirectory://_nonascii_14.mab");


    usw. teilweise einige 100 Zeilen.
    auf meiner Seite gibt es ein kleines Tool (prefsclean - nur für Windows) das alle diese Zeilen entfernt und die bereinigte Prefs auf %systemroot%\prefs.js ablegt. Der Hintergrund ist einfach, dass ich kein Tool schreiben wollte das die Prefs.js direkt überschreibt - Es kann immer was schiefgehen und so ist es in der Entscheidung des Anwenders diese Datei zu verwenden und man kann vor dem Überschreiben noch mal schnell ein Backup machen oder die aktuelle Prefs.js umbenennen.

    schöne Grüße

    Toolman

    TB-Version: 128.3.3esr (64-Bit). ESET Smart Security, Windows 11 Pro

    Ach das meint ihr mit "nonascii-Zeilen"; ich hatte dabei schon an sowas wie "*hier stand ein kurzes Stück Binärcode*", also an Binärcode gedacht und mich sehr gewundert, dass TB damit laufen soll. Es war also ein Missverständnis meinerseits. Solche Zeilen hatte ich nie und wenn es ein Bug aus Vor-1.5.0.9-Zeiten ist, werde ich sie hoffentlich auch nie haben. Danke für die Info!

    Gruß, Sünndogskind_2

    EDIT:
    Toolman: Ich hab den Binärcode trotzdem vorsichtshalber gelöscht.

    Hallo Sünndogskind_2,

    kannst du bitte deinen Beitrag editieren und den Binärcode wieder löschen?
    Seitdem funktioniert der Forenfeed wieder nicht.

    Danke und schöne Grüße

    Toolman

    Edit: hat sich erledigt... es muss wohl etwas anderes gewesen sein. (seit gestern 14:17 hatte ich keine neuen Feedeinträge)

    TB-Version: 128.3.3esr (64-Bit). ESET Smart Security, Windows 11 Pro