Jetzt war die 81.x verfügbar. Danke
Super, danke für die Rückmeldungen!
1 Like
Naja, es klingelt halt nicht kurz nach sondern etwa 10-15 Sekunden. Die Rufannahme im Auto klappt auch selten bis garnicht. Ich muss immer in der App annehmen.
Deswegen habe ich es die meiste Zeit auf GSM stehen und sehe dann leider keine Rufnummern.
Ich war schon am überlegen deswegen ein iphone zu kaufen da anscheinend die Android-Version sehr stiefmütterlich behandelt wird. Zumindest wurde mir zugetragen es funktioniere unter iOS.
Der jetzige Status auf Android ist auch sehr ernüchternd:
Anruf geht ein, App signalisiert überhaupt nicht, dafür klingelt Smartwatch und Bluetooth Headset.
Rufannahme ist weder am Headset noch an der Smartwatch möglich. Anruf klingelt einfach 15 Sekunden lang fröhlich weiter obwohl aufgelegt.
Beliebig reproduzierbar.
@b.schliekmann Spontan lassen sich derartige Probleme nicht nachstellen. Um hier weiterhelfen zu können bitte das Problem mit eingeschaltetem Debug Modus nachstellen und mir die Support Info per PN zuschicken.
Das Problem ist, dass die App im Debug-Modus abstürzt oder gar nicht erst aufwacht.
Habe eben noch einen Fehler im Client (v81.D1998) gefunden.
Wenn ich eine Rufnummer kopiere und per rechte Maustaste ins Wählfeld einfügen möchte, stürzt der Client ab.
Füge ich die Nummer mit STRG+V ein funktioniert es.
Support Info hätte ich falls benötigt. 
Edit: Ich habe die Nummer aus meinem OneNote kopiert.
Der Fehler tritt auch nur auf wenn ich die Nummer (egal welche) direkt in OneNote kopiere und einfügen will. (Nur per klick, STRG+V geht immer)
Aus Outlook oder Chrome gibts das Problem nicht.
gerade unter w10 mitn gleichen client gestestet: meiner stürzt nicht ab… nr die ich kopiert hatte: +49 (0)211 8xx xx x0
@pkraus danke für den Nachtrag, genau das habe ich vermutet, dass er auf die “Herkunft” ankommt. Vermutlich sind hier irgendwelche Formatierungen oder ähnliches im Spiel, was in unserem Client dann zum Problem führt.
Wir werden uns das Problem ansehen, danke fürs melden!
1 Like
Hallo @hazington,
Diese Aussage ist leider nur begrenzt hilfreich. Magst du uns evtl. Logs zukommen lassen wenn der Debug Mode crasht. Dann können wir ja zuerst dieses Problem reparieren und uns dann um das nicht-reproduzierbare Label-Problem kümmern.
Grüße,
Jan
Ich weiß, dass das nicht hilfreich ist. Ich weiß nur leider ebenso wenig, wie ich helfen kann. Denn ohne den Debug-Modus bekomme ich keine Log-Files oder gibt es einen anderen Weg, wie ich dich mit einem nicht-gerooteten Android-Telefon mit Log-Files versorgen kann?
Diese Probleme sind enorm undankbar, weil man sie nicht reproduzieren kann. Wir haben eigentlich immer die gleiche Ausgangslage, und zwar, dass gelegentlich keine Labels angezeigt werden und zwar so, dass weder ein Muster erkennbar ist, noch, dass dies gezielt reproduziert werden kann. Schalten wir also den Debug-Modus ein, passieren zwei Dinge:
1.) Bei eingehenden Anruf stürzt der Client ab und der Debug-Modus wird beendet. Es gibt kein Log-File.
2.) Mit Debug-Mode stürzt das Telefon nicht ab, jedoch erscheinen dann auch immer die Labels.
Sollte es mir jemals gelingen, einen Anruf ohne Labels im Debug-Modus aufgezeichnet zu bekommen, dann sende ich dir sofort die Log-Files zu. Einen anderen Weg sehe ich leider nicht.
Hallo @hazington,
Das kann so eigentlich nicht sein. Das Debug-Mode Flag ist ein persistentes Setting in der Datenbank, d. h. selbst wenn der Client hier crasht, bleibt beim nächsten Start der Debug Modus eingeschaltet. Und wie gesagt, wenn der Client bei eingeschaltetem Debug Modus stürzt, wäre das auch ein Bug den wir beheben sollten. Ältere Debug-Logs bleiben auch eine Zeitlang erhalten, selbst wenn der Debug-Modus zwischendurch ausgeschaltet war.
Also wenn das bei dir so auftritt, schalte bitte sofort nach dem Crash den Debug Modus wieder ein und sende mir die Supportinfos zu. Vielleicht kommen wir ja so weiter.
Grüße,
Jan
pascom Client v81 BETA (81.D2004)
German
- Windows: Verwendung der Kernel-Streaming-API für Webcam-Support standardmäßig deaktiviert, dies führt zu Stabilitätsproblemen. Falls notwendig kann das Plugin mit
--enableWinksbzw der UmgebungsvariablePC_ENABLE_WINKSwieder aktiviert werden - Anpassungen am Logging
- Kleinere Stabilitätsverbesserungen
- Downgrade auf pjsip 2.10
English
- Windows: Usage of the kernel streaming API for webcam support is disabled by default. If necessary it can be enabled again by using the
--enableWinkscommandline parameter or thePC_ENABLE_WINKSenvironment variable - Adjustments to the default log levels of some messages
- Some smaller stability improvements
- Downgrade to pjsip 2.10
Unter Android 12 (Pixel 4) kam es nun zum wiederholten Male vor, dass der Client eingefroren ist, während er versuchte sich bei einem eingehenden Anruf mit dem Server zu verbinden. Mit eingeschaltetem Debug-Mode ist es leider nicht reproduzierbar. Könnte dir die SupportInfo dennoch privat zusenden, wenn es hilft. Die Akku-Optimierung ist ausgeschaltet und die App hat unbegrenzte Nutzungsrechte für mobile Daten. Mehr geht nicht.
Grundsätzlich frage ich mich, warum der Start der Android Anwendung noch immer bis zu 20 Sekunden dauert, selbst dann, wenn kein Anruf eingeht. Ja, ich sehe keine Ladeansicht mehr, dennoch hängt die gesamte Anwendung bis zu 20 Sekunden, ehe ich etwas tun kann. Gefühlt scheinen die mobilen Anwendungen keine Priorität zu haben, denn sonst müssten sie mindestens so schnell und so stabil laufen wie der Desktop-Client. Der verzögerte Push ist eine Sache, jedoch erhält das Smartphone den Push und brauch trotzdem 10-20 Sekunden, bis überhaupt etwas geht. Manchmal klappt nicht einmal das.
Ich kann mir irgendwie nicht vorstellen, dass der Verbindungs-Aufbau und die Authentifizierung in der Telefonanlage so lange dauern und selbst wenn, sollte dieser Vorgang die Benutzeroberfläche nicht blockieren. Es ist mittlerweile die 2. oder 3. Beta seit der Einführung des Offline-Modus, jedoch ist die App gefühlt dadurch noch langsamer geworden. Die Authentifizierung sollte eigentlich nur wenige ms dauern. Ob die App an der Authentifizierung oder an der Synchronisation scheitert, ist gar nicht zu erkennen, da ich ja nur die 3 Punkte oben sehe und sich mit denen zeitgleich der Online-Zustand ändert.
Aktuell ist die mobile App nicht praxistauglich. Ich weiß nicht, ob ich der einzige bin, der das so sieht. Mit der Desktop-Anwendung bin ich vollkommen zufrieden. Mobil hingegen habe ich intern schon mehrfach angestoßen, die App zu entfernen, da ein realistischer Praxis-Betrieb damit nicht möglich ist. Wir behelfen uns mittlerweile sogar dadurch, dass wir mit der Caffeine App die pascom Anwendung dauerhaft offen halten, da wir eingehende Anrufe sonst nicht annehmen können. Kaum jemand bleibt X + 20 Sekunden in der Leitung.
Ich weiß, langsam wird die Kritik am mobilen Client anstrengend, aber ich hoffe, ihr versteht auch, dass ich nicht das Gefühl habe, dass dort nennenswert dran gearbeitet wird. Grundsätzlich ist das, was ihr hier macht ja auch richtig gut. Etwas mehr Fokus und eine konkurrenzfähige mobile App würden sicherlich helfen.
Dem Teil kann ich nur beipflichten. Allerdings scheint die iOS Variante auch nicht gut zu funktionieren lt. meinen Kollegen mit Apple-Telefon.
Aber unter Android bin ich auch sehr unzufrieden. Mit Umschalten auf GSM ist es noch ganz okay. Ansonsten nicht nutzbar.
Hallo @hazington , @b.schliekmann,
danke für euer Feedback. Dies ist jedoch eine Off Topic Diskussion über die gefühlte Unzufriedenheit mit der Mobile App und hilft beim Debug der BETA nicht weiter.
Generell stecken wir jede Menge Energie in unsere Mobile-Plattformen und sind jederzeit daran interessiert diese weiter zu verbessern. Ich bin Android User auf einem Samsung. Kaltstartzeit der App: 2 Sekunden, bis ich interagieren kann. Nach 3 Sek ist der Sync durch. Start der App in Memory: SOFORT, 2 Sek, bis der Sync durch ist. Der Sync blockt die App in keinem der Fälle.
@hazington Block die App tatsächlich jedes Mal 20 Sekunden biete ich dir gerne an das über den Support zu debuggen da wir dieses Problem in keinem unserer Test nachvollziehen können.
LG
Mathias
Hallo Mathias,
es ist ja keine gefühlte Unzufriedenheit. Es ist eine App die auch in der aktuellen BETA die genannten Probleme aufweist. Daher finde ich es nicht gerade offtopic. Leider wird halt nicht konstruktiv darauf eingegangen. Ich kann schon verstehen, dass das lästig erscheint. Aber entweder hat man halt den Anspruch die App zu verbessern oder weist darauf hin, dass das Stand der Technik ist und man es eben nicht verbessern wird. Der aktuelle Stand ist (aus meiner Sicht), dass man eigtl. mehr oder weniger ignoriert wird. Daher entsteht dann halt der Eindruck es ist eine vernachlässigte Plattform.
Mir wurde nahegelegt ein Ticket zu eröffnen. Das werde ich jetzt tun.
1 Like
Hallo zusammen,
@hazington:
es hat zwar eine ganze Weile gedauert, aber wir konnten zum Thema “Labels fehlen manchmal” tatsächlich einen möglichen Bug identifizieren. Ein Fix ist in v84 Beta enthalten, magst mal testen und im dortigen Thread Feedback geben?
@mseyffert: Der Jabra-Headset Support sollte nun auch nach dem Standby unter Linux noch funktionieren mit v84.
Grüße,
Jan
Ich kann den Fehler mittlerweile reproduzieren. Der Fehler tritt immer dann auf, wenn das Handy gesperrt ist und pascom aus dem Hintergrund aufwacht. Wenn dann der Anruf angezeigt wird, fehlen immer die Label. Ich habe deswegen Freitag auch eine SupportInfo aufzeichnen können und einen Screenshot gemacht. Soll ich dir die Datei dennoch zusenden? Oder glaubst du, der Fehler ist durch v84 gefixt?
Hallo @hazington,
ich glaube das v84 das Problem tatsächlich löst. Deine Beschreibung passt gut zur Codeänderung die wir gemacht haben. Bitte teste zuerst v84, und wenn es nicht klappt, lass uns dort weiter debuggen.
Grüße,
Jan