Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: VDR Portal. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

1

Samstag, 15. Mai 2010, 12:43

[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
signature intentionally left blank

serdisplib -> http://serdisplib.sourceforge.net

2

Mittwoch, 19. Mai 2010, 01:06

Zitat

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

ich hab da was :D

Quellcode

1
2
3
4
5
6
make[1]: Entering directory `/build/buildd/vdr-plugin-graphlcd-0.2.0'
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
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
common.c: In function 'GLCD::cType DurationType(int, const std::string&)':
common.c:73: error: invalid operands of types 'int' and 'double' to binary 'operator%'
make[1]: *** [common.o] Error 1

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »hotzenplotz5« (19. Mai 2010, 01:07)


3

Mittwoch, 19. Mai 2010, 01:38

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:

Quellcode

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


nach der aenderung:

Quellcode

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


nach dieser aenderung laeuft bei mir der compiler durch.

/wastl
signature intentionally left blank

serdisplib -> http://serdisplib.sourceforge.net

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »wastl« (19. Mai 2010, 01:38)


4

Mittwoch, 19. Mai 2010, 13:07

jop damit ging es, danke !

5

Samstag, 29. Mai 2010, 20:09

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
»wastl« hat folgendes Bild angehängt:
  • graphlcdservices.jpg
signature intentionally left blank

serdisplib -> http://serdisplib.sourceforge.net

Beiträge: 1 946

Wohnort: D-Sachsen-Anhalt

Beruf: Ing.

  • Nachricht senden

6

Sonntag, 30. Mai 2010, 13:10

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

7

Mittwoch, 16. Juni 2010, 13:04

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

8

Mittwoch, 16. Juni 2010, 22:01

... altes posting hinfaellig ....

/wastl
signature intentionally left blank

serdisplib -> http://serdisplib.sourceforge.net

Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von »wastl« (17. Juni 2010, 00:19)


9

Donnerstag, 17. Juni 2010, 00:25

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
signature intentionally left blank

serdisplib -> http://serdisplib.sourceforge.net

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »wastl« (17. Juni 2010, 00:27)


10

Donnerstag, 17. Juni 2010, 00:34

ich hab für das paket ein "snapshot" von hier genommen :
http://projects.vdr-developer.org/git/?p…efs/heads/0.2.0

(21.5.2010)

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »hotzenplotz5« (17. Juni 2010, 00:35)


11

Donnerstag, 17. Juni 2010, 09:03

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
signature intentionally left blank

serdisplib -> http://serdisplib.sourceforge.net

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »wastl« (17. Juni 2010, 09:04)


12

Donnerstag, 17. Juni 2010, 09:08

es ist nur der patch :

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
diff -urNad vdr-plugin-graphlcd_0.2.0~/common.c vdr-plugin-graphlcd_0.2.0/common.c
--- vdr-plugin-graphlcd_0.2.0~/common.c	2010-05-18 23:03:20.000000000 +0200
+++ vdr-plugin-graphlcd_0.2.0/common.c	2010-05-19 12:57:42.886848453 +0200
@@ -70,8 +70,8 @@
             enum { normal, format } state = normal;
             int n = 0;
 #if VDRVERSNUM >= 10701
-            int f = (Index % DEFAULTFRAMESPERSECOND) + 1;
-            int s = (Index / DEFAULTFRAMESPERSECOND);
+            int f = (Index % (int)DEFAULTFRAMESPERSECOND) + 1;
+            int s = (Index / (int)DEFAULTFRAMESPERSECOND);
 #else
             int f = (Index % FRAMESPERSEC) + 1;
             int s = (Index / FRAMESPERSEC);


"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 ?

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »hotzenplotz5« (17. Juni 2010, 09:11)


13

Donnerstag, 17. Juni 2010, 09:26

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
signature intentionally left blank

serdisplib -> http://serdisplib.sourceforge.net

14

Donnerstag, 17. Juni 2010, 13:21

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

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
[hd61830]
# hd61830 driver
#  This is a driver module for the Hitachi HD61830 LCD controller.
#  Default size: 240 x 128
Driver=hd61830

Device=/dev/parport0
#Port=0x378
#Width=240
#Height=128
UpsideDown=yes
Invert=no
#AdjustTiming=0
#RefreshDisplay=1


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

Quellcode

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

15

Donnerstag, 17. Juni 2010, 13:42

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
signature intentionally left blank

serdisplib -> http://serdisplib.sourceforge.net

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »wastl« (17. Juni 2010, 13:50)


16

Donnerstag, 17. Juni 2010, 17:14

@wastl ich glaube am "schnellsten" geht es, wenn du mir den patch schickst und ich bau damit ein paket
für alle mit dem problem.
ausser die sagen jetzt was anderes :D

17

Donnerstag, 17. Juni 2010, 17:50

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
signature intentionally left blank

serdisplib -> http://serdisplib.sourceforge.net

18

Donnerstag, 17. Juni 2010, 19:05

ich hab mal ein paket hochgeladen nach :
https://launchpad.net/~hotzenplotz5/+archive/test/+packages

allerdings dauert es bei launchpad noch 2stunden bis es gebaut wird.
keine angst das repo sieht einsam aus, aber es ist eine art verlängerter arm für stable-repo
und wird nach dem test eh wieder gelöscht von mir :D

19

Donnerstag, 17. Juni 2010, 19:39

@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

20

Donnerstag, 17. Juni 2010, 20:17

Quellcode

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


:D

na da fehlt mir wohl noch ein include ...

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »hotzenplotz5« (17. Juni 2010, 20:25)


Immortal Romance Spielautomat