[ANNOUNCE] GraphTFT 0.0.12

Hallo,

ich nehm an, dass steht irgendwo in irgendeiner doku, aber wie bekomme ich die icons für das touch-tft-plugin wieder von deinem (horchi) deep-blue skin weg?

michi

Zitat

Original 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:

Code

Feb  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

Alles anzeigen

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

Zitat

Originally posted by horchi
Hi JurKub,

Ich habe die PIDs der drei Graphtft Prozesse (Threads) aus deinem top gegrept:

Code

:~> grep 5941  top.txt
 5941 root     S      77256  4439  0.4 19.9 vdr
~> grep 5962 top.txt 
 5962 root     S      77256  5942  0.0 19.9 vdr
~> grep 5963 top.txt 
 5963 root     S      77256  5942  5.9 19.9 vdr

zwei davon brauchen 0,x% der CPU und einer 5,9%, das sollte eigentlich kein Problem sein und ist m.E. völlig normal, oder übersehe ich hier etwas? Insgesammt scheint mir die CPU nicht so extrem belastet zu sein. Hast du ggf. ein io Problem mit der HD bei 3 gleichzeitigen Aufnahmen. Mit sar siht man u.a. auch den Wait/IO.

Gruß
horchi

Alles anzeigen

Hi horchi,

erst mal vielen Dank für deine Hilfe bei der Suche nach meinem Problem !

Ich hab mal das syslog und das Log von mpstat, sar hab ich nicht hinbekommen, angehängt. Ich hab mal 3 Aufnahmen nacheinander gestartet.

Das CPU Problem hab ich ohne graphtft nicht. Da geht die Last zwar auch hoch aber nur bis ca. 70%. Mit graphtft auf 100% und das OSD ist schon bei 1-2 Aufnahmen sehr träge.

Bis denne
JurKub

... das lässt ja hoffen

Hast du schon mal über das

Anzeigen von Aufnahme + Episode bei Wiedergabe von Aufnahmen

nachgedacht. Wenn eine regelmäßige Aufnahme keinen Episodentitel hat ist die Anzeige im graphtft leer.

cu
JurKub

was ist eigentlich besser, dass TFT an eine 2. FF Karte oder an eine Grafikkarte mit TV-Out anzuschließen?

cu
JurKub

Hi,

ich hab mir auch extra eine Grafikkarte die hier im Board empfohlen wird ei eBay geschossen. Eine Asus - V7100

Ich bekomme den Trauerrand aber mit nvtv nicht in den Griff. Entweder hab ich einen Trauerrand oder am Rand fehlt ein Stück der Grafik.

JurKub

Habe bei einem Freund vdr 1.5.1 installiert und versuche grad graphTFT-0.0.16 zu installieren.

Leider funktioniert der mitgelieferte Patch nicht und das Plugin kompiliert nicht.

Hat jemand einen funktionierenden Patch oder eine Idee, wie ich es zum Laufen bekomme?

btw: Ich habe keinen Thread zum graphTFT-0.0.16 gefunden.

Gruß,

Matthias

Ausgezeichnet. Das hat geklappt. Der patch ist mir noch nie aufgefallen. Erleichtert doch einiges.

Jetzt bekomme ich allerdings ein

make[1]: Entering directory `/usr/src/vdr-1.5.1/PLUGINS/src/graphtft-0.0.16'
g++ -g -O2 -Wall -Woverloaded-virtual -fPIC -g -ggdb -O0 -c -DUSE_DOLBYINREC -DUSE_GRAPHTFT -DUSE_JUMPPLAY -DUSE_NOEPG -DUSE_OSDMAXITEMS -DUSE_PINPLUGIN -DUSE_REPLACEMENUS -DUSE_YAEPG -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"graphtft"' -DHAVE_IMAGE_MAGICK -DHAVE_IMLIB -DHAVE_SOFTMPEG -I../../../../DVB/include -I../../../include -I../../../../DVB/include -I. -I./imlibrenderer -I./imlibrenderer/fbrenderer -I./imlibrenderer/dvbrenderer -I./dfbrenderer -I./imlibrenderer/dmyrenderer -I/src -I/usr/include/ffmpeg -o transfer.o transfer.c
transfer.c: In constructor 'cGraphTFTTransfer::cGraphTFTTransfer(Renderer*, const cChannel*)':
transfer.c:22: error: no matching function for call to 'cReceiver::cReceiver(int, int, int, const int*, const int*)'
../../../include/vdr/receiver.h:41: note: candidates are: cReceiver::cReceiver(tChannelID, int, int, const int*, const int*, const int*)
../../../include/vdr/receiver.h:17: note:                 cReceiver::cReceiver(const cReceiver&)
make[1]: *** [transfer.o] Fehler 1

Habe den graphtft-Patch in der Make.config aktiviert. Daran sollte es jetzt nicht mehr liegen. Imlib2, ffmpeg und libavcodec(-dev) sind installiert.

Edit: Habe die Frage auch im [ANNOUNCE] VDR Extensions Patch v.23 Thread gepostet.

Gruß,

Matthias

ich hätte mal ein feature request:

Wäre es möglich, oder geht es vlt schon und ich weiß nur net wie, dass graphtft im Verbindung mit dem radio-plugin wahlweise nicht das EPG (was meistens ohnehin nicht sehr aussagekräftig ist) anzeigt sondern die RDS-Informationen, Radiotext, die das radio-plugin via OSD anzeigt?

Grüße Michi

Ich hätte da auch noch so 2-20 Ideen Nur denke ich dass das mit der aktuellen Arbeitsweise eher nichts wird.

- Bild in Bild (Nach TimeOut Fernsehbild als kleines Fenster anzeigen
- bei Medienwiedergabe generell evtl im Ordner befindliche Bilder anzeigen
- Visualisierung bei Musik (ähnlich XBMC)

Da aber meines Wissens nach im Moment jedes Bild einzeln erstellt und als Bild ans Display geschickt wird , geht das wohl so nicht, dafür müsste es ein richtiges Anwendungsdisplay sein, was die Flexibilität der ANzeigegeräte einschränken würde und das Skinnen wahrscheinlich auch ...

Hey möchte mich gerne bedanken, super plugin.
Hab da allerdings noch ein Problem:
Konf: nvidia, twinview, graphtft über frontend.
mp3ng zeigt mir keine Titel oder Interpreten während dem abspielen an, aufm osd tv kein Problem....
Gibts da Abhilfe?
Zum zweiten eher eine Feststellung das scrollen durch die Menüs ist spührbar langsamer geworden... ists meine Installation oder liegts wirklich am graphtft?
Vielen Dank cu Peje

Hi,

die hohe CPU-Last und damit der träge Aufbau der Menus scheint von der Skalierung der Bildes vor der Ausgabe in den Framebuffer zu kommen. Mit meinem EPIA-Board ist mit graphtft nicht mal mehr das unterbrechungsfreie Abspielen von MP3's möglich. Ohne diese Skalierung geht alles prima. Nur leider muß man dann die Skins von Hand an die Displaygröße anpassen. Ich habe mal einen kleinen Patch gemacht, der die Sklalierung abschaltet, im Makefile ist die Größe des Framebuffers anzupassen.

Stefan

Zitat

Original von stegoOhne diese Skalierung geht alles prima.

Etwas Beschleunigung könnte dem OSD gut tun ... seit graphtft ist es schon recht träge

Zitat

Nur leider muß man dann die Skins von Hand an die Displaygröße anpassen.

Könntest du kurz auflisten, was alles angepasst werden muss?
Evtl. würde es ja auch Sinn machen, die Skins angepasst an gängige Auflösungen zum Download zur Verfügung zu stellen!?

Zitat

Ich habe mal einen kleinen Patch gemacht, der die Sklalierung abschaltet, im Makefile ist die Größe des Framebuffers anzupassen.

D.h., wenn ich graphtft eh nur auf 800x600 laufen habe, sollte ich das wohl mal probieren, oder?

Lg
Roman