ZitatAlles anzeigenOriginal von horchi
Hi,
das Plugin hat drei Threads, den des Plugins selbst, einen für die TCP Kommunikation und einen für den Aufbau des Display. Der tcp Thread sollte solange das Frontend nicht angemeldet ist keine Last verursachen. In Verdacht habe ich eigentlich nur den Display Thread. Die PID der einzelnen Threads findest du auch im log, in der eckigen Klammer:
CodeFeb 4 13:14:42 linvdr vdr: [3348] starting plugin: graphtft Feb 4 13:14:42 linvdr vdr: [3362] GraphTFT plugin tcp communication thread started (pid=3362) Feb 4 13:14:42 linvdr vdr: [3363] GraphTFT plugin display thread started (pid=3363)
Da ich diesen Bereich in deinem log nicht finden kann, ist es mir so nicht möglich die beiden Prozesse welche (entsprechen dem top) die CPU belasteten zu identifizieren.
Das log lässt vermuten, dass von 10:21:59 bis 10:22:51 im Menü hin und her geschaltet wurde, dabei muss immer das TFT Bild neu gerendert werden was Last erzeugt. Im letzten log Abschnitt (10:22:52 - 10:32:45) wird die Hauptschleife des Display Treads im Sekundentakt durchlaufen. Der Sekundentackt lässt auf die Wiedergabe einer Aufnahme schließen, bei der Wiedergabe wird die Anzeige zwecks Aktualisierung der Fortschrittsanzeige jede Sekunde neu aufgebaut. Das würde die Last des Display Treads erklären. Lief eine Wiedergabe?
Bitte prüf auch nochmal zu welchem Prozess die Pid's gehören.
horchi
Hi horchi,
ich hab nochmal ein komplettes Log und top gepostet.
Es werden sofort beim VDR-Start 3 Aufnahmen gestartet.
Die Timer hatte ich vorher schon eingerichtet.
Es läuft jetzt auch keine Wiedergabe einer Aufnahme.
cu
JurKub