Von der knappen Beschreibung her kann man nur Vermutungen über die Ursachen anstellen. Wenn du sagst, dass hardwareseitig die Tastendrücke weiterhin registriert werden ("Chat reagiert noch"), dann könnte man Paketverluste der Client-Server TCP/IP-Verbindung auf dem Netzwerkweg vermuten. Die Clientchat-Chatserver-Verbindung läuft nämlich über einen zweiten, unabhängigen Port. Damit wäre es kein reines Problem des Mac-Clients.

Um das Problem besser eingrenzen zu können, bräuchte man mehr Informationen. Zum Beispiel: Tritt das Problem die ganze Zeit auf oder nur zeitweilig, zu welchen Uhrzeiten besonders oft/stark, in welchen Gebieten hältst du dich dann in-game auf, hängt dein Mac über Netzwerkkabel oder WLAN am Router, wieviele Personen teilen sich den Internetanschluss im Haushalt, welche Verbindungsart (DSL, LTE, Kabel etc.) bei welchem Provider hast du, benutzt du ein VPN oder sonstige Proxies, wieviele und welche Firewalls betreibst du wo (Mac, Router, etc.).

Paketverluste treten dann auf, wenn ein Routerport saturiert wird, d.h. wenn er dauerhaft zu mehr als 90% ausgelastet wird. Problem ist, dass kann überall auf der Strecke von dir ins RZ nach FFM vorkommen, und es sind sehr viele Parteien involviert. Du kannst natürlich nur Dinge bei dir zuhause beobachten, bzw. ändern; alles, was hinter deinem Router passiert, kannst du nicht mehr beeinflussen.

Zur Not müsste man mal die Latenzzeiten während dieser Aussetzer messen, aber das ist etwas aufwendiger.

Der KB-Artikel zum "Unbekannten Fehler" empfiehlt, über die Launcher-Option das Spiel zu reparieren.

Bevor man das macht, kann man aber auch, nacheinander mit steigendem Aufwand, folgendes versuchen:

• Sämtliche Addons deaktivieren und eine Weile ohne spielen. Sind diese als Fehlerquelle ausgeschlossen, sollte man sie (gerade nach erfolgten Updates des Spiels) wenn möglich auf den neuesten Stand bringen, falls noch nicht geschehen.
• Im Benutzerordner unter Dokumente/Elder Scrolls Online/liveeu (für den EU Server) die Dateien UserSettings.txt und ShaderCache.cooked wegsichern, bzw. umbenennen, so dass das Spiel mit neuangelegten Dateien und Standardeinstellungen startet.
• Zusätzlich, bzw. danach, kann man im Spiel unter den Einstellungen die Hauptoption Grafik-Qualität auf eine der vorgegebenen Stufen zurückstellen. Es empfiehlt sich, je nach Rechen/Grafikpower, mit "Sehr hoch" anzufangen und dann die untergeordneten Einzeloptionen nach Bedarf runter zu setzen, weil durch die Hauptoption auch einige "versteckte" Optionen beeinflusst werden. VSYNC sollte immer aus sein.
• Die Textur-Qualität übrigens beeinflusst mit die Zeit, bis der Memory Leak zuschlägt, zusätzlich zur eigenen Aktivität im Spiel. Die Einstellung auf "Mittel" kann diese Zeit beträchtlich strecken (siehe auch den sticky Post oben im Forum).
• Nun kann man über die Reparatur der Clientdateien nachdenken.
• Es gibt einen Bericht von einem Benutzer im englischen Mac Forum, der das Spiel nach einer Abo-Pause jüngst komplett neu installiert hat und ohne Probleme selbst in Cyrodiil mehrere Stunden verbringt. Mit einer Neuinstallation sind natürlich alle oben genannten Schritte abgearbeitet.

Falls der Fehler danach immer noch auftritt und eine Fehlernummer dabei steht, kannst du diese ja per /help oder /bug im Spiel, oder unter hilfe.elderscrollsonline.com/app/ask an den Support melden.

Meine Vermutung ist, dass irgendwo Paketverluste auftreten. Bei einer TCP/IP-Verbindung steigt damit auch immer die Latenz in den Sekundenbereich. Der Client desynchronisert dann mit dem Server und es könnte zu dem Phänomen führen, dass sich der Client mit dem unbekannten Fehler beendet. Aber das muss sich auch belegen lassen. Leider fehlt dem Spiel eine eingebaute Latenz-Anzeige.

Versuch doch mal folgendes:

• starte das Spiel im Fenster-Modus, und verkleinere es, so dass es nicht den ganzen Desktop einnimmt und noch andere Fenster sichtbar bleiben
• mit [Alt]-[Tab] kommst du auf den Desktop
• starte ein Terminal-Fenster (am schnellsten über Spotlight: [Cmd]-[Leertaste], dann "Terminal" suchen und starten)
• gib folgendes ein und drücke [Enter]

  lsof -i tcp | grep eso
  

  (das | ist [Alt]-[7])
• du solltest zwei zustanden gekommene ("ESTABLISHED") TCP-Verbindungen ins 159.100.232.* Netzwerk auf Ports im 24000er Bereich sehen.
• Nun setz ein ping auf eine der beiden IP-Adressen ab, z.B.:

  ping 159.100.232.114
  

• Der ping läuft nun solange, bis du den Befehl mit [Ctrl]-[C] unterbrichst. Beobachte die Zeiten (in Millisekunden) während des Spielens und insbesondere dann, wenn das Phänomen auftritt. Wechsele die beiden IP-Adressen ab.

Würde mich interessieren, ob und was dabei herauskommt. Es gibt dabei grundsätzlich einen Schönheitsfehler: ping geht über ICMP, nicht über TCP. Ein ping kann also "normale" Roundtrip-Zeiten vermelden, währen die TCP-Pakete gerade irgendwo unterwegs verhungern. Meine Latenz zum neuen RZ in FFM liegt übrigens im Mittel um die 11 ms (DTAG ADSLv2 16000 kbit/sec).

zauberfalke schrieb: »

PING:
Auf einer IP bekomme ich nur "Request timeout for icmp_seq"
auf der anderen IP schwankt der Wert zw. 13 und 26 ms, zwischendurch auch mal timeout

Jup, und bei diesen Timeouts sind irgendwo unterwegs ICMP Echo Request Antwort-Pakete verloren gegangen. Wie oft tritt das auf, wenn du den ping mal länger laufen lässt? Von, beispielsweise, 100 pings bei mir ging kein einziger auf Timeout, und alle lagen bei einer Latenz zwischen 10,9 und 12,7 ms, also keine breite Streuung. Wenn du mal 100, 1000, oder 10.000 pings absetzt, hast du da eine merkliche Verlustrate mit eventuell wild schwankenden Latenzen?

Die HTTP-Fehlermeldungen im Launcher beim Download sind mir allerdings selber noch nie untergekommen, könnten aber auch als weiterer Hinweis auf Paketverluste interpretiert werden. HTTP ist da eigentlich sehr robust und weiß gut damit umzugehen. Allerdings lädt der Launcher seine Daten von den Amazon Web Services (AWS, das Cloud Computing und Content Delivery Network von Amazon, Inc.), nicht von den ZOS Serverfarmen selber.

Wenn du bei anderen Online-Spielen aktuell (also nach dem Wechsel deiner Anschlussleitung) keinerlei Probleme der gleichen Art hast, dann könnte man vermuten, dass eventuell etwas beim Peering deines ISP (Kabel D) mit dem ISP von ZOS Deutschland (Level 3) nicht ganz rundläuft. Falls diese beiden nicht direkt miteinander peeren, gibt es noch entsprechend mehr(ere) Mittelsmänner zwischen beiden.

Das Problem ist, a) so etwas belegbar und eindeutig nachzuweisen, weil sich die entsprechenden Logs und aussagekräftigen Tools nur in den Händen der ISP selber befinden, und b) als kleiner Endkunde überhaupt damit gehört zu werden. Selbst ZOS ist "nur" Business-Kunde bei Level 3. ZOS könnte im Prinzip auch nur dann bei ihrem ISP auf Nachforschungen (oder gar Nachbesserungen) pochen, wenn ein großer Teil ihrer Kundschaft mit dem gleichen Endkunden-ISP die gleichen Probleme meldet. Insofern solltest du (und jeder andere auch) natürlich Probleme dieser Art auch bei Fortbestehen wieder melden, damit ZOS etwas in der Hand hat, mit dem sie arbeiten können.

Was man machen könnte, wäre mal mit traceroute etwas rumzuspielen. Ob das irgendetwas ergibt (oder gar belegt), bliebe dahingestellt. Eventuelle Auffälligkeiten könnte man eh nur an den Kundendienst weitergeben, und die sind natürlich auch erstmal machtlos, wenn es um "Peering-Politik" zwischen ISPs geht. Wenn du also wie oben beschrieben die aktuellen Client-TCP-Verbindungen kennst, kannst du ja mal ein traceroute auf beide nacheinander absetzen, z.B.:

traceroute -a -q 3 159.100.232.160

Das ganze, wenn möglich, öfters an verschiedenen Wochentagen zu unterschiedlichen Uhrzeiten. Was nämlich gerne vergessen wird ist, dass das Kabelfernsehnetz auf der letzen Meile ein shared medium ist, dass sich alle angeschlossenen Teilnehmer bis zur nächsten Kopfstation teilen. Da kann man nur hoffen, in einer Gegend ohne viele "Power-Sauger" zu wohnen.

Auch bei traceroute gibt es wieder den Wermutstropfen, dass es im Normalfall nicht mit TCP arbeitet, sondern mit (immerhin) UDP; man kann das mit der Option -P tcp ändern, aber dann funktioniert der trace höchstwahrscheinlich erst gar nicht, weil TCP-Pakete ohne vorheriges SYN meistens kommentarlos geblockt/verworfen werden. Die Option -a sucht das entsprechende Autonome System heraus, zu dem eine erreichte IP-Adresse gehört. Damit kann man über eine Abfrage bei der RIPE NCC Datenbank herausfinden, welcher Firma/Organisation das dazugehörige IP-Netzwerk gehört. So findet man den Weg, den IP-Verbindungen von sich zuhause über's Internet zu einem Anbieter nehmen.

Die Option -q bestimmt die Anzahl der Pakete, die zum jeweiligen Hop (Zwischenstation) gesendet werden, um über die Antwortzeit mitteln zu können (3 Pakete sind Standard). Würde man jetzt herausfinden wollen, ob irgendwo Antwortpakete verschludert werden, könnte man -q entsprechend hoch ansetzen, um etwaige Verluste besser entdecken zu können: 10, 50, 100. Nachteil ist, dass dann zu jedem Hop auf der Strecke entsprechend viele Pakete geschickt werden und das ganze ein Geduldspiel wird. Bei mir sind es, Heimrouter und Zielhost mitgezählt, insgesamt 7 Hops.

Hey Leute,
bitte kontaktiert unseren Kundendienst und beschreibt euer jeweiliges Problem. Wir werden euch in Kürze antworten. http://hilfe.elderscrollsonline.com/

Nun ja - das Forum hier heisst doch " Kundendienst - Deutsch Technischer Support Mac" also haben wir uns ja korrekt verhalten! Da die Vorkommen des Genannten Fehlers - der hinreichend beschrieben ist - sich häufen habe ich auch einen Fehlerbericht ingame eingereicht. Genauere Angaben wie gross die Latenz ist oder etwa welche Tastendrücke unter welchen Umständen nicht durchkommen kann keiner machen da das disassemblieren und debuggen gegen die EULA verstösst! Da wären wir auf eine offizielle Test/Fehlersuchversion des Client angewiesen.