[ANNOUNCE] VNC Server für graphtft Remoteanzeige

    Hi zusammen,


    da ich noch ein altes SIMpad herumliegen hatte, dem ich einen Sinn geben wollte und mir das genial SIGTS-Tool durch den benötigten tomcat zu kompliziert war, habe ich dem graphtft Plugin einen VNC-Server spendiert. Dadurch ist es möglich sich mit einem beliebigen VNC-Client zu graphtft zu verbinden und das Bild anzuzeigen. Anregung hierzu war der im ffnetdev Plugin integrierte VNC-Server und das touchtft Plugin.


    Features:

    • Anzeige des graphtft-Screens auf beliebigen VNC-Clients im Netz (auch mehreren)
    • Bedienung des graphtft im Stil von touchtft über die Maus/Touchpanel/etc. am VNC-Client
    • Bedienung des vdr über die Tastatur am VNC-Client
    • VNC-Server kann beliebige Auflösung haben
    • Kein Framebuffer/DirectFrameBuffer o.Ä. nötig
    • Es werden effizient die tatsächlichen Änderungen am graphtft verfolgt, um mit VNC so sparsam wie möglich mit dem Netzwerk umzugehen. Das ist besonders bei WLAN-Clients nötig.
    • Passwort-Authentifizierung. Man kann im config Verzeichnis des Plugins zwei Passwort-Datei anlegen um den Zugriff auf das VNC zu schützen. Eine Datei legt das control-Password fest, mit dem auch die Bedienung des VDR möglich ist. Die zweite Datei enthält das view-Passwort, mit dem man zwar sehen, aber nicht bedienen kann. (siehe unten bei Bedienung)


    Installation:

    • graphtft-0.0.16 wie gewohnt entpacken
    • Patch im Anhang mit gunzip -c graphtft-vnc.diff.gz | patch -p1 anwenden
    • libvncserver isntallieren (Gentoo: emerge libvncserver, verfügbar unter http://libvncserver.sourceforge.net/). Beim Übersetzen von libvncserver ist es auf 64-bit Systemen eventuell nötig, das Compiler-Flag "-fPIC" anzugeben, siehe dazu Post von Frank weiter unten.
    • Im Makefile HAVE_VNC=1 einkommentieren und alle anderen Optionen wie gewohnt einstellen
    • Plugins wie gewohnt übersetzen
    • Beim vdr-start das Plugin laden und VNC-Server starten. Den VNC-Server aktiviert man mit -v <port>. Ein Beispiel mit Framebuffer wäre also vdr -P"graphtft -v 20000 -d /dev/fb0". Wenn man das Plugin rein zum Betrieb mit dem VNC-Server verwenden will, muss man -d dummy mit angeben, um die device-autodetection zu unterdrücken, also zum Beispiel vdr -P"graphtft -v 20000 -d dummy". Um die Fernbedienungs-Funktion über die VNC-Client-Tastatur zu aktivieren, ist die Option -r zusätzlich mit anzugeben, siehe auch unten unter Bedienung.
    • mit vnc-client auf den Port verbinden, z.B: vncviewer localhost::20000


      [/list=1]


      Bedienung:

      • Die linke Maustaste ist klick, mittlere ist "Menü", rechte ist "Back" und das Scrollrad "Up" bzw. "Down".
      • Im graphtft-Plugin-Setup die gewünschte Auflösung für den Server einstellen. Danach ist jeweils ein vdr-Neustart fällig, weil der vnc-Server dabei nicht neu gestartet wird.
      • Zusätzlich gibt es die Möglichkeit über VNC den VDR mittels Tastatur zu steuern. Dazu muss man als Kommandooption -r mit angeben. Beim ersten Start fordert VDR dann zum Lernen der Fernbedienung auf. Man muss also als erstes VDR starten, dann einen VNC-Client und von dort aus die Tasten anlernen (des geht allerdings nur, wenn man das Original-OSD sieht, z.B. über den Fernseher oder den ffnetdev VNC Server, da die Lern-Meldungen nicht auf dem graphtft landen). Die Tastenbelegung landet in der remote.conf als graphtftvnc.KEY. Dort kann man sie auch per Hand editieren oder komplett löschen, wenn man neu lernen möchte.
      • Die Passwort-Dateien heißen control.pass und view.pass und man kann sie mit dem beim libvncserver enthaltenen Tool storepasswd <passwd> <pfad> erzeugen. Unter gentoo wird das tool mit installiert und steht im Pfad zur Verfügung, bei der libvncserver source-Distribution ist es im Verzeichnis examples enthalten. Ein Beispielaufruf zum Erzeugen der Passwörter wäre storepasswd ctrlPasswd /video/plugins/control.pass bzw. storepasswd viewPasswd /video/plugins/view.pass. Leider überträgt VNC die Passwörter im Netz im Klartext, das ist also hächstens im lokalen Netz zu empfehlen. Wenn Ihr das VNC übers Internet zugänglich machen wollt, solltet ihr unbedingt über ssh o.Ä. tunneln, da weder der VNC-Server noch das Protokoll ausreichend sicher sind.


      TODOS:
      [list]

    • Neustart nach Änderung der Auflösung abschaffen


    Credits:
    ffnetdev für die VNC-Idee, TouchTFT für die Klick-Idee, libvncserver für den Server und natürlich allen graphtft Entwicklern. TightVNC für die Idee und ein bisschen Code für die effizientere VNC Netzwerk Übertragung.


    Dieses Patch ist als Beta zu sehen und ich freue mich über jegliche Art von Lob und Tadel. Bitte meldet auch den (hoffentlich) erfolgreichen Einsatz!


    Viele Grüße,


    Markus


    PS.: Ich hab gerade gemerkt, dass ich Euch versehentlich noch einen anderen Patch für graphtft mit unterjuble: Eine neues Log-Device um auch vom graphtft aus den "standart" - vdr Log-Weg zu benutzen (im Setup-Menü, Log Device = vdr).

    Hallo Markus,


    die Idee ist sehr gut !!!


    Ich habe gerade mal kurz getestet. Was mir aufgefallen ist:


    1. auf einem x86_64 System muss man
    LibVNCServer-0.8.2/libvncserver/Makefile anpassen:
    +CPPFLAGS = -fPIC
    sonst kann man das gepatchte graphtft nicht übersetzten (-fPIC Error message)


    2. die Bedienung der Touchbuttons funktioniert auch mit der Maus - sehr, sehr gut!!!


    3. Leider funktioniert mit dem veränderten graphtft mein TFT nicht
    -P"graphtft -d vdr/0"


    4. Mit
    -P"graphtft -d vdr/0 -d vnc/20000" funktioniert nur Output über vncclient


    Daher folgender erster Vorschlag:
    Patche graphtft so, dass man TFT und vncclient gleichzeitig benutzen kann.
    -- evtl so ein Aufruf: -P"graphtft -d vdr/0 -D vnc/20000"


    Gruß Frank

    Hallo Frank,


    freut mich, dass Dir die Idee gefällt.


    Zu Deinen Punkten:


    1. Super, dass Du das gleich hier gepostet hast, das Problem werden bestimmt auch noch andere haben und ich besitze leider keinen 64-bit Rechner.


    2. So war das gedacht :) Und sobald ich mit meinen Tests fertig bin, sogar mit der Tastatur vom VNC-Client aus (verhält sich dann wie eine Fernbedienung, die man anlernen muss)


    3. Das ist wirklich sehr mysteriös. Ich hab die DvbRenderer-Funktionen nicht angefasst und im Programmfluss wird auch zuerst auf den Dvb-Renderer geprüft. Ich habe leider keine zweite FF-Karte, noch hab ich den DFB, daher konnte ich das auch nicht testen. Der normale Framebuffer funktioniert auf jeden Fall noch. Kannst Du bitte mal zwei Sachen testen: 1. Im Makefile HAVE_VNC wieder auskommentieren, neu übersetzen und dann schauen, ob die Ausgabe auf der DVB wieder läuft. 2. Schick mir doch bitte mal das Log vom VDR-Start bis ca. 5 Sekunden danach. (Mit eingeschalteten HAVE_VNC und mit -P"graphtft -d vdr/0" und im graphtft-plugin-setup Loglevel auf 10)


    4. Das habe ich mir auch schon überlegt, leider ist das nicht ganz einfach, da das Konzept des Plugins nur einen Renderer (Ausgabedevice) gleichzeitig vorsieht. D.h. dass immer nur eine Ausgabe gleichzeitig möglich ist, also fb, dfb, vdr oder vnc. Im Moment "gewinnt" derjenige, der als letztes in den Parametern steht, in Deinem Fall also VNC. Ich mach mir mal Gedanken und schau ob ich da eventuell eine Lösung finde, so dass mehrere Renderer gleichzeitig laufen können (riecht nach viel Arbeit ;-)).


    Viele Grüße,


    Markus

    So, nachdem mir das keine Ruhe gelassen hat, habe ich zum einen die Tastatursteuerung über VNC implementiert und zu anderen VNC als Option zusätzlich zu einem der anderen Devices hinzugefügt. Man kann also jetzt den VNC-Server parallel zu einem angeschlossenen Display betreiben.


    Ich werde den ersten Post entsprechend ändern und auch dort das aktuelle diff wieder mit anhängen.


    Den VNC-Server aktiviert man jetzt nicht mehr mit der -d Option sondern mit -v <port>. Ein Beispiel mit Framebuffer wäre also vdr -P"graphtft -v 20000 -d /dev/fb0". Wenn man das Plugin rein zum Betrieb mit dem VNC-Server verwenden will, muss man -d dummy mit angeben, um die device-autodetection zu unterdrücken, also zum Beispiel vdr -P"graphtft -v 20000 -d dummy".


    Zusätzlich gibt es ab sofort die Möglichkeit über VNC den VDR mittels Tastatur zu steuern. Dazu muss man also Kommandooption -r mit angeben. Beim ersten Start fordert VDR dann zum Lernen der Fernbedienung auf. Man muss also als erstes VDR starten, dann einen VNC-Client und von dort aus die Tasten anlernen (des geht allerdings nur, wenn man das Original-OSD sieht, z.B. über den Fernseher oder den ffnetdev VNC Server, da die Lern-Meldungen nicht auf dem graphtft landen). Die Tastenbelegung landet in der remote.conf als graphtftvnc.KEY. Dort kann man sie auch per Hand editieren oder komplett löschen, wenn man neu lernen möchte.


    Auch dieses Patch ist wieder als Beta zu sehen und ich freue mich über jegliche Art von Lob und Tadel. Bitte meldet auch den (hoffentlich) erfolgreichen Einsatz!


    Viele Grüße,


    Markus

    Das Klicken im VNC auf Menüeinträge funktioniert nun auch. Allerdings nur mit einem passenden Theme. Zu empfehlen ist das touchtft Theme, das die nötigen Definitionen enthält. Die Themes Deepblue und beim poetter funktionieren auch, jedoch ist die Maus und Touchscreenunterstüzung dort noch nicht ganz so ausgereift (und klicken auf Menüeinträge geht im Moment nicht).

    Hallo Markus,


    der erste Schnelltest sieht halbwegs gut aus:
    - TFT und vncviewer funktionieren parallel
    - Anlernen der Tastatur funktioniert
    - Tastatur funktioniert
    - Touchbuttons funktionieren


    Ab und an erhalte ich mit:
    ./vdr -P"graphtft -d vdr/0 -v 20000 -r" -P"touchtft -d vdr/0"
    dmesg
    vdr[8311]: segfault at 00002aaaab1ad012 rip 00002abc29a763df rsp 0000000041408778 error 4


    Beim Versuch eine Aufnahme abzuspielen erhalte ich mit tail -f /var/log/messages:
    Mar 13 21:45:01 mardec /usr/sbin/cron[13335]: (mailman) CMD (/usr/bin/python -S /usr/lib/mailman/cron/gate_news)
    Mar 13 21:45:05 mardec vdr: [13330] OSD-Teletext: Error opening teletext file /vtx/C-133-2-10/430s.vtx: Too many open files
    Mar 13 21:45:06 mardec vdr: [13262] replay /video/Die_Simpsons_(191)/In_den_Fýgen_einer_Sekte/2007-02-26.20.10.50.99.rec
    Mar 13 21:45:06 mardec vdr: [13262] playing '/video/Die_Simpsons_(191)/In_den_Fýgen_einer_Sekte/2007-02-26.20.10.50.99.rec/001.vdr'
    Mar 13 21:45:06 mardec vdr: [13262] ERROR: /video/Die_Simpsons_(191)/In_den_Fýgen_einer_Sekte/2007-02-26.20.10.50.99.rec/001.vdr: Bad file descriptor
    Mar 13 21:45:06 mardec vdr: [13262] playing '/video/Die_Simpsons_(191)/In_den_Fýgen_einer_Sekte/2007-02-26.20.10.50.99.rec/001.vdr'
    Mar 13 21:45:06 mardec vdr: [13262] ERROR: /video/Die_Simpsons_(191)/In_den_Fýgen_einer_Sekte/2007-02-26.20.10.50.99.rec/001.vdr: Bad file descriptor
    Mar 13 21:45:06 mardec vdr: [13262] ERROR: /video/Die_Simpsons_(191)/In_den_Fýgen_einer_Sekte/2007-02-26.20.10.50.99.rec/resume.vdr: Too many open files
    Mar 13 21:45:06 mardec vdr: [13262] ERROR: /video/Die_Simpsons_(191)/In_den_Fýgen_einer_Sekte/2007-02-26.20.10.50.99.rec/info.vdr: Too many open files
    Mar 13 21:45:06 mardec vdr: [13262] ERROR: /video/Die_Simpsons_(191)/In_den_Fýgen_einer_Sekte/2007-02-26.20.10.50.99.rec/summary.vdr: Too many open files
    Mar 13 21:45:06 mardec vdr: [13262] playing '/video/Die_Simpsons_(191)/In_den_Fýgen_einer_Sekte/2007-02-26.20.10.50.99.rec/001.vdr'
    Mar 13 21:45:06 mardec vdr: [13262] ERROR: /video/Die_Simpsons_(191)/In_den_Fýgen_einer_Sekte/2007-02-26.20.10.50.99.rec/001.vdr: Bad file descriptor
    Mar 13 21:45:06 mardec vdr: [13262] playing '/video/Die_Simpsons_(191)/In_den_Fýgen_einer_Sekte/2007-02-26.20.10.50.99.rec/001.vdr'
    Mar 13 21:45:06 mardec vdr: [13262] ERROR: /video/Die_Simpsons_(191)/In_den_Fýgen_einer_Sekte/2007-02-26.20.10.50.99.rec/001.vdr: Bad file descriptor
    Mar 13 21:45:06 mardec vdr: [13331] receiver on device 2 thread ended (pid=13262, tid=13331)
    Mar 13 21:45:06 mardec vdr: [13279] ERROR: can't open filter handle on '/dev/dvb/adapter2/demux0'
    Mar 13 21:45:06 mardec vdr: [13273] ERROR: can't open filter handle on '/dev/dvb/adapter0/demux0'
    Mar 13 21:45:06 mardec vdr: [13276] ERROR: can't open filter handle on '/dev/dvb/adapter1/demux0'
    Mar 13 21:45:06 mardec vdr: [13262] switching to channel 55
    Mar 13 21:45:07 mardec vdr: [13262] ERROR: can't open filter handle on '/dev/dvb/adapter1/demux0'
    Mar 13 21:45:07 mardec vdr: [13262] ERROR: can't open filter handle on '/dev/dvb/adapter1/demux0'
    Mar 13 21:45:07 mardec vdr: [13262] ERROR: can't open filter handle on '/dev/dvb/adapter1/demux0'
    Mar 13 21:45:07 mardec vdr: [13262] ERROR: can't open filter handle on '/dev/dvb/adapter1/demux0'
    Mar 13 21:45:07 mardec vdr: [13262] ERROR: can't open filter handle on '/dev/dvb/adapter1/demux0'
    Mar 13 21:45:07 mardec vdr: [13262] ERROR: can't open filter handle on '/dev/dvb/adapter1/demux0'
    Mar 13 21:45:07 mardec vdr: [13262] ERROR: can't open filter handle on '/dev/dvb/adapter1/demux0'
    Mar 13 21:45:07 mardec vdr: [13262] buffer stats: 0 (0%) used
    Mar 13 21:45:07 mardec vdr: [13362] receiver on device 2 thread started (pid=13262, tid=13362)
    Mar 13 21:45:13 mardec vdr: [13262] replay /video/Abendschau/2007-02-22.19.20.99.99.rec
    Mar 13 21:45:13 mardec vdr: [13262] playing '/video/Abendschau/2007-02-22.19.20.99.99.rec/001.vdr'
    Mar 13 21:45:13 mardec vdr: [13262] ERROR: /video/Abendschau/2007-02-22.19.20.99.99.rec/001.vdr: Bad file descriptor
    Mar 13 21:45:13 mardec vdr: [13262] playing '/video/Abendschau/2007-02-22.19.20.99.99.rec/001.vdr'
    Mar 13 21:45:13 mardec vdr: [13262] ERROR: /video/Abendschau/2007-02-22.19.20.99.99.rec/001.vdr: Bad file descriptor
    Mar 13 21:45:13 mardec vdr: [13262] ERROR: /video/Abendschau/2007-02-22.19.20.99.99.rec/resume.vdr: Too many open files
    Mar 13 21:45:13 mardec vdr: [13262] ERROR: /video/Abendschau/2007-02-22.19.20.99.99.rec/info.vdr: Too many open files
    Mar 13 21:45:13 mardec vdr: [13262] ERROR: /video/Abendschau/2007-02-22.19.20.99.99.rec/summary.vdr: Too many open files
    Mar 13 21:45:13 mardec vdr: [13262] playing '/video/Abendschau/2007-02-22.19.20.99.99.rec/001.vdr'
    Mar 13 21:45:13 mardec vdr: [13262] ERROR: /video/Abendschau/2007-02-22.19.20.99.99.rec/001.vdr: Bad file descriptor
    Mar 13 21:45:13 mardec vdr: [13262] playing '/video/Abendschau/2007-02-22.19.20.99.99.rec/001.vdr'
    Mar 13 21:45:13 mardec vdr: [13262] ERROR: /video/Abendschau/2007-02-22.19.20.99.99.rec/001.vdr: Bad file descriptor
    Mar 13 21:45:13 mardec vdr: [13362] receiver on device 2 thread ended (pid=13262, tid=13362)
    Mar 13 21:45:17 mardec vdr: [13279] ERROR: can't open filter handle on '/dev/dvb/adapter2/demux0'
    Mar 13 21:45:17 mardec vdr: [13273] ERROR: can't open filter handle on '/dev/dvb/adapter0/demux0'
    Mar 13 21:45:18 mardec vdr: [13262] switching to channel 55
    Mar 13 21:45:18 mardec vdr: [13262] ERROR: /dev/dvb/adapter1/demux0: Too many open files
    Mar 13 21:45:18 mardec vdr: [13262] ERROR (dvbdevice.c,691): Too many open files
    Mar 13 21:45:18 mardec vdr: [13262] ERROR: can't set PID 511 on device 2
    Mar 13 21:45:18 mardec vdr: [13262] ERROR (dvbdevice.c,716): Bad file descriptor
    Mar 13 21:45:18 mardec vdr: [13262] ERROR (dvbdevice.c,723): Bad file descriptor
    Mar 13 21:45:18 mardec vdr: [13262] ERROR: failed to set PIDs for channel 55 on device 2
    Mar 13 21:45:18 mardec vdr: [13262] retrying
    Mar 13 21:45:18 mardec vdr: [13262] ERROR: /dev/dvb/adapter1/demux0: Too many open files
    Mar 13 21:45:18 mardec vdr: [13262] ERROR (dvbdevice.c,691): Too many open files
    Mar 13 21:45:18 mardec vdr: [13262] ERROR: can't set PID 512 on device 2
    Mar 13 21:45:18 mardec vdr: [13262] ERROR (dvbdevice.c,716): Bad file descriptor
    Mar 13 21:45:18 mardec vdr: [13262] ERROR: can't open filter handle on '/dev/dvb/adapter1/demux0'
    Mar 13 21:45:18 mardec vdr: [13262] ERROR: can't open filter handle on '/dev/dvb/adapter1/demux0'
    Mar 13 21:45:18 mardec vdr: [13262] ERROR: can't open filter handle on '/dev/dvb/adapter1/demux0'
    Mar 13 21:45:18 mardec vdr: [13262] ERROR: can't open filter handle on '/dev/dvb/adapter1/demux0'
    Mar 13 21:45:18 mardec vdr: [13262] ERROR: can't open filter handle on '/dev/dvb/adapter1/demux0'
    Mar 13 21:45:18 mardec vdr: [13262] ERROR: can't open filter handle on '/dev/dvb/adapter1/demux0'
    Mar 13 21:45:18 mardec vdr: [13262] ERROR: can't open filter handle on '/dev/dvb/adapter1/demux0'
    Mar 13 21:45:18 mardec vdr: [13262] buffer stats: 0 (0%) used
    Mar 13 21:45:18 mardec vdr: [13262] ERROR: /dev/dvb/adapter1/demux0: Too many open files
    Mar 13 21:45:18 mardec vdr: [13262] ERROR (dvbdevice.c,691): Too many open files
    Mar 13 21:45:18 mardec vdr: [13262] ERROR: can't set PID 32 on device 2
    Mar 13 21:45:18 mardec vdr: [13262] ERROR (dvbdevice.c,716): Bad file descriptor
    Mar 13 21:45:18 mardec vdr: [13363] transfer thread started (pid=13262, tid=13363)
    Mar 13 21:45:28 mardec vdr:
    [13273] ERROR: can't open filter handle on '/dev/dvb/adapter0/demux0'dle on '/dev/dvb/adapter2/demux0'



    Beim Start ist graphtft auf dem TFT OK, mit vncviewer bleibt "graphtft startet" stehen bis man eine angelernet Taste drückt.


    Nach dem Versuch, eine Aufnahme abzuspielen erhalte ich gerade:
    Mar 13 21:53:28 mardec vdr: [14390] ERROR (svdrp.c,126): Too many open files
    Mar 13 21:53:29 mardec vdr: [14390] ERROR (svdrp.c,126): Too many open files
    Mar 13 21:53:33 mardec vdr: [14390] ERROR (svdrp.c,126): Too many open files
    Mar 13 21:53:37 mardec vdr: [14401] ERROR: can't open filter handle on '/dev/dvb/adapter0/demux0'
    Mar 13 21:53:40 mardec vdr: [14390] ERROR (svdrp.c,126): Too many open files
    Mar 13 21:53:48 mardec vdr: [14401] ERROR: can't open filter handle on '/dev/dvb/adapter0/demux0'



    Gruß Frank

    Hallo Frank,


    Oh je, das wirft kein allzu gutes Licht auf den Patch... ;) Aber davon lasse ich mit nicht entmutigen.


    Ich hab zu dem Thema mal ein bisschen gegoogled und das Problem haben unabhängig von meinem Patch auch andere:


    graphTFT und "can't open filter handle" / "Too many open files"
    und
    http://www.mail-archive.com/vdr@linuxtv.org/msg01970.html


    Im ersten Fall hängt es mit einer früheren Version von graphtft + ein anderes Patch zusammen, im zweiten Fall scheint es unabhängig davon zu sein.


    Es wurde der Verdacht geäußert, dass das am Logging des Plugins liegt. Stell doch versuchsweise mal das Logging vom Plugin auf 0 oder 1. Ich werde auch meinen Patch nochmal dahingehend anpassen, dass ich sämtliches Logging-relevante wieder rauswerfe.


    Kannst Du bitte mal die Ausgabe von lsof -p $(pgrep vdr) posten, damit wir sehen, welche Dateien offen sind (das müssen ja dann eine ganze Menge sein...)?


    Bei mir sind es in Summe recht konstant 78+-1 Dateien (lsof -p $(pgrep vdr) | grep -c ".*"). Wie gesagt, kann ich allerdings nur mit fb + vnc testen, da ich keine FF-Karte habe.


    Ich werde mal weiter testen und schauen ob ich das reproduzieren kann.


    Den Segfault beim Starten habe ich bisher noch nicht reproduzieren können. Wenn Du Lust auf ein bisschen debuggen hast, dann könntest Du ja mal vdr im gdb starten (Ich vermute zwar, Du bist eh fitter als ich, aber zur Sicherheit hier mal der Ablauf dazu;-))


    Code
    gdb vdr
(gdb) run -P"graphtft -d vdr/0 -v 20000 -r" -P"touchtft -d vdr/0"


    Dann mehrmals den Prozess starten und stoppen(run -P..., dann STRG+C, dann kill und dann wieder run -P... eintippen), bis vdr halt beim Start abstürzt. gdb hält dann an:


    Beispiel aus einem HowTo:

    Code
    (gdb) run
Starting program: /home/dgawd/cpsc/363/a.out 
test string


Program received signal SIGSEGV, Segmentation fault.
0x4007fc13 in _IO_getline_info () from /lib/libc.so.6
(gdb)


    Dann gibt doch bitte mal das Kommando bt ein und anschließend noch info threads und poste mal alle Augaben von gdb.


    Vielen Dank auf jeden Fall für Deine Unterstützung!!!


    Falls noch jeman anderes mit liest, der meinen Patch ebenfalls angewendet hat, dann schreib doch bitte mal Deine Erfahrungen. Danke!


    Viele Grüße,


    Markus

    Hallo Markus,


    LASS DICH BLOSS NICHT ENTMUTIGEN !!! Habe jetzt meinen VDR mit ca 40 Plugins und Deinen Änderungen auf meinem Testsystem laufen und kann jetzt (mit graphtft-debug=0) richtig testen.
    @ALL: es können nun auch Leute testen, die keinen gdb kennen!!!


    @ Markus
    Hier nun die Ergebnisse:
    1. Oben files mit debug=10: wenn das Problem auftritt (nach dem Versuch eine Aufnahme abzuspielen) sind 1087 vdr relevante Files offen. Das Posten der Liste erspare ich mir, denn /tmp/graphTFT.log wurde 994 mal geöffnet (mit graphtft debug level =10). Das Problem liegt also eindeutig am graphtft Plugin)


    mardec:~ # grep graphTFT.log open-files.txt | wc -l
    994
    mardec:~ # cat open-files.txt | wc -l
    1087


    2. Open files mit Debug=0
    Kein Problem festgestellt - kann Aufnahmen abspielen und danach Sender Wechseln.


    3. Segfault mit graphtft-debug=10 babe ich zu ca 70% beim Aufruf von s.u nach ca. 15 Sekunden:
    mardec:/dvb/VDR # ./vdr -P"graphtft -d vdr/0 -v 20000 -r" -P"touchtft -d vdr/0"
    Segmentation fault
    mardec:/dvb/VDR # ./vdr -P"graphtft -d vdr/0 -v 20000 -r" -P"touchtft -d vdr/0"
    Killed
    mardec:/dvb/VDR # ./vdr -P"graphtft -d vdr/0 -v 20000 -r" -P"touchtft -d vdr/0"
    Segmentation fault
    mardec:/dvb/VDR #
    Ich habe den VDR nun 8x mit Debug=0 gestartet - diesmal immer ohne segfault


    4. Debugging mit debug=10:
    mardec:/dvb/VDR # gdb ./vdr
    GNU gdb 6.3
    Copyright 2004 Free Software Foundation, Inc.
    GDB is free software, covered by the GNU General Public License, and you are
    welcome to change it and/or distribute copies of it under certain conditions.
    Type "show copying" to see the conditions.
    There is absolutely no warranty for GDB. Type "show warranty" for details.
    This GDB was configured as "x86_64-suse-linux"...Using host libthread_db library "/lib64/tls/libthread_db.so.1".


    (gdb) run -P"graphtft -d vdr/0 -v 20000 -r" -P"touchtft -d vdr/0"
    Starting program: /dvb/vdr-1.4.3/vdr -P"graphtft -d vdr/0 -v 20000 -r" -P"touchtft -d vdr/0"
    [Thread debugging using libthread_db enabled]
    [New Thread 47524750238688 (LWP 8712)]
    [New Thread 1075841376 (LWP 8715)]
    [New Thread 1077942624 (LWP 8716)]
    [Thread 1077942624 (LWP 8716) exited]
    [Thread 1075841376 (LWP 8715) exited]
    [New Thread 1075841376 (LWP 8718)]
    [New Thread 1077942624 (LWP 8719)]
    [New Thread 1080043872 (LWP 8721)]
    [New Thread 1082145120 (LWP 8722)]
    [New Thread 1084246368 (LWP 8724)]
    [New Thread 1086347616 (LWP 8725)]
    [New Thread 1088448864 (LWP 8729)]
    [New Thread 1090550112 (LWP 8730)]
    [New Thread 1092651360 (LWP 8731)]
    [New Thread 1094752608 (LWP 8732)]
    [New Thread 1096853856 (LWP 8733)]
    [New Thread 1098955104 (LWP 8734)]
    [New Thread 1101056352 (LWP 8736)]
    [New Thread 1103157600 (LWP 8737)]
    [New Thread 1105258848 (LWP 8738)]
    [Thread 1096853856 (LWP 8733) exited]


    dmesg liefert dann:
    vdr[8702]: segfault at 00002aaaab1cd012 rip 00002b2138c373df rsp 0000000041408778 error 4


    bt liefert:
    Program received signal SIGINT, Interrupt.
    [Switching to Thread 47524750238688 (LWP 8712)]
    0x00002b3937411a5f in pthread_cond_timedwait@@GLIBC_2.3.2 ()
    from /lib64/tls/libpthread.so.0
    (gdb) Quit
    (gdb) bt
    #0 0x00002b3937411a5f in pthread_cond_timedwait@@GLIBC_2.3.2 ()
    from /lib64/tls/libpthread.so.0
    #1 0x00000000004bfa89 in cCondVar::TimedWait (this=0x7343a0, Mutex=@0x7343e0,
    TimeoutMs=<value optimized out>) at thread.c:124
    #2 0x00000000004a426d in cRemote::Get (WaitMs=1000, UnknownCode=0x0)
    at remote.c:186
    #3 0x00000000004cabda in main (argc=<value optimized out>,
    argv=<value optimized out>) at vdr.c:878
    (gdb)


    info threads liefert
    (gdb) info threads
    18 Thread 1105258848 (LWP 8738) 0x00002b3937c3a2c9 in poll ()
    from /lib64/tls/libc.so.6
    17 Thread 1103157600 (LWP 8737) 0x00002b3937411a5f in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0
    16 Thread 1101056352 (LWP 8736) 0x00002b3937411a5f in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0
    15 Thread 1098955104 (LWP 8734) 0x00002b3937c3a2c9 in poll ()
    from /lib64/tls/libc.so.6
    13 Thread 1094752608 (LWP 8732) 0x00002b3937411a5f in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0
    12 Thread 1092651360 (LWP 8731) 0x00002b3937c3c246 in __select_nocancel ()
    from /lib64/tls/libc.so.6
    11 Thread 1090550112 (LWP 8730) 0x00002b3937411a5f in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0
    10 Thread 1088448864 (LWP 8729) 0x00002b3937c16a15 in __nanosleep_nocancel
    () from /lib64/tls/libc.so.6
    9 Thread 1086347616 (LWP 8725) 0x00002b3937c3a2c9 in poll ()
    from /lib64/tls/libc.so.6
    8 Thread 1084246368 (LWP 8724) 0x00002b3937411a5f in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0
    7 Thread 1082145120 (LWP 8722) 0x00002b3937c3a2c9 in poll ()
    from /lib64/tls/libc.so.6
    6 Thread 1080043872 (LWP 8721) 0x00002b3937411a5f in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0
    5 Thread 1077942624 (LWP 8719) 0x00002b3937c3a2c9 in poll ()
    from /lib64/tls/libc.so.6
    4 Thread 1075841376 (LWP 8718) 0x00002b3937411a5f in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0
    * 1 Thread 47524750238688 (LWP 8712) 0x00002b3937411a5f in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0
    (gdb)


    5. Hier noch eine Frage:
    Hast Du an Berechtigungen gedacht - ich kann in meinem LAN den VDR mit beliebigem Account bedienen. Ich schlage daher vor, ein Passwort abzufragen. Dieses muss man ja nicht unbedingt via vdr | setup | plugins | graphtft vergeben können (oder doch???).


    6. Mein Punkt von gestern "Beim Start ist graphtft auf dem TFT OK, mit vncviewer bleibt "graphtft startet" stehen bis man eine angelernet Taste drückt." ist mit debug=0 offenbar auch nicht mehr relevant :lachen3


    Das Hauptproblem ist im Moment offenbar noch das Debugging.


    Viele Grüße,
    Frank

    Hallo Frank,


    keine Angst, ich lass mich nicht entmutigen, dafür macht mir das im Moment viel zu viel Spaß ;)


    Ich hab mal wieder eine neue Version gebaut und in den initial-Post mit eingestellt. Da die Version bei mir recht vernünftig zu laufen scheint, stelle ich sie als Beta mit der Version 0.0.1 ein.


    Die Neuerungen sind:

    • Überarbeitete VNC-Übertragung: Es werden jetzt effizient die tatsächlichen Änderungen verfolgt, um so sparsam wie möglich mit dem Netzwerk umzugehen. Das ist besonders bei WLAN-Clients nötig.
    • Passwort-Authentifizierung. Ab sofort kann man im config Verzeichnis des Plugins zwei Passwort-Datei anlegen um den Zugriff auf das VNC zu schützen. Eine Datei legt das control-Password fest, mit dem auch die Bedienung des VDR möglich ist. Die zweite Datei enthält das view-Passwort, mit dem man zwar sehen, aber nicht bedienen kann.
    • Kleinere Bugfixes


    Die Passwort-Dateien heißen control.pass und view.pass und man kann sie mit dem beim libvncserver enthaltenen Tool storepasswd <passwd> <pfad> erzeugen. Unter gentoo wird das tool mit installiert und steht im Pfad zur Verfügung, bei der libvncserver source-Distribution ist es im Verzeichnis examples enthalten. Ein Beispielaufruf zum Erzeugen der Passwörter wäre:


    Code
    storepasswd ctrlPasswd /video/plugins/control.pass
storepasswd viewPasswd /video/plugins/view.pass


    Leider überträgt VNC die Passwörter im Netz im Klartext, das ist also hächstens im lokalen Netz zu empfehlen. Wenn Ihr das VNC übers Internet zugänglich machen wollt, solltet ihr unbedingt über ssh o.Ä. tunneln, da weder der VNC-Server noch das Protokoll ausreichend sicher sind.


    Zu Deinen Punkten:


    1) Das könnte man lösen, dazu müsste man das Plugin mal im Hinblick auf Logging aufräumen. Vielleicht kann das der Maintainer (horchi, vermute ich) ja mal in Angriff nehmen? Das erfordert so viele Eingriffe an so vielen Stellen, dass das für mich im Moment keinen Sinn macht um es in einen Patch zu packen. Am besten also Logging vorerst auf 0 oder 1 stellen, alles andere ist eh höchstens zum Debuggen gut.


    2) Super :)


    3) und 4) Das ist ein sehr komische Stelle für einen Segfault. Das passiert ja nicht mal im graphtft Plugin. Ich kann mir darauf keinen Reim machen. Die Zeilen in vdr-sourcen sehen an diesen Stellen unkritisch aus. Ich wüsste nicht was ein Timed-Wait mit offenen Dateien zu tun hat. Aber gut, dass es ohne die vielen offenen Dateien nicht mehr passiert.


    5) Nein, aber ich hab gleicheine Passwortabfrage mit eingebaut ;) libvnc sieht das schon vor. Siehe oben.


    6) Sehr erfreulich ;) Ich habe einen verdacht, welcher Bug das war ;)


    So, dann mal viel Spaß mit dem Patch und vielen Dank! Die aktuelle Version gibt wieder im initial-Post.


    Viele Grüße,


    Markus

    Markus,


    Version 0.0.1 sieht sehr gut aus (mit debug=0 getestet).


    PW - Abfrage ist auch OK.


    Hier mal noch eine Idee - könntest Du graphtft so patchen, dass man im Setup von graphtft einstellen kann:
    1. Ob ein vnc-server gestartet werden soll
    2. Welcher Port für 1. benutzt werden soll
    3. Evtl auch Setting ob die Touchbuttons funktionieren sollen oder nicht
    4. "restart vnc server" (wenn man 2 geändert hat)
    5. "start vnc-server" (wenn man 1. angeschalten hat)


    Gruß Frank

    @Frank


    leider bin ich seit letzter Woche offline, da ich VDSL bekommen habe bzw. hätte und damit erst mal gar keinen Internetzugang habe - daher auch die späte Antwort.


    Ich hab mir Gedanken zu Deinen Anregungen gemacht und finde sie alle sinnvoll und sie sind auch durcvhaus machbar. Dazu wird es aber nötig das Konzept mit dem ich VNC in das Plugin intergriert habe, komplett zu überarbeiten. Ich überlege daher, ob es nicht Sinn macht, ein eigenes Plugin im Stil con TouchTFT nur für den VNC Server zu schreiben und somit die nötigen patches an graphtft auf ein Minimum zu reduzieren (im Prinzip ist das dann nur ein zusätzlicher Service-Request). Ich melde mich dann in naher Zuknuft mit einer neuen Version.


    Viele Grüße,


    Markus

    Hallo,


    bin von der Idee für dieses Plugin begeistert!
    Danke markusrr.


    Leider bin ich wohl zu blöd, um es ans Laufen zu bekommen....
    Das Übersetzen und Starten scheint zu klappen, aber leider keine Verbindung mittels xvncclient :(


    Starte mit: vdr -P"graphtft -v 20000 -d dummy"
    Verbindungsversuch: xvncviewer localhost::20000


    Habt Ihr ein paar Tips?


    System: Kubuntu 7.04 mit libvncserver-dev


    /var/log/messages:


    May 28 23:01:49 vdr vdr: [9126] found 2 video devices
    May 28 23:01:49 vdr vdr: [9126] initializing plugin: graphtft (0.0.16): Display Info on TFT
    May 28 23:01:49 vdr vdr: [9126] setting primary device to 2
    May 28 23:01:49 vdr vdr: [9126] SVDRP listening on port 2001
    May 28 23:01:49 vdr vdr: [9126] skin "EnigmaBin" not available - using "classic" instead
    May 28 23:01:49 vdr vdr: [9126] loading /var/lib/vdr/themes/classic-default.theme
    May 28 23:01:49 vdr vdr: [9126] starting plugin: graphtft
    May 28 23:01:49 vdr vdr: [9126] Device is 'dummy'
    May 28 23:01:49 vdr vdr: [9126] Loding themes
    May 28 23:01:49 vdr vdr: [9126] loading /var/lib/vdr/plugins/graphTFT/themes/DeepBlue/DeepBlue.theme
    May 28 23:01:49 vdr vdr: [9126] Loaded 1 themes
    May 28 23:01:49 vdr vdr: [9126] Activated theme 'DeepBlue'
    May 28 23:01:49 vdr vdr: [9138] GraphTFT plugin tcp communication thread started (pid=9126)
    May 28 23:01:49 vdr vdr: [9126] skin "EnigmaBin" not available - using "classic" instead
    May 28 23:01:49 vdr vdr: [9126] loading /var/lib/vdr/themes/classic-default.theme
    May 28 23:01:49 vdr vdr: [9126] switching to channel 1
    May 28 23:01:49 vdr vdr: [9139] GraphTFT plugin display thread started (pid=9126)


    Grüße
    Funzt

    Hi,


    Nachtrag:
    Testumgebung:


    plain vanilla vdr-1.4.3
    graphtft-0.0.16 nach wiki installiert und mit graphtft-vnc-0.0.1.diff.gz gepacht.


    xvncviewer auf einen anderen vncserver über localhost geht.



    Grüße
    Funzt




    Auszug aus Graphtft-Makefile:



    #
    # Makefile for a Video Disk Recorder plugin
    #


    ################################################################################
    # Config:


    # You will need ffmpeg for dvb/fb-devices and for softmpeg,
    # so install it and set path below:


    FFMDIR = /usr/include/ffmpeg


    # Install imlib2, set path below and uncomment the lines
    # to enable support for dvb- and fb-devices.


    #IMLIB = ../../../../imlib2
    HAVE_IMLIB = 1


    # Install libvncserver and uncomment the following line
    # to enable support for output to VNC
    HAVE_VNC = 1


    # Install ImageMagick


    HAVE_IMAGE_MAGICK = 1


    # Install directFB and libsoftmpeg to use an directFB-output-device
    # If you wont use libsoftmpeg, in future(dosent work at the moment)
    # ffmpeg will be used for PbP.
    # You can use only directFB without ffmpeg, imlib
    # and libsoftmpeg, but without Pbp.


    # HAVE_SOFTMPEG = 1


    # USE FASTMEMCPY WITH CPUACCEL
    #HAVE_FAST_MEMCPY = 1


    # FIX FOR USING PVR350-FRAMEBUFFER
    #HAVE_PVRFB = 1


    # USE DFB
    #HAVE_DFB = 1


    #############################################

    Hi Funzt,


    <EDIT> habe Deinen Post noch mal gelesen und stelle meiner Antwort dies zuvor
    Wie hast Du gepached?
    Das solltest Du so machen
    1. libvdr-graphtft.so.1.4.X löschen
    2. im Plugin source:
    make clean aufrufen
    3. patch -p0 < graphtft-vnc-0.0.1.diff
    oder
    patch -p1 < graphtft-vnc-0.0.1.diff
    aufrufen
    4. im VDR src Verzeichnis
    make plugins aufrufen


    Danch kannst Du folgendes testen:
    mardec:/dvb/VDR/PLUGINS/src/graphtft # grep -r "OSD via VNC" *
    graphtft-vnc-0.0.1.diff:+ : cThread("OSD via VNC")
    imlibrenderer/vncrenderer/vncworker.c: : cThread("OSD via VNC")
    Binary file imlibrenderer/vncrenderer/vncworker.o matches
    Binary file libvdr-graphtft.so matches
    </EDIT>



    Deine Einstellungen (Makefile) sind OK.


    Probier mal einen Portscan auf Port 2000 mit:
    nmap localhost -p 20000


    -> sollte so aussehen:
    Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2007-05-29 17:10 CEST
    Interesting ports on localhost (127.0.0.1):
    PORT STATE SERVICE
    20000/tcp open unknown
    Nmap finished: 1 IP address (1 host up) scanned in 0.132 seconds


    Ich vermue aber, dass der Port bei Dir nicht offen ist. Was mir an Deinem Log auffällt:


    1. Es fehlt so ein Eintrag:
    May 29 17:01:53 mardec vdr: [8216] OSD via VNC thread started (pid=8189, tid=8216)


    2. Das Thema DeepBlue hast Du nicht installiert. Es kann sein, dass das Thema "default" den Fehler verursacht


    Gruß Frank

    Hi Frank,


    danke für die Hilfe.
    Läuft leider immer noch nicht :(
    Hier die Ausgaben:


    root@vdr:/usr/local/src/vdr-1.4.3/PLUGINS/src/graphtft# grep -r "OSD via VNC" *


    Ãbereinstimmungen in Binärdatei imlibrenderer/vncrenderer/vncworker.o.
    imlibrenderer/vncrenderer/vncworker.c: : cThread("OSD via VNC")
    Ãbereinstimmungen in Binärdatei libvdr-graphtft.so.


    Die Installation lief so durch, wie Du geschrieben hast.


    Der port 20000 ist leider zu:


    root@vdr:~# netstat -tulpen
    Aktive Internetverbindungen (Nur Server)
    Proto Recv-Q Send-Q Local Address Foreign Address State Benutzer Inode PID/Program name
    tcp 0 0 127.0.0.1:2208 0.0.0.0:* LISTEN 0 17495 5186/hpiod
    tcp 0 0 0.0.0.0:8001 0.0.0.0:* LISTEN 99 18362 5613/perl
    tcp 0 0 127.0.0.1:13666 0.0.0.0:* LISTEN 0 17683 5299/LCDd
    tcp 0 0 0.0.0.0:2001 0.0.0.0:* LISTEN 0 63589 14349/vdr
    tcp 0 0 127.0.0.1:7634 0.0.0.0:* LISTEN 0 17637 5271/hddtemp
    tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 0 17380 5127/dnsmasq
    tcp 0 0 0.0.0.0:2039 0.0.0.0:* LISTEN 0 63586 14349/vdr
    tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 0 22453 9327/cupsd
    tcp 0 0 127.0.0.1:2207 0.0.0.0:* LISTEN 108 17506 5189/python
    tcp6 0 0 :::53 :::* LISTEN 0 17382 5127/dnsmasq
    tcp6 0 0 :::22 :::* LISTEN 0 17721 5328/sshd
    udp 0 0 0.0.0.0:32768 0.0.0.0:* 105 17360 5114/avahi-daemon:
    udp 0 0 0.0.0.0:32769 0.0.0.0:* 111 17393 5127/dnsmasq
    udp 0 0 0.0.0.0:53 0.0.0.0:* 0 17379 5127/dnsmasq
    udp 0 0 0.0.0.0:67 0.0.0.0:* 0 17383 5127/dnsmasq
    udp 0 0 0.0.0.0:5353 0.0.0.0:* 105 17359 5114/avahi-daemon:
    udp6 0 0 :::53 :::* 0 17381 5127/dnsmasq


    > May 29 17:01:53 mardec vdr: [8216] OSD via VNC thread started (pid=8189, tid=8216)
    Das fehlt bei mir leider weiterhin.


    Meine /var/log/messages:


    May 29 20:52:48 vdr vdr: [14347] VDR version 1.4.3 started
    May 29 20:52:48 vdr vdr: [14347] switched to user 'root'
    May 29 20:52:48 vdr vdr: [14347] loading plugin: ./PLUGINS/lib/libvdr-text2skin.so.1.4.3
    May 29 20:52:55 vdr vdr: [14349] VDR version 1.4.3 started
    May 29 20:52:55 vdr vdr: [14349] switched to user 'root'
    May 29 20:52:55 vdr vdr: [14349] loading plugin: ./PLUGINS/lib/libvdr-text2skin.so.1.4.3
    May 29 20:52:55 vdr vdr: [14349] loading plugin: ./PLUGINS/lib/libvdr-graphtft.so.1.4.3
    May 29 20:52:55 vdr vdr: [14349] loading /var/lib/vdr/setup.conf
    May 29 20:52:55 vdr vdr: [14349] loading /var/lib/vdr/sources.conf
    May 29 20:52:55 vdr vdr: [14349] loading /var/lib/vdr/diseqc.conf
    May 29 20:52:55 vdr vdr: [14349] loading /var/lib/vdr/channels.conf
    May 29 20:52:55 vdr vdr: [14349] loading /var/lib/vdr/timers.conf
    May 29 20:52:55 vdr vdr: [14349] loading /var/lib/vdr/commands.conf
    May 29 20:52:55 vdr vdr: [14349] loading /var/lib/vdr/reccmds.conf
    May 29 20:52:55 vdr vdr: [14349] loading /var/lib/vdr/svdrphosts.conf
    May 29 20:52:55 vdr vdr: [14349] loading /var/lib/vdr/remote.conf
    May 29 20:52:55 vdr vdr: [14349] loading /var/lib/vdr/keymacros.conf
    May 29 20:52:58 vdr vdr: [14349] found 2 video devices
    May 29 20:52:58 vdr vdr: [14349] initializing plugin: text2skin (1.1-cvs): Loader for text-based skins
    May 29 20:52:58 vdr vdr: [14349] initializing plugin: graphtft (0.0.16): Display Info on TFT
    May 29 20:52:58 vdr vdr: [14349] setting primary device to 2
    May 29 20:52:58 vdr vdr: [14349] SVDRP listening on port 2001
    May 29 20:52:58 vdr vdr: [14349] skin "DeepBlue" not available - using "classic" instead
    May 29 20:52:58 vdr vdr: [14349] loading /var/lib/vdr/themes/classic-default.theme
    May 29 20:52:58 vdr vdr: [14349] starting plugin: text2skin
    May 29 20:52:58 vdr vdr: [14349] text2skin: loading /var/lib/vdr/plugins/text2skin/DeepBlue/DeepBlue.trans
    May 29 20:52:58 vdr vdr: [14349] text2skin: loading /var/lib/vdr/plugins/text2skin/DeepBlue/DeepBlue.colors
    May 29 20:52:58 vdr vdr: [14349] parsing /var/lib/vdr/plugins/text2skin/DeepBlue/DeepBlue.skin
    May 29 20:52:58 vdr vdr: [14349] text2skin: loading /var/lib/vdr/plugins/text2skin/EnigmaBin/EnigmaBin.trans
    May 29 20:52:58 vdr vdr: [14349] text2skin: loading /var/lib/vdr/plugins/text2skin/EnigmaBin/EnigmaBin.colors
    May 29 20:52:58 vdr vdr: [14349] parsing /var/lib/vdr/plugins/text2skin/EnigmaBin/EnigmaBin.skin
    May 29 20:52:58 vdr vdr: [14349] starting plugin: graphtft
    May 29 20:52:58 vdr vdr: [14349] Device is 'dummy'
    May 29 20:52:58 vdr vdr: [14349] Loding themes
    May 29 20:52:58 vdr vdr: [14349] loading /var/lib/vdr/plugins/graphTFT/themes/DeepBlue/DeepBlue.theme
    May 29 20:52:58 vdr vdr: [14349] Loaded 1 themes
    May 29 20:52:58 vdr vdr: [14349] Activated theme 'DeepBlue'
    May 29 20:52:58 vdr vdr: [14361] GraphTFT plugin tcp communication thread started (pid=14349)
    May 29 20:52:58 vdr vdr: [14349] setting current skin to "DeepBlue"
    May 29 20:52:58 vdr vdr: [14349] loading /var/lib/vdr/themes/DeepBlue-default.theme
    May 29 20:52:58 vdr vdr: [14349] switching to channel 2
    May 29 20:52:58 vdr vdr: [14362] GraphTFT plugin display thread started (pid=14349)



    Habe text2skin und das Thema DeepBlue jetzt drin.


    Noch 'ne Idee?


    Grüße
    Funzt

    Hi Funzt,


    ich hab die Postings gerade gesehen und werde versuchen das nach zu vollziehen. Soweit ich das bei Euch beiden mitgelesen habe, sollte es eigentlich funktionieren.


    Leider werde ich vermutlich in den nächsten Tagen nicht dazu kommen. Ich melde mich auf jeden Fall sobald ich mehr weiß.


    Viele Grüße,


    Markus

    Hi,
    ich bin gerade auf diesen Thread gestoßen.... gibts da irgendwelche updates?!?


    Is ja nun schon ziemlich lang her.


    Danke!
    Jejune

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden