• Dieses Thema ist leer.
Ansicht von 12 Beiträgen - 16 bis 27 (von insgesamt 27)
  • Autor
    Beiträge
  • #24096
    Thilo Brandt
    Keymaster

    Hallo Axel,
    @AxelF wrote:

    In der Prio-Liste „Order of identification“ fehlt der, obwohl er genau da stehen müsste, denn dort ist er drin und nicht entfernbar.

    hast du auf dem Client als Serverbasiertes Adressbuch das jAnrufmonitor Adressbuch eingestellt? Das könnte die Ursache für das aktive CallerDirectory auf dem Server sein.

    Viele Grüße
    Thilo

    #24097
    Anonym
    Inaktiv

    hast du auf dem Client als Serverbasiertes Adressbuch das jAnrufmonitor Adressbuch eingestellt?

    Nein. Auf dem Client ist der Fast Client Mode an und *nur* MySQL als Adressbuch aktiv.

    #24098
    Thilo Brandt
    Keymaster

    @AxelF wrote:

    Nein. Auf dem Client ist der Fast Client Mode an und *nur* MySQL als Adressbuch aktiv.

    Puhh, dann muss ich auch passen… Das jAnrufmonitor Adressbuch dürfte dann nicht aktiv sein. Also ich bekomme diese Situation bei meinen Tests erst gar nicht nachgestellt. Schickst du mir mal deine PI des Servers, dann schau ich mir das nächste Woche mal in Ruhe an.

    #24099
    Anonym
    Inaktiv

    Hallo Thilo,

    was genau brauchst du vom Server? Die Logs, Configs, Alles?

    #24100
    Thilo Brandt
    Keymaster

    Hallo Axel,

    die PI (siehe http://www.janrufmonitor.de/pi) benötige ich.

    Viele Grüße
    Thilo

    #24101
    Anonym
    Inaktiv

    Hi Thilo,

    konntest du an Hand der gesendeten PI was rausfinden?

    Ich war inzwischen nicht untätig und habe, wenn es sich ergab, das Netzwerkverhalten des jAM beobachtet, speziell im Hinblick auf MySQL Verbindung + Journal bzw. Identifizierung. Dabei habe ich festgestellt, dass:

    1. das „jam-x.log“ regelmässig Fehler protokolliert:

    ** BEGIN NESTED EXCEPTION **

    java.net.SocketException
    MESSAGE: Software caused connection abort: socket write error

    STACKTRACE:

    java.net.SocketException: Software caused connection abort: socket write error
    at java.net.SocketOutputStream.socketWrite0(Native Method)
    [..]
    at de.janrufmonitor.ui.swt.DisplayManager$1.run(DisplayManager.java:102)

    ** END NESTED EXCEPTION **

    Last packet sent to the server was 1 ms ago.
    at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:2710)
    at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:2621)
    [..]
    at de.janrufmonitor.ui.swt.DisplayManager$1.run(DisplayManager.java:102)

    [ SEVERE - 10/Jul/2013:15:21:46 +0200 - JAM-SWT/JFaceUI-Thread-(non-deamon) - de.janrufmonitor.framework.i18n.DatabaseI18nManager.getString() - Access is denied: Session is closed ]
    java.sql.SQLException: Access is denied: Session is closed
    at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
    at org.hsqldb.jdbc.jdbcStatement.fetchResult(Unknown Source)
    [..]
    at org.eclipse.swt.widgets.Display.readAndDispatch(Unknown Source)
    at de.janrufmonitor.ui.swt.DisplayManager$1.run(DisplayManager.java:102)

    [ WARNING - 10/Jul/2013:15:21:46 +0200 - JAM-SWT/JFaceUI-Thread-(non-deamon) - de.janrufmonitor.framework.i18n.DatabaseI18nManager.getString() - Identifier {label} is not valid. ]

    2. der jAM zu 90% nicht in der Lage ist, die Verbindung zum MySQL Server aufzubauen. (Der Server und der Client laufen 5/24 durch). Wenn es jAM beim Start gelingt die Verbindung herzustellen, was häufig nicht der Fall ist, verliert er sie spätestens nach 1-2 Stunden wieder und ist nicht in der Lage, sie wieder herzustellen. Stattdessen loggt er nur noch Fehler. Selbst wenn man nach Neustart im Journal einen Eintrag manuell aktualisieren möchte, wird statt des Verbindungsversuches nur der Error protokolliert, das war’s dann wieder mal.

    Das ist ein merkwürdiges Verhalten. Kann man da was machen? Ansonsten ist das MySQL Modul in einer C/S Umgebung unbrauchbar.

    Womit ich wieder beim „langsamen Adressbuch“ bin. Denn die empfohlene Anzahl an Kontakten im textbasierten Adressbuch ist wegen unerklärlichen Performance-Problemen praxisfern und kommt in einer Client/Server Umgebung nicht in Frage. Es gibt keinen sinnvollen Filter um die Anzahl der angezeigten Kontakte so zu begrenzen, dass der jAM damit klar käme. Einen Filter nach „Vorwahl“ brauchen sicher die wenigsten. Sinnvoller wäre z.B. ein Filter für die 100 zuletzt eingefügten Kontakte – oder nach Alphabet (zeige A.. bis C..) – oder seitenweise 1-100, 101-200, …

    Ein Adressbuch ist naturgemäss ein stetig wachsendes Verzeichnis. Man kann es nicht künstlich klein halten, nur damit der jAM nicht überfordert wird.

    Aus meiner Sicht muss das Verhalten des jAM im Zusammenspiel mit dem MySQL Modul überarbeitet werden und das Adressbuch benötigt – neben einer Performance Optimierung – brauchbare Filter.

    Ich bin sofort dabei, wenn ich dabei helfen kann.

    #24102
    Thilo Brandt
    Keymaster

    Hallo AxelF,

    erst mal die „guten“ Nachrichten 🙂

    @AxelF wrote:

    …Es gibt keinen sinnvollen Filter um die Anzahl der angezeigten Kontakte so zu begrenzen, dass der jAM damit klar käme. Einen Filter nach „Vorwahl“ brauchen sicher die wenigsten. Sinnvoller wäre z.B. ein Filter für die 100 zuletzt eingefügten Kontakte – oder nach Alphabet (zeige A.. bis C..) – oder seitenweise 1-100, 101-200, …

    Eigentlich ist die Kategorie seit einigen Versionen die Gruppierungsfunktion der Wahl. Diese werden als Filter dann angeboten und man kann Kontakte jeweils einer Kategorie zu weisen. So machen das ja auch die bewerten PIMs wie Apple Kontakte oder Outlook inzwischen. Nichts desto trotz habe ich bereits für Version 5.0.42 die Alphabet-Filter für Nachnamen auf dem Plan, damit kannst du dann, wie in einem Adressbuch nach A…, B… usw. filtern.

    @AxelF wrote:

    Ein Adressbuch ist naturgemäss ein stetig wachsendes Verzeichnis. Man kann es nicht künstlich klein halten, nur damit der jAM nicht überfordert wird.

    Da bin ich anderer Meinung. Ein gut gepflegtes Adressbuch „lebt“, d.h. im Laufe der Zeit kommen sicherlich Adressen hinzu, aber es verschwinden auch wieder Kontakte. Gerade im privaten Bereich, für das jAnrufmonitor eben primär konzipiert ist, hat eine gute Adressliste keine 5-stellige Kontakte-Anzahl. Meine Meinung ist, dass die Kontaktliste ein gewisses Personenumfeld im zeitlichen Kontext widerspiegeln muss. Für Kontakte-Sammler, die niemals Kontakte löschen, wenn sie nicht mehr aktuell sind, ist jAnrufmonitor in der Tat das falsche Produkt. Schließlich erhebe ich ja nicht den Anspruch auf eine PIM Software mit jAnrufmonitor zu erfüllen.

    @AxelF wrote:

    Aus meiner Sicht muss das Verhalten des jAM im Zusammenspiel mit dem MySQL Modul überarbeitet werden und das Adressbuch benötigt – neben einer Performance Optimierung – brauchbare Filter.

    Bin ich bei dir. Ist aktuell eine Zeitfrage. Der Umbau des Moduls ist keine kleine Entwicklung, da ja der Funktionsumfang für Adressbücher im jAnrufmonitor gewachsen ist, und dieser beim Umbau berücksichtigt werden muss. Wie schon oben mal geschrieben, habe ich das Thema MySQL Optimierung auf der ToDo-Liste, bin es nur noch nicht angegangen.

    @AxelF wrote:

    konntest du an Hand der gesendeten PI was rausfinden?

    Nein, nicht wirklich. Mit deiner PI habe ich eine Installation am Laufen, kann aber den Fehler bei mir nicht reproduzieren. Auch deine Beobachtung nach 1-2 Stunden Betrieb kann ich nicht nachvollziehen. Es gibt in der Tat mal Connection-Probleme, das aber eher nach Hibernate oder StandBy Zuständen. Hierfür werde ich noch Bugfixe liefern.

    @AxelF wrote:

    ** BEGIN NESTED EXCEPTION **

    java.net.SocketException
    MESSAGE: Software caused connection abort: socket write error

    STACKTRACE:

    java.net.SocketException: Software caused connection abort: socket write error
    at java.net.SocketOutputStream.socketWrite0(Native Method)
    [..]
    at de.janrufmonitor.ui.swt.DisplayManager$1.run(DisplayManager.java:102)

    ** END NESTED EXCEPTION **

    Last packet sent to the server was 1 ms ago.
    at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:2710)
    at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:2621)
    [..]
    at de.janrufmonitor.ui.swt.DisplayManager$1.run(DisplayManager.java:102)

    [ SEVERE - 10/Jul/2013:15:21:46 +0200 - JAM-SWT/JFaceUI-Thread-(non-deamon) - de.janrufmonitor.framework.i18n.DatabaseI18nManager.getString() - Access is denied: Session is closed ]
    java.sql.SQLException: Access is denied: Session is closed
    at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
    at org.hsqldb.jdbc.jdbcStatement.fetchResult(Unknown Source)
    [..]
    at org.eclipse.swt.widgets.Display.readAndDispatch(Unknown Source)
    at de.janrufmonitor.ui.swt.DisplayManager$1.run(DisplayManager.java:102)

    [ WARNING - 10/Jul/2013:15:21:46 +0200 - JAM-SWT/JFaceUI-Thread-(non-deamon) - de.janrufmonitor.framework.i18n.DatabaseI18nManager.getString() - Identifier {label} is not valid. ]

    Bist du auf Version 5.0.41? Damit sind nämlich die Session-Closed Fehler beseitigt worden. Mich wundert, dass diese bei dir noch auftreten.

    Was spricht bei dir nochmal für das jAnrufmonitor eigene Adressbuch? Warum bist du davon weggekommen? Warum musste es MySQL sein?

    Viele Grüße
    Thilo

    #24103
    Anonym
    Inaktiv

    Hallo Thilo,

    danke für deine ausführliche Antwort.

    Deine Ansicht, dass der jAM vorwiegend privat verwendet wird, kann ich nicht teilen. Wer hat schon zu Hause ISDN, Client/Server, MySQL Server… Aber darum geht es ja auch nicht. Adresslisten werden vielleicht im guten, alten Notizbuch gepflegt, aber nicht auf dem PC von Privatleuten, die nicht mal in der Lage oder Willens sind, unbenötigte Treiber, Drucker, Startmenüeinträge usw. vom System zu entfernen. Das ist nun mal so.

    Datenbanken sind – auch wenn du das [noch] anders siehst – *nicht* dazu da, händisch gepflegt zu werden. Warum soll ich mit solchen Dingen, die weder Spass machen noch produktiv sind, meine Zeit verschwenden? Solche Aufgaben hat gefälligst der Computer zu erledigen, denn dazu ist er da! Ich sortiere ja auch nicht Spam manuell aus, obwohl ich es könnte. Und du vernichtest nicht jede alte Datei, die du nicht mehr brauchst und hast bestimmt auch schon deine achte Festplatte und fünften USB Stick und räumst nicht dauernd alte Backups auf, nur um die Redundanz zu verringern 😉

    Das Entfernen der verstorbenen Tante Emma kann der PC natürlich nicht ohne Weiteres erledigen, aber er kann Tante Erna in der Liste absacken lassen, so wie alle Kontakte, die in den letzten 300 Tagen nicht angerufen haben. Staffelt man diese Logik in z.B. 50 Tage Intervalle, dann sammeln sich mit wachsender Wahrscheinlichkeit die unbedeutenden Kontakte am Ende der Liste. Nach 2 oder 3 Jahren kann man den Kontakt entfernen und schwupps ist auch Tante Emma raus.

    So räumt sich die Liste selber auf – mit zwei angenehmen Nebeneffekten:

    1. die Liste hört irgendwann auf zu wachsen

    2. die wichtigen Kontakte stehen oben. Dann macht auch ein Filter auf $Anzahl_Einträge Sinn, denn das sind die, die am häufigsten anrufen und für die die Wahrscheinlichkeit am höchsten ist, dass man danach sucht.

    Das mit den Kategorien ist nicht der Weisheit letzter Schluss. Sogar MS geht im Outlook davon weg und empfielt, diese nicht mehr zu verwenden.

    Ich akzeptiere und erkenne an, dass der jAM ein Hobby- und vielleicht auch Lern-Projekt ist und deshalb nicht auf höchstem Profi-Level entwickelt wird und wurde – obwohl es nah dran ist und ein Haufen Arbeit drin steckt. Das kann man nicht hoch genug schätzen. Du steckst soviel Herzblut in das Projekt (inkl. Support!!!), dass es mir manchmal unheimlich wird, im Ernst! Ich spreche aus Erfahrung aus einem Open Source Projekt, wo ich mal mit ähnlichen Ambitionen involviert war 🙂

    Aber dem steht ja nicht im Weg, dass man Gutes nicht verbessern könnte. Aber nun zurück zum Thema:

    Ich habe nun von v5.0.37 auf v5.0.41 aktualisiert und dabei auch noch das Datenbank-Journal von 2.0.7 auf 2.0.8, selbiges auf dem Server + diverese Telefonbücher f. d. Reverse-Suche. Nun kann ich mit aktuellen Logeinträgen aufwarten, nutze dazu den Anrufsimulator mit einer Nummer, die im Adressbuch steht. Ergebnis:

    In MySQL-DB nicht gefunden, das Örtliche wird befragt, Eintrag im Log

    [ SEVERE - 12/Jul/2013:19:06:09 +0200 - Thread-63 - de.janrufmonitor.service.client.Client.disconnect() - Unregistration of client 192.168.66.9 failed. Server not reachable. ]

    Auffällig ist im Moment, das auch Fehler (keine Verbindung zum MySQL) nicht mehr geloggt werden. Werde ggf. den Loglevel höher stellen.

    Mit deiner PI habe ich eine Installation am Laufen, kann aber den Fehler bei mir nicht reproduzieren.

    Macht nichts, wirf sie weg. Es ist nun zuviel Zeit vergangen.

    Es gibt in der Tat mal Connection-Probleme, das aber eher nach Hibernate oder StandBy Zuständen.

    Ja, da auch. Aber ich kann (bzw. konnte) dem jAM fast zusehen, wie er die Verbindung verlor. Das ist ja an und für sich kein Problem und in Zeiten von WLAN mehr oder weniger normal. Aber warum baut er sie dann nicht wieder auf, nicht mal ein einziger Versuch.

    Da du die MySQL Geschichte noch auf der ToDo Liste hast, will ich jetzt nicht weiter drauf rumreiten. Das ist nachvollziehbar eine grössere Maßnahme, ich wünsche dir dafür viel Zeit und Kraft.

    Was spricht bei dir nochmal für das jAnrufmonitor eigene Adressbuch? Warum bist du davon weggekommen?

    Gegen das jAM Adressbuch (und für MySQL) sprach die Performance, speziell beim servergespeicherten. Ich habe keine 5-stellige Anzahl von Kontakten, sondern 600. Wenn ich das AB aufrief, war der jAM für mehrere Stunden mit sich selbst beschäftigt und reagiert auf nichts. Du hattest dann empfohlen, die Spalte „Zuletzt angerufen“ zu entfernen, was eine erhebliche Verbesserung brachte. Danach ging es eigentlich nur noch um die Probleme mit der Identifizierung der Kontakte über MySQL.

    Ich schlage vor, dass wir das Thema an dieser Stelle schliessen, denn die Ursache der Probleme mit den nicht erkannten Kontakten, sind nun klar, können aber nur mit grossem Aufwand beseitigt werden.

    Vielleicht lässt du dir aber meine Idee mit dem selbstpflegenden Adressbuch nochmal durch den Kopf gehen?

    PS: ISDN wird ja immer weiter zurückgebaut. Hast du da nicht Angst um dein „Baby“?

    #24104
    Thilo Brandt
    Keymaster

    Hallo Axel,

    @AxelF wrote:

    Du hattest dann empfohlen, die Spalte „Zuletzt angerufen“ zu entfernen, was eine erhebliche Verbesserung brachte. Danach ging es eigentlich nur noch um die Probleme mit der Identifizierung der Kontakte über MySQL.

    Ok, wie du oben schreibst, war das der Stand 5.0.37. Im Zuge diverse Optimierungen in den verschiedenen Modulen wurde das Programm-Framework auch nochmal in Bezug auf Performance verbessert. Den Tipp die Spalte „Zuletzt angerufen“ zu entfernen, bleibt immer noch bestehen, aber bei 600 Kontakten lohnt sich das jAnrufmonitor eigene Adressbuch nochmal anzuschauen. Insbesondere deswegen, als dass seit Version 5.0.39 eine Indize-Funktion auf die Attribute wie Nachname, Vorname, Ort etc. angewandt wird. Bilder sollten im Client/Server Betrieb mittlerweile auch mit gzip-Kompression übertragen werden, dennoch auch hier auf die Dateigröße achten und bei den empfohlenen 110×90 px bleiben. Ausserdem steht zur Version 5.0.42 die Einführung von Alphabet-Filtern für die Spalten Name, Ort und Land in den Kontakten an (u.a. durch Feedback von dir).
    Mein Standard-Test fürs Adressbuch ist bereits seit Version 5.0.38 mit 500, 1000 und 2000 Kontakten am Laufen (lokal). Client/Server-Adressbuch läuft bis 1000 Kontakte auch flüssig, wobei man sagen muss, dass nur ca. 50 % der Kontakte Bilder und/oder mehr als eine Rufnummer haben. Für mich sieht dein 600 Kontakte Adressbuch daher erstmal nicht aussergewöhnlich aus.

    @AxelF wrote:

    Vielleicht lässt du dir aber meine Idee mit dem selbstpflegenden Adressbuch nochmal durch den Kopf gehen?

    Ich nehme es auf jeden Fall mal auf die ToDo-Liste auf.

    @AxelF wrote:

    PS: ISDN wird ja immer weiter zurückgebaut. Hast du da nicht Angst um dein „Baby“?

    Nein ehrlich gesagt nicht, ISDN ist schon seit gut 4 Jahren ein rückläufiges Thema. Die Installationen mit ISDN liegen derzeit bei 39% aller jAnrufmonitor Installationen. Steckenpferd ist inzwischen die AVM Fritz!Box Fon Variante mit 49% aller Installationen. 9% geht auf TAPI und der Rest sind Client-Installationen ohne „echte“ Überwachungskomponente. In Planung ist auch eine SIP-Überwachung für reine VoIP Anschlüsse. Aktuell aber auch von der Prio etwas zurückgelagert. Durch die Modularisierung des JAMs, sollte aber auch hier mit relativ überschaubarem Aufwand eine Lösung realisierbar sein.

    Viele Grüße
    Thilo

    #24105
    Anonym
    Inaktiv

    Hallo Forum & Thilo und Axel,

    weit davon entfernt, Fragen wie „Umstellung des jAnrufmonitor-Adressbuchs auf MySQL“ beantworten (oder auch nur verstehen) zu können, habe ich dennoch eine wie ich meine passende Verständnisfrage.

    Bei mir läuft jAnrufmonitor (Fritz!Box-Variante) als Server auf einem kleinen Netbook und speist über WLAN zwei Clients.

    Das funktioniert auch alles bestens, insbesondere die Anzeige der Anrufer.

    Auch das Journal öffnet sich wenige Sekunden nach dem Aufruf auf den Clients (möglicherweise weil der Filter auf „maximal 100 Einträge“ steht).

    Allerdings kann die Anzeige des Adressbuchs auf dem Client schon mal eine Minute dauern (falls sie funktioniert). Früher war der Server übrigens auf einem leistungsfähigeren Notebook, da ging auch die Anzeige des Adressbuchs am Client viel schneller.

    Nun ist es mir zwar als Computer Power User, allerdings Datenbank-Dummie, absolut unverständlich, wie eine Liste mit vielleicht 200 Einträgen einen Gigahertz- Prozessor und ein Megabit-Netzwerk buchstäblich minutenlang beschäftigen kann, bis sie angezeigt wird.

    Manchmal reagiert der jAnrufmonitor auf dem Client auch überhaupt nicht mehr, bis nach ein paar Minuten eine Fehlermeldung kommt, oder das Fenster bzw. Icon wieder auf Eingaben reagiert.

    Soeben warte ich (nach dem Aufruf des Adressbuchs am Client) buchstäblich seit einer Viertelstunde auf das Ende einer abwechselnden Abfolge der folgenden Meldungen:




    Jetzt ist der Netbook-Server sogar derart zusammengebrochen, dass auch nach einem Re-Boot das WLAN nicht mehr funktioniert. Ich musste erst die Fritz!Box neustarten, um alles wieder zum Laufen zu bringen — und ich habe normalerweise keine Netzwerkprobleme…

    Das war jetzt zwar ein Extremfall, aber ist schon öfters so oder ähnlich vorgekommen, wenn man nur schnell an einem jAnrufmonitor-Client eine Adresse nachschlagen wollte.

    Ich meine, 200 Adressen, das sind nach meiner bescheidenen Auffassung sehr großzügig geschätzt „ein Megabit“. Eine solche Datenmenge müsste jede heutige CPU in winzigen Bruchteilen einer Sekunde mehrfach verarbeiten, und jedes heutige Netzwerk ebenfalls innerhalb von Bruchteilen einer Sekunde übertragen können.

    Stattdessen dauert es aber tatsächlich um den Faktor ~100 länger, und manchmal geht es auch gar nicht, und nur noch der Taskmanager- oder gar Netzschalter-Vorschlaghammer hilft.

    Das hat sicher alles gute Gründe, die ich mir aber einfach nicht vorstellen kann. Ist die Kombination aus Java-Runtimes und Datenbankzugriff derart ineffizient, dass es „hunderte mal“ langsamer geht als die Anzeige einer simplen Textdatei mit ein paar Seiten Text, übers Netzwerk?

    Und wenn das so ist, warum ist man dann gezwungen, es so „umständlich und langsam“ zu machen?

    Nochmal, eine Textdatei mit 50 Seiten Text ist ein absoluter Klacks auch für einen 20 Jahre alten Computer. Warum bricht mir aber mit wenigen 100 jAnrufmonitor-Adressen buchstäblich mein halbes Home-Netzwerk zusammen?

    Fragt sich ratlos
    David.P

    #24106
    Thilo Brandt
    Keymaster

    Hallo David.P,

    das sollte in der Tat schneller gehen. Ich befürchte, dass das aber gar keine Problem des jAnrufmonitors sondern deines PC sein wird. Hast du sowas wie Internet Security Software laufen? Oder Windows Defender? Du musst beachten, dass jAnrufmonitor eine Java Anwendung ist. Java ist böse! Zumindest in der Windows Welt. D.h. IS Programme oder Defender blockieren oder scannen Java HTTP Anfragen erst mal und das verzögert die komplette Kommunikation. In neuester Zeit „kämpfe“ ich gerade an der AVAST Front. Hier hat der Hersteller einfach Java mal komplett geblockt und bot nichtmal einen Schalter das für einen Benutzer auszuschalten. Schau mal, was bei dir auf Server und Client so alles in Richtung Netzwerk-Traffic geht. Von jAnrufmonitor-Seite kann man da wenig machen.
    Was du im jAnrufmonitor noch tun kannst, wäre die Spalte „Zuletzt angerufen“ aus den Kontakten zu entfernen. Dieses wäre die einzige CallBack-Methode, die den Server zusätzlich belastet. Er ruft nämlich für jeden der 200 Kontakte erneut den Server-Modus auf, um den letzten Anruf des Kontakts im Journal zu ermitteln. Wenn du diese Spalte rausnimmst, sollte nochmal ein kleiner Geschwindigkeitsvorteil spürbar sein.

    Viele Grüße
    Thilo

    #24107
    Anonym
    Inaktiv

    Vielen Dank Thilo, für die schnelle Antwort und Hintergrundinformationen.

    Habe jetzt mal am Client alle Spalten bis auf Name, Adresse und Rufnummer rausgenommen — und siehe da, das Adressbuch erscheint nicht nach Dutzenden, sondern nach zwei Sekunden.

    Virenschutz habe ich mir schon seit Jahrzehnten abgewöhnt. Allerdings lief auf dem kleinen Netbook mit Windows 7 tatsächlich der Windows Defender Echtzeitschutz. Diesen habe ich auch gleich mal abgestellt.

    Also für den Moment sieht es für mich jetzt sehr gut aus mit der Performance des Adressbuchs.

    Vielen Dank nochmal,
    Grüße David

Ansicht von 12 Beiträgen - 16 bis 27 (von insgesamt 27)
  • Du musst angemeldet sein, um auf dieses Thema antworten zu können.