[TEST] graphlcd-base / vdr-plugin-graphlcd branch 0.2.0: animated images/logos and scrolling texts

  • hi,


    habe in den letzten tagen animierte logos und 'scrolling texts' im glcdskin-teil von graphlcd-base eingebaut.
    das ganze ist bereits im graphlcd-base git-repository verfuegbar und kann getestet werden.


    um das mit VDR verwenden zu koennen wird die aktuellste version des '0.2.0' branchs von vdr-plugin-graphlcd benoetigt.
    informationen, wie dieser geholt werden kann: graphlcd with skin support / vdr-plugin-graphlcd (the '0.2.0'-branch).


    naehere informationen zu allen neuerungen in graphlcd-base/glcdskin und vdr-plugin-graphlcd, branch '0.2.0':
    graphlcd with skin support



    anmerkungen:

    • multiline-texte und texte, die tabulatoren enthalten, werden noch nicht unterstuetzt
      (zweitere sind mir ohnedies noch nicht untergekommen)
    • ich entwickle auf einer alten installation mit VDR 1.4.7 und gcc 4.1.1: graphlcd-base kompiliert auch auf einer aktuellen installation mit gcc 4.4.3 fehlerfrei, bei vdr-plugin-graphlcd konnte ich das nicht testen. wenn compiler errors/warnings: mir bitte melden.
    • da C++ von mir von ganzem herzen gehasst wird: mich bitte auf unschoenheiten/fehler/... im code aufmerksam machen.


    /wastl

  • Zitat

    da C++ von mir von ganzem herzen gehasst wird: mich bitte auf unschoenheiten/fehler/... im code aufmerksam machen.


    ich hab da was :D


    Code
    1. make[1]: Entering directory `/build/buildd/vdr-plugin-graphlcd-0.2.0'
    2. g++ -g -Wall -Woverloaded-virtual -Wno-parentheses -O2 -fPIC -c -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DUSE_GRAPHTFT -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"graphlcd"' -DHAVE_FREETYPE2 -I/usr/include/dvb-s2api-liplianin -I./graphlcd-base/ -I/usr/include/vdr/include -I/usr/include -I/usr/include/freetype2 alias.c
    3. g++ -g -Wall -Woverloaded-virtual -Wno-parentheses -O2 -fPIC -c -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DUSE_GRAPHTFT -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"graphlcd"' -DHAVE_FREETYPE2 -I/usr/include/dvb-s2api-liplianin -I./graphlcd-base/ -I/usr/include/vdr/include -I/usr/include -I/usr/include/freetype2 common.c
    4. common.c: In function 'GLCD::cType DurationType(int, const std::string&)':
    5. common.c:73: error: invalid operands of types 'int' and 'double' to binary 'operator%'
    6. make[1]: *** [common.o] Error 1
  • habe jetzt auf einem aktuellen system (aber ohne DVB-karten) die neueste vdr-version installiert und graphlcd-base.


    kannst du bitte folgendes testen:


    im common.c vor den beiden DEFAULTFRAMESPERSECOND ein (int) davorstellen.


    vor der aenderung:

    Code
    1. int f = (Index % DEFAULTFRAMESPERSECOND) + 1;
    2. int s = (Index / DEFAULTFRAMESPERSECOND);


    nach der aenderung:

    Code
    1. int f = (Index % (int)DEFAULTFRAMESPERSECOND) + 1;
    2. int s = (Index / (int)DEFAULTFRAMESPERSECOND);


    nach dieser aenderung laeuft bei mir der compiler durch.


    /wastl

  • spiele gerade mit der unterstuetzung v. plugins (via service-schnittstelle) im vdr-graphlcd-plugin herum.


    das ganze ist noch mitten in der entstehung, aber ein paar sachen funktionieren bereits so wie ich mir das vorgestellt habe.


    das nette daran: es werden nicht mehr wild werte ueberschrieben irgendwo mitten im graphlcd-code, sondern das ganze ist ausgelagert in eine eigene klasse und kann sauber erweitert werden (bzw. sollte koennen ;-).
    und:
    die einzelnen werte koennen in der skin-definition ueber eigene tokens sauber eingebunden werden.


    im bild schon mal ein vorgeschmack auf integrierte femon-statusinformationen (signal, snr, video bitrate vom aktuellen sender).


    /wastl

  • Hi,
    sieht nett aus!!!!!


    mfG,
    Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 512MB PCIe x1 | v2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 750GB F1, GT730, 2x TT DVB-S2-3200) easyVDR 2.3
    VDR5: Gigabyte
    GA-G31M-S2L (Intel E2140, Zotac GT220 512MB + Zalman VNF100, Digitainer2-Geh., t6963c 6 " gLCD, 750GB F1, Sundtek DVB-C + Satelco DVB-C) easyVDR 1.0
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT 3200 | easyVDR 2.3 64bit
    VDR-User #1068 
    www.easyvdr.de 

  • Hi,


    haben unter yaVDR 0.2 das Problem, dass das 0.2-Plugin scheinbar zu einer sehr hohen CPU-Last führt. Teilweise 100% auf einem Kern..
    Wurde dieses Problem schon mal beobachtet?? Thread siehe hier

    VDR: Asus M3N78-EM mit Onboard Nvidia 8300, AMD 5050e, 2x2GB Ram, 8GB SATA Transcend SSD + 1 TB WD green, Atric-Einschalter, Hitachi-LCD 240x128 (HD61830) & AX206 (Pearl), Terratec S2 HD & TeVii S464 (unterstützt durch v4l-dvb per selfmade-patch), yaVDR 0.4

  • die cpu-probleme bekam ich ledliglich mit meinen lokalen aenderungen zusammen (== hinfaelliges posting).


    mit den letzten git-versionen von graphlcd-base und vdr-plugin-graphlcd 0.2.0, die auf projects.vdr-developer.org verfuegbar sind, kann ich das NICHT nachvollziehen!


    welche versionen verwendet yaVDR 0.2?


    /wastl

  • ja, die verhaelt sich auch mit 2 gleichzeitig scrollenden texten relativ dezent (letzverfuegbare graphlcd-base + vdr-plugin-graphlcd). ich habe aber gegen die unveraenderten git-versionen getestet. in den yavdr-paketen sind noch patches enthalten wenn ich das richtig gelesen habe. habe mir diese aber nicht genauer angesehen.


    welcher skin wird verwendet in yavdr, welche graphlcd.conf und wie wird das plugin aufgerufen (cmdline-parameter)?


    kann ja nicht sein, dass mene viel schwaechere single-core cpu problemlos damit zurechtkommt, und eine schnellere dualcore 100% cpu hat (bei einem updatevorgang kann die cpu-load schon mal kurzzeitig ansteigen, aber nicht permanent).


    /wastl

  • es ist nur der patch :



    "aktiviert"


    was die "user" in der conf mitgeben kann ich natürlich nicht sagen...


    Zitat

    welcher skin wird verwendet in yavdr


    soweit ich weiss gibt es "nur" ein default skin ?

  • ok, der default-skin ist relativ 'unaufregend'. haette ja sein koennen, dass hier ein eigener gebastelt worden ist.


    der eine patch sollte kein problem sein, der ist nur fuer neuere gcc, damit diese nicht maulen.


    ich habe mit vdr 1.4.7 getestet. muss jetzt wirklich mal 1.7.x aktivieren und damit testen, wuerde mich aber stark wundern, wenn es daran laege. weiters teste ich mit einem 32bit system. der datentyp uint64_t scheint grosse probleme zu machen bei vergleichen (darum auch die probleme mit meiner lokalen entwicklerversion, da waren vergleiche a la ((uint64_t)(x-y) >= (uint64_t)mScrollTime) IMMER erfuellt (auch wenn x nur ganz wenig groesser als y war und rein rechnerisch eine zahl < mScrollTime herausgekommen ist). aber auch das sollte hier nicht der fall sein, da in der git-version auf int gecastet wird (und die bedingung dann funktioniert - zumindest auf 32bit ...).


    interessant waere, welche graphlcd.conf-settings die betroffenen verwenden (t6963, hitachi-controller). bitte nur relevante settings - nicht das komplette graphlcd.conf!


    /wastl

  • So dann mach ich mal den Anfang und stell mal meine Config vor:
    Ausschnitt aus /etc/graphlcd.conf


    und /etc/vdr/plugins/plugin.graphlcd.conf

    Code
    1. -c /etc/graphlcd.conf -d hd61830


    Gibt es da optimierungsbedarf?

    VDR: Asus M3N78-EM mit Onboard Nvidia 8300, AMD 5050e, 2x2GB Ram, 8GB SATA Transcend SSD + 1 TB WD green, Atric-Einschalter, Hitachi-LCD 240x128 (HD61830) & AX206 (Pearl), Terratec S2 HD & TeVii S464 (unterstützt durch v4l-dvb per selfmade-patch), yaVDR 0.4

  • eigentlich nicht. kenne aber auch den hd61830 nicht. aber entweder es wird 'upgedatet' oder nicht (dh cpu-last sollte nur waehrend einem update hoeher sein, dazwischen nicht) . dh graphlcd.conf sollte so passen.


    kann man auf yavdr selber etwas kompilieren? ansonsten wirds eher schwierig, dem fehler auf die spur zu kommen (haette vor einer bestimmten anweisung gerne ein fprintf, das einen punkt ausgibt (ob ein problem mit uint64_t zuschlaegt oder nicht).


    kann man vdr eigentlich komplett ohne karte betreiben (quasi als besseren streamdev-client)? in meinem 64bit-rechner habe ich keine dvb-karte.


    /wastl

  • es ist kein patch. sondern ein 'optisches erkennungsmerkmal'.
    '.' bei jedem update ausgeben in glcddrivers/driver.c nach Clear();
    zb:


    Clear();
    fprintf(stderr, ".");
    if (data)
    {.....



    wenn die punkte nur so daherrauschen: problem mit der erkennung, ob ein update benoetigt wird oder nicht. wenn die punkte 1/2-wegs deckungsgleich mit den div. aenderungen in der anzeige sind: erkennung passt, fehler/problem woanders.


    das muesste dann aber wohl ein inoffizielles paket sein fuer jene, die beim finden des bugs mithelfen wollen (und den vdr so starten koennen, dass sie die debug-ausgabe auch sehen ;-)


    /wastl

  • hotzenplotz5


    Sollen wir das dann testen?
    Könntest du mir kurz für Laien erklären, was ich machen muss? In sources.list einbinden? wgetten?

    VDR: Asus M3N78-EM mit Onboard Nvidia 8300, AMD 5050e, 2x2GB Ram, 8GB SATA Transcend SSD + 1 TB WD green, Atric-Einschalter, Hitachi-LCD 240x128 (HD61830) & AX206 (Pearl), Terratec S2 HD & TeVii S464 (unterstützt durch v4l-dvb per selfmade-patch), yaVDR 0.4

  • Code
    1. driver.c: In member function 'virtual void GLCD::cDriver::SetScreen(const unsigned char*, int, int, int)':
    2. driver.c:38: error: 'stderr' was not declared in this scope
    3. driver.c:38: error: 'fprintf' was not declared in this scope


    :D


    na da fehlt mir wohl noch ein include ...