Hallo Gemeinde,
Ich habe ein sehr grosses Projekt von XE2 auf Delphi 11.3 migriert. Wobei es eher eine Neuentwicklung ist welche auf den Erfahrungen der alten Applikation abstützt. Es handelt sich um einen Client welcher mit einer Fremd
API H264 Videostreams mit bis zu 50fps anzeigen kann. Die alte XE2 Applikation benutzte dazu ein
ActiveX des Herstellers. Dieses ist End of Life. Neu wird eine 64bit C
DLL API benutzt. Die Entwicklung dauerte ca. ein halbes Jahr. Nun sind wir im Release Candidate Test beim Kunden. Weil wir verfügen nur über ca. 20 Kameras hier. Beim Kunden sind es einige tausend.
Der Client wird auch vom Server fremdbeschaltet (Videowall Betrieb). Hier kann z.B. in einem Rutsch ein Aufschaltbefehl für 36 Kameras (mit der entsprechenden Splitschaltung) kommmen. Ein paar Sekunden später ein 4-er Split mit anderen Kameras usw. Meistens funktioniert das alles sehr geschmeidig. Manchmal aber eben nicht. Es gibt zwei Phänomene.
1. Manchmal bleibt die Applikation mitten in einer Aufschaltung stehen. Es sollte z.B. ein 9-er Split aufgeschaltet werden. Die ersten 5 Kameras streamen bereits live. Bei den letzten 4 ist noch der Verbindungsaufbauscreen zu sehen. Die Applikation kann noch an der Kopfzeile gepackt und leicht bewegt werden. Die Streams streamen mit den vollen Auflösung. Wenn in die Applikation geklickt wird erscheint "not responding". Alle Callbacks von der
API kommmen in Threads. Diese sind alle abgesichert und werden mit der
VCL synchronisiert. Mein erster Verdacht war das TThread.Synchronize. Dann habe ich alles auf PostMessage umgestellt. Mit dem gleichen Resultat. In die
API muss ein
Handle der (Panel-) Komponenten mitgegeben werden. Auf diese zeichnet dann die
API. Ich habe 100-e Seiten gelesen und auch verstanden dass z.B. TWinControl.Handle Getter nicht Threadsafe sind. Deshalb habe ich auch die synchronsiert bzw. in Variablen gespeichert. Ebenso ein krass intensives Logging wurde eingeführt. Das sieht man jeweils meisten als letzten Logeintrag ein PostMessage an das Hauptformular welches dort nicht mehr ankommt. Testweise habe ich auch einen Timer mit einem 5Sekunden Interval Log platziert. Auch dieser hört dann in dem Moment auf. Es sieht also so aus dass das Messaging den Betrieb komplett eingestellt hat. Die CPU Auslastung ist auf 2% in diesem Zustand. Das rendering der Streams passiert zu 100% auf der GPU.
2. Die Walls welche durchlaufen sind manchmal nach einer Woche weg. Im Windows Eventlog ist das eine
Exception in der NTDLL.DLL zu finden. Ich habe schon mit Eureka Log kompiliert. EurekaLog kriegt den Absturz nicht mal mit.
Tja. Guter Rat ist teuer. Hat jemand eine Idee oder schon mal was ähnliches erlebt? Das Problem ist auch: Es könnte an der
API liegen? Aber wie kann ich das belegen? Wie kann ich die Ursache dieser Symptome finden? Einmal konnte ich mich per RemoteDebugger auf einen stehenden Client verbinden. Im Hauptthread an den Stellen der Messages ist (logischerweise) aber nichts gekommen. Im Processexplorer sehe ich haufenweise Threads vor allem der
API DLLs. In meinem Programm sehe ich anhand der ID nur noch einige und in die bin ich mit Breakpoints rein. Der Hauptthread rödelt mit 0.1% CPU dahin. Da war nichts. Was ist da los?
Vielen Dank für jeden Input
Gruss Werner
Die obige Aussage repräsentiert meine persönliche Meinung.
Diese erhebt keinen Anspruch auf Objektivität oder Richtigkeit.