Hi ich habe gerade Threema auf mein neues Telefon migriert, dabei haben sich gleich mehrere Dinge geändert. Zum einen habe ich erstmals gesehen, dass ich Threema von F-Droid beziehen kann, was ich nun auch getan habe. Vorher hatte ich die Shop-Version. (Gibt es einen inhaltlichen Unterschied dieser beiden Versionen?) Zweitens bin ich von einem mehr als fünf Jahre alten LG zu einem Motorola gewechselt und drittens habe ich nun Android Version 12 statt vorher (ich glaube) 9. Alles läuft gut, nur eins stört mich, nämlich, dass ich Web-Sitzungen nun per Hand starten muss, weil Threema Push aktiv ist. Liegt es an der neuen Android- bzw. Threema-Version oder habe ich nur die Einstellung/Berechtigung nicht gefunden. Ich hatte auf dem alten Telefon keine Probleme mit verzögert zustellten Nachrichten. Brauche ich Push unbedingt auf dem neuen oder kann ich es auch ausschalten? Wie?
Beiträge von Ein_Threema_User
-
-
Cool, das hat geklappt, danke! Einfach electron.app.disableHardwareAcceleration();vor die Zeile 44, und ich bin das Problem los! Lesen die Devs hier mit oder muss ich das im Git melden? Wäre ja schön, wenn man einfach per Konfiguration die Hardwarebeschleunigung ausschalten könnte.
-
Nachdem es jetzt auch mit Version 1.2.7 nicht anders ist, habe ich noch ein bisschen herumgespielt. Ein update auf einer anderen Maschine, die ebenfalls auf OpenSUSE Tumbleweed läuft, zeigt den Fehler nicht. Auf der betroffenen Maschine sehe ich beim Start von einem Terminal aus 21 Mal folgende Fehlermeldung:
[3540:0428/162942.436308:ERROR:gbm_wrapper.cc(275)] Failed to export buffer to dma_buf: Datei oder Verzeichnis nicht gefunden (2)
Die nicht betroffene Maschine hat diese Meldungen nicht. gbm scheint auf libgbm1 hinzudeuten:
This package contains the GBM buffer management library. It provides
a mechanism for allocating buffers for graphics rendering tied to
Mesa.
GBM is intended to be used as a native platform for EGL on drm or
openwfd.
also irgendwas mit Hardware-Videobeschleunigung, was ja passen würde. Die letzte funktionierende Version hatte ich im Dezember installiert. Ich habe aber im Git keinen commit gefunden, der danach für den Fehler verantwortlich sein könnte. Trotzdem ist Threema das einzige Programm, das diese Art von Fehler zeigt.
-
Seltsam, das kann ich auf OpenSuSE Leap nicht nachvollziehen.
Hast du die Schriftart "Roboto" auf deinem System installiert?
Yep, Paket google-roboto-fonts-2.138-2.1.noarch ist installiert. Vielleicht sollte ich noch dazu sagen, dass im Browser keine Darstellungsfehler auftreten. Ach ja, die Darstellungsfehler verändern sich auch, wenn ich mit der Maus drüber fahre.
-
Hi, ich habe gerade auf die Linux rpm-Version 1.2.5-1 (unter OpenSuSE TumbleWeed) aktualisiert. Jetzt habe ich sowohl in der Chat-Übersicht als auch in den Chats selber Darstellungsfehler, wie sie in diesem Screenshot zu sehen sind.
-
Klingt so, als gäbs in deiner Systemkombination Probleme mit WebRTC. Hier lohnt eventuell mal eine Suche in bugzilla.mozilla.org/
In der Tat, ich habe gerade diesen Bug gefunden, allerdings kein FF Bug an sich sondern einer mit opensuse. Habe den dortigen Workaround angewandt, der zwar mein Problem mit dem Einfrieren zu beheben scheint, aber webrtc funktioniert immer noch nicht richtig. Inzwischen fahre ich mit zwei Profilen, ein ganz leeres nur für threema web. Mit letzterem geht es manchmal...
-
Inzwischen habe ich auch die Version 93. Und ich habe nicht nur Probleme mit Threema Web, sondern auch mit test.webrtc.org oder lichess.org. Beide Webseiten schaffen es, ff zum einfrieren zu bringen. Das ist auch auf dem zweiten Computer der Fall. Wenn das so weiter geht, werde ich wohl einen anderen Browser nehmen müssen. Nur komisch, dass es offenbar sonst niemanden trifft. Vielleicht liegt es ja an opensuse und deren Nutzer benötigen betroffene Webseiten nicht, so dass es nicht auffällt.
-
Hab ich mal angehängt. Allerdings ist nicht alles zu sehen, sondern nur unten die fehlerhaften Test,, weil mein Bildschirm nicht hoch genug ist.
Aber das Fehlerbild wird immer merkwürdiger. Ich hatte ja gesagt, dass ein Löschen des Profils nichts ändert. Das ist nicht ganz korrekt. Das „Löschen“ bestand darin, dass ich firefox als root gestartet habe und dort das vorhandene Profil im Profilmanager gelöscht und auch ein neues angelegt habe. Damit hatte ich dann dasselbe Fehlerbild. Da ich „als root starten“ über „kdesu“ gemacht hatte, lief der Windowmanager immer noch unter meinem normalen Login. Jetzt fiel mir ein, dass ich noch einen Testuser auf dem System hatte. Für den ebenfalls über kdesu FF gestartet, hatte ich wieder denselben Fehler. Ich habe danach das bereits vorhandene alte (aber nie benutzte) Profil des Testusers gelöscht und wie bei root ein neues erstellt. Mit diesem Profil funktionierte es plötzlich. Daraufhin habe ich mich richtig als root am Window-Manager eingeloggt, um zu vermeiden, dass dieser auf irgendwelche Ressourcen meines normalen Logins zugreift, aber auch damit hatte ich den Fehler.
Fazit: ein normaler User mit frischem Profil hat das Problem nicht, ich mit meinem alten Profil und root mit einem neuen haben es. Ich will logischerweise jetzt nicht mein komplettes Profil löschen, zumal ich nicht einmal sicher sein kann, dass das das Problem lösen würde (siehe root). Vielleicht liegt es an irgendwelchen Gruppenzugehörigkeiten. Mein normales Login hat mehr davon als der Testuser, und root darf ja eh alles. Warum allerdings mehr Berechtigungen zu dem Fehler führen sollten, ist mir schleierhaft.
-
Nutzt du ein VPN?
Im Telefon? Ja, Blokada 5. Aber das sollte ja keine Rolle spielen, da es mit anderen Computern/Browsern klappt. Im betroffenen Computer? Nein.
-
Hast du jemals etwas an about:config geändert? Ist vielleicht media.peerconnection.turn.disable auf true gesetzt? (Ist Standardmässig auf false.) So weit ich weiss werden im Fehlerbehebungsmodus nicht alle Parameter in about:config auf die Standardwerte zurückgesetzt.
Nicht in letzter Zeit. Und media.peerconnection.turn.disable steht auf false. Die einzige Einstellung mit peerconnection, die nicht auf ihrem Standardwert steht (bzw. fett ist), ist app.normandy.startupRolloutPrefs.media.peerconnection.mtransport_process. Dies ist offenbar kein Standard-Parameter, da er beim Umschalten von true auf false weiterhin fett bleibt und ich ihn entfernen könnte. Wenn ich das tue, ändert sich allerdings am Fehler nichts. Der andere Rechner, auf dem es noch funktioniert, hat den troubleshoot-Test mit überall grünen Haken bestanden. Wie gesagt, das ist das gleiche Betriebssystem. Und auch am betroffenen Rechner geht es ja mit opera immer noch. Sehr mysteriös! Gibt es noch about:config-Einstellungen, die ich checken sollte?
-
das habe ich auch hin und wieder. Hast Du schon versucht, die aktuelle Sitzung zu löschen und eine neue zu erstellen? Besteht das Problem auch im Fehlerbehebungsmodus? Falls ja, besteht das Problem auch in einem neuen, frischen Testprofil ohne jegliche Änderungen und/oder Erweiterungen?
Gruß Ingo
Das Problem tritt bei dem Versuch auf, eine neue Sitzung zu erstellen. Und ja, auch mit einem frischen Testprofil, wie ich schon schrieb und du zitiertes.
Mittlerweile ist die neuste Version von Firefox 93.0. Uns sind aber keine allgemeinen Probleme in 92 oder 93 aufgefallen.
Die Tipps von Ingo helfen sicher das Problem einzugrenzen. Zusätzlich haben wir noch einen Diagnose-Modus in Threema Web: https://web.threema.ch/troubleshoot/
Laufen dort alle Tests erfolgreich durch?
Danke für den Tipp mit dem Diagnose-Modus. Nein, es laufen nicht alle Tests durch: Are WebRTC DataChannel connections possible? scheint den Test nicht beenden zu können, es ist andauernd die Aktivitätsanzeige zu sehen und im grauen Kasten darunter:
RTCPeerConnection available
RTCDataChannel available
Als letztes steht:
Does TURN work?
No
It looks like TURN traffic is being blocked by your firewall.
Without TURN, connections can only be established if your computer
and your phone are in the same network.
Results:
mit leerem grauen Kasten. An meiner Firewall sollte es nicht liegen, denn mit Opera funktioniert es ja. Auf einem Zweitrechner mit gleichem Betriebssystem (opensuse tumbleweed x64) habe ich noch eine gespeicherte Sitzung, die sich starten lässt. Habe nicht ausprobiert, diese zu löschen und eine neue zu erstellen, weil ich diese Sitzung nicht auch noch verlieren möchte. Ach ja, Telefon und Rechner befinden sich im gleichen (häuslichen) Netz.
PS: Sorry, dass ich jetzt erst antworte. Ich dachte, ich bekäme eine Email, wenn jemand auf meine NAchricht antwortet.
-
Seit meinem letzten Firefox-Update kann ich keine Threema-Web-Sitzung mehr initiieren. Es scheint ein FF-Problem zu sein, da ich mit Opera keine Probleme hatte. Auch ein Löschen des FF-Profils inklusive aller plugins bringt keine Abhilfe. Wenn ich den QR-Code scanne, fängt der runde Fortschritts-„Balken“ in FF an fortzuschreiten, bei 60% ist aber Schluss und es kommt die Meldung „Verbindungsaufbau scheint länger zu dauern als normal …“
