[ANNOUNCE] graphtft 0.3.1

Bin begeistert! Nachdem ich nach 3 Jahren meinen 1.4.7er VDR auf 1.6 gebracht habe (never change a running system ;), habe ich auch graphtft aktualisiert ... mächtige fortschritte und tolle funktionen!! Repsekt an alle beteiligten

Mir fehlen nur 2 Dinge zum glücklichsein:
* ein shuffle-mode in der dia.sh
* die Picture-by-Picture funktion

Btw.: PbP

Ich nutze folgendes Scripts:

Zitat

#!/bin/sh
fbtv -t8 -q 2>&1

gestartet aus "Befehle", welches mir sauber das TV-Bild auf das TFT bringt ... muß noch die ACTIVE on/off geschichte einbauen ...

Aber der Shuffle-Mode in der dia.sh ... jemand ne Idee?

Irgendwie bekomme ich keine epgimages mehr angezeigt. Ich lasse mir die Bilder vom tvm2vdr-Plugin herunterladen. Das Verzeichnis wurde per Symlink unter /video0/epgimages eingebunden. Dort liegen auch jede Menge Dateien mit 12345.jpg als Namen. Allerdings werden nirgendwo im Graphtft irgendwelche Bilder angezeigt. Im Debug-Modus erscheint im Log:

May 21 14:56:00 video vdr: [graphTFT] Image '/video0/images/Startup.jpg' not found :(
May 21 14:56:00 video vdr: [graphTFT] Image '/video0/images/NVA.jpg' not found :(

Er sucht wohl nach Dateien mit der Sendungsbezeichnung im Namen und nicht mit der ID (dafür auch noch im falschen Verzeichnis - das existiert nicht einmal).

Das hat schon mal funktioniert

Hallo, ich muss mal wieder Fragen, da ich mit der SuFu zu keinem Ergebnis kam:

Wie war nochmal der letzte Stand zum Thema "vdr/0" ( also dem ausgang an der FF ) ?
Graphtft-fe und fb funktionieren 1a, aber auf dem Ausgang der FF schaut das Bild nicht gerade Fein aus.

* Schwarz-Weis
* irgendwie wie ein NTSC bild auf einem lcd, das das nicht kann ( meins könnte es aber - ist halt kein ntsc )
* Zerbröselt ( fast wie ne falsche frequenz )
* Zu lang ( breite > display )

Ich hab schon alle möglichen Optionen an den dvd-ttpci übergeben, aber immer das gleiche "falsche" bild.

Ich kann mich erinnern dieses Thema vor 2 Jahren mal angeschnitten zu haben, kann mich aber nicht mehr erinnern.

Versionen siehe ganz unten

-----

HagenS:
Guck mal in deinem Theme-File ( bsp: /etc/vdr/plugins/graphTFT/themes/DeepBlue/DeepBlue.theme oder /etc/vdr/plugins/graphTFT/themes/avp/avp.theme ) ... da musst du die Pfade anpassen:

var varEPGimagesPath_1 = "/var/vdr/epgimages/";
var varImagesPath_1 = "/var/vdr/covers/";

die varEPGimagesPath_1 sind für die mit ID, die varImagesPath_1sind für die mit Namen. Das ist für Statische Cover recht nett ( Serien usw. ) ... und sie werden nacheinander abgearbeitet.. erst die mit ID, dann die mit Namen ( zumindest in der Standardeinstellung des avp-themes, bei den anderen weis ich grad net ).
PS: lies dir mal das Readme und die .theme files durch, da ist einiges anpassbar.

-----
so, wieder zu meinem Prob:

linux-siac:/usr/src/vdr/ # ffmpeg --version
FFmpeg version git-7796d7b, Copyright (c) 2000-2009 Fabrice Bellard, et al.
  configuration: --prefix=/usr --enable-gpl --enable-libxvid --enable-postproc --enable-avfilter --enable-shared
  libavutil     50. 3. 0 / 50. 3. 0
  libavcodec    52.31. 2 / 52.31. 2
  libavformat   52.34. 0 / 52.34. 0
  libavdevice   52. 2. 0 / 52. 2. 0
  libavfilter    0. 5. 0 /  0. 5. 0
  libswscale     0. 7. 1 /  0. 7. 1
  libpostproc   51. 2. 0 / 51. 2. 0
  built on Jun 17 2009 14:49:42, gcc: 4.3.2 [gcc-4_3-branch revision 141291]

linux-siac:/usr/src/vdr # ./vdr --version
vdr (1.7.7/1.7.7) - The Video Disk Recorder
graphtft (0.3.3) - VDR OSD on TFT

dvb 0000:01:07.0: PCI INT A -> Link[APC2] -> GSI 17 (level, low) -> IRQ 17
saa7146: found saa7146 @ mem ffffc20005702000 (revision 1, irq 17) (0x13c2,0x0006).
firmware: requesting dvb-ttpci-01.fw
DVB: registering new adapter (Fujitsu Siemens DVB-S rev1.6)
adapter has MAC addr = 00:d0:5c:02:7f:c9
dvb-ttpci: info @ card 0: firm f0240009, rtsl b0250018, vid 71010068, app c0f12623
dvb-ttpci: firmware @ card 0 supports CI link layer interface
dvb-ttpci: Crystal audio DAC @ card 0 detected
saa7146_vv: saa7146 (0): registered device video0 [v4l2]
saa7146_vv: saa7146 (0): registered device vbi0 [v4l2]
DVB: registering adapter 0 frontend 0 (Philips TDA8083 DVB-S)...
input: DVB on-card IR receiver as /devices/pci0000:00/0000:00:10.0/0000:01:07.0/input/input5
dvb-ttpci: found av7110-0.
DVB: adapter 0 frontend 0 frequency 8176000 out of range (920000..2200000)

DVB-Treiber vom ~17.05.2009.

Zitat

Originally posted by horchi
Hi ciax,

stimmt, das macht eine Menge Last, hier benötigt der Prozess zwischen 3% und 6% CPU, sobald das animierte REC Symbol angezeigt wird geht es auf 30% bis 35% hoch.

Wenn du alle Zeilen mit
..... path=symbols/animation/recOn_?.png,delay=300ms;
auf
..... ,path=symbols/recOn.png;
änderst ist die Animation aus.

Grüße
horchi

Alles anzeigen

hallo horchi,

ich muß zum thema "animiertes rec-symbol" nochmal lästig sein. ausgeschaltet ist es, allerdings kommt auch kein "nicht-animiertes" normales recsymbol, wenn eine aufnahme läuft. "symbols/recOn.png" müßte doch ein statisches bild sein

nutze data's AvP theme ...

gruß, ciax

Zitat

Originally posted by ciax
"symbols/recOn.png" müßte doch ein statisches bild sein

nutze data's AvP theme ...

ok, recOn.png gibt's beim aktuellen AvP nicht unter dem "symbols" verzeichnis. ich teste mal mit dem recOn.png aus "themes/avp/columnimages/recOn.png" ...

EDIT: so, und "avp/columnimages/recOn.png -> ../symbols/recOn.png" ist also ein link retour ins symbolsverzeichnis und der zeigt ins leere. wo ist nur das recOn.png hingekommen ..hab's nun einmal aus dem DeepBlue rüberkopiert ..

danke, ciax

@ Horchi

Ist es möglich das Du aus dem actuellen cvs/snv Stand in eine -rc3 erstellen kannst?
Sind ja doch ne Menge Änderungen in letzter Zeit eingeflossen...

Zur Info, ich hab hier noch ne klein Ansammlung an patches rumliegen die das eine oder andere fixen
( gcc-4.4 compile, glibc-2.10 compile, ffmpeg > 0.5 ( cvs stand ) da kommen noch ein paar Sache auf uns zu )
Ich würde die gerne gegen ne frische -rc* actualisieren und austesten.

und ja, ich könnte auch den svn auschecken...
erschwert mir aber die Arbeit letztendlich

Hallo,

Ich hab erst seit kurzem graphtft im Einsatz.
Genauer gesagt verwende ich es mit graphtft-fe.

Da bei mir die Bildschirm als ein großer virtueller eingerichtet sind, hab ich einen kleinen Patch gebastelt.
Er fügt folgende Parameter ein:
-x Offset> X Offset (default 0)
-y <Y Offset> Y Offset (default 0)

Damit kann man die Position des Fenster beim Öffnen definieren.
In meinem Fall kann ich damit graphtft-fe gleich so öffnen lassen das es im Bereich meines 2.Bildschirms sichbar ist.

Anzuwenden ist der Patch ganz einfach im graphtft-fe Verzeichniss mittels:
bzcat graphtft-fe_offset.patch.bz2 | patch

horchi oder alle Developer:
Ich weiß nicht wo ich das einwerfen muss, damit es eine Chance hat in den Code direkt aufgenommen werden. Bist du da der richtige Ansprechpartner?

Das ist meine erste Änderung an C-Code, aber irgendwie sind mir die übergebenen Parameter beim Aufruf von "XCreateSimpleWindow" ein bißchen komisch vorgekommen.
Ich hab sie nun entsprechend dieser Seite angepasst: http://www.eggdrop.ch/texts/xlib/
Den Parameter "depth" der bisher übergeben hab ich mal heraus genommen. Hab ich ihn nach "height" angegeben, wurde bei mir das ganze Fenster um Rund +12 Pixel (x und y) verschoben.

So hat nichts mit dem Patch zu tun, daher dachte mir ich mach einen 2.Post:
Seit dem ich graphtft im Einsatz hab ist bei mir der Aufbau des EPG z.B. was spielt es jetzt recht langsam. Ist das normal oder kann es sein das ich hier was falsch konfiguriert habe?

Installiert hab ich:
VDR-1.7.7 (inkl. Extensions Patch)
xineliboutput (aus dem SVN Stand letzter Woche)
graphtft (CVS von gerade eben & mein oben angeführter Patch)
Skinelchi

Falls das normal ist:
Liegt die Performancebremse an graphtft oder im Code vom VDR?

Bei mir mag mit dem Patch das Fenster nicht korrekt positionieren. Irgendwie kan ich angeben was ich will, die x und y Parameter bewirken nichts.

Kann das am Fenstermanager (fluxbox) liegen?

...Hagen

Scheint i.d.T. bei Fluxbox etwas anders zu laufen. Ich habe das Fenster jetzt über die Settings von Fluxbox auf den zweiten Schirm 'gezwungen'. Leider hat die Applikation keinen Fenstertitel (xprop WM_CLASS müsste gesetzt sein), dann wäre es noch einfacher. So gehe ich davon aus, dass Xine nicht betroffen ist und ansonsten keine anderen Fenster gestartet werden. Dann sieht die ~/.fluxbox/apps so aus:

[app] (name=) (class=)
  [Head]        {2}
  [Fullscreen]  {yes}
  [Deco]        {NONE}
[end]

Über "Deco None" verschwindet auch noch der Fensterrahmen mitsamt Kopf...

Hallo,

ist auch mal Unterstützung für das radio-plugin geplant? Ich habe es zwar geschafft den RDS-Titel noch in das Deep-Blue Theme einzubauen, aber Titel und Künstler gehen leider in cGraphTFTDisplay::OsdProgramme verloren.

Hallo,

beim Beenden des vdr (vdr-1.6.0-2) mit extension patch 72 stürzt der mir jedesmal ab. Der vdr ist selbst übersetzt unter Xubuntu 9.04 (32bit). Hier der Backtrace. Vieleicht kennt jemand die Lösung dafür. Alles complett neu übersetzt und installiert. Benuzte Plugins: streamdev-client, xine, graphtft, skinenigma.

Core was generated by `/usr/local/bin/vdr -c /etc/vdr -E /video0/epg.data -l 3 -L /usr/local/lib/vdr/p... (gekürzt)

Program terminated with signal 6, Aborted.
[New process 7115]
[New process 7134]
[New process 7120]
[New process 7127]
#0 0xb80b3430 in __kernel_vsyscall ()
(gdb) bt
#0 0xb80b3430 in __kernel_vsyscall ()
#1 0xb7d556d0 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7d57098 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0xb7d9324d in ?? () from /lib/tls/i686/cmov/libc.so.6
#4 0xb7d9a009 in ?? () from /lib/tls/i686/cmov/libc.so.6
#5 0xb7d9b1d7 in ?? () from /lib/tls/i686/cmov/libc.so.6
#6 0xb7d9b5b6 in free () from /lib/tls/i686/cmov/libc.so.6
#7 0xb7f7c231 in operator delete () from /usr/lib/libstdc++.so.6
#8 0xb73fbb16 in ~cDisplayImage (this=0xa91bea0) at ./theme.h:559
#9 0x0812b5f5 in cListBase::Clear (this=0x400) at tools.c:1831
#10 0xb7412d67 in cGraphTFTTheme::exit (this=0xa850050) at theme.c:1569
#11 0xb7425c1c in ~cGraphTFTTheme (this=0xa850050) at ./theme.h:862
#12 0x0812b5f5 in cListBase::Clear (this=0xb7450038) at tools.c:1831
#13 0xb7423a29 in ~cList (this=0xb7450038) at ../../../include/vdr/tools.h:404
#14 0xb7423ab5 in ~cGraphTFTThemes (this=0xb7450038) at ./theme.h:978
#15 0xb7d58f51 in __cxa_finalize () from /lib/tls/i686/cmov/libc.so.6
#16 0xb73e9e54 in __do_global_dtors_aux () from /usr/local/lib/vdr/plugins/libvdr-graphtft.so.1.6.0
#17 0xb7439780 in _fini () from /usr/local/lib/vdr/plugins/libvdr-graphtft.so.1.6.0
#18 0xb80c705f in ?? () from /lib/ld-linux.so.2
#19 0xb80c7937 in ?? () from /lib/ld-linux.so.2
#20 0xb8064c84 in ?? () from /lib/tls/i686/cmov/libdl.so.2
#21 0xb80c2036 in ?? () from /lib/ld-linux.so.2
#22 0xb806501c in ?? () from /lib/tls/i686/cmov/libdl.so.2
#23 0xb8064cba in dlclose () from /lib/tls/i686/cmov/libdl.so.2
#24 0x080fa2bf in ~cDll (this=0x9fe7860) at plugin.c:166
#25 0x0812b42f in cListBase::Del (this=0xbfccea90, Object=0x1bcb, DeleteObject=true) at tools.c:1794
#26 0x080f9dc5 in cPluginManager::Shutdown (this=0x9fe7860, Log=true) at plugin.c:500
#27 0x08131888 in main (argc=Cannot access memory at address 0x1bcb
) at vdr.c:1709
(gdb)

Ich habe die Ursache dafür bis jetzt leider noch nicht gefunden...

[EDIT]
Leider habe ich das Problem noch nicht gefunden. Der Absturz tritt auch mit 0.3.2-rc2 auf. Das Problem müssten doch auch andere haben, oder bemerkt nur keiner den Absturz beim Beenden?

Zum Thema core in meinem letzten Beitrag (Ich nutzte gcc 4.3.3 unter ubuntu 9.04). Der vorherige Absturz kommt wenn mehr als ein Theme im graphtft themes Ordner liegt. Lasse ich nur noch eines dort (egal welches) kriege ich diesen anderen Absturz:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb3aa6b90 (LWP 4631)]
0xb7da3816 in ?? () from /lib/libgcc_s.so.1
(gdb) bt
#0 0xb7da3816 in ?? () from /lib/libgcc_s.so.1
#1 0xb7da4015 in ?? () from /lib/libgcc_s.so.1
#2 0xb7da414a in _Unwind_ForcedUnwind () from /lib/libgcc_s.so.1
#3 0xb7f86f36 in _Unwind_ForcedUnwind () from /lib/tls/i686/cmov/libpthread.so.0
#4 0xb7f84961 in __pthread_unwind () from /lib/tls/i686/cmov/libpthread.so.0
#5 0xb7f7c35b in sigcancel_handler () from /lib/tls/i686/cmov/libpthread.so.0
#6 <signal handler called>
#7 0xb7fc6430 in __kernel_vsyscall ()
#8 0xb7d157b1 in select () from /lib/tls/i686/cmov/libc.so.6
#9 0x08127bbd in cFile::FileReady (FileDes=<value optimized out>, TimeoutMs=100) at tools.c:1371
#10 0xb7978d1a in ?? ()
#11 0x0812240c in cThread::StartThread (Thread=0x95e1c70) at thread.c:245
#12 0xb7f7e4ff in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#13 0xb7d1d49e in clone () from /lib/tls/i686/cmov/libc.so.6
(gdb)

Beide Abstürze sind jedesmal reproduzierbar. Und wie gesagt, nehme ich graphtft raus ist alles ok, kein core mehr.

Jegliche Ideen / Lösungen sind willkommen!

[EDIT 01.09 15:00]
Habe mir den Code mal genauer angeschaut. Dabei ist mir in cTouchThread::Stop() aufgefallen, das der Cancel() ohne Timeout benutzt wird. Meiner Ansicht nach könnte das zu dem 2. Absturz (in cTouchThread::Action) führen. Kann ich aber erst heute Abend testen. Schnell noch mal die Version 0.3.3 aus dem cvs geholt und reingeschaut. Dort wird schon Cancel(3) benutzt, das lässt mich hoffen...

Vieleicht teste ich auch mal die CVS-Version an um zu schauen, ob der 1. Absturz (mehr als ein Theme im Ordner) vieleicht auch schon gefixt ist (vieleicht tut es auch schon der Cancel()).

So, Abstürze getestet:

- Cancel(3) behebt den 2. Absturz.
- Die CVS-Version behebt auch den 1. Absturz (die Cancel-Änderung ist auch mit drin).

Damit ist alles wieder ok.

nabend

hab ein problem mit meinem tft, bekomme nur ein bild wenn ich den vdr beende.
der log sieht so aus:

Sep  2 23:55:12 bex-vdr vdr: [5010] starting plugin: graphtft
Sep  2 23:55:12 bex-vdr vdr: [5010] Device is '/dev/fb0'
Sep  2 23:55:12 bex-vdr vdr: [5032] EPGSearch: conflictcheck thread started (pid=5010, tid=5032)
Sep  2 23:55:12 bex-vdr vdr: [5010] Loading themes
Sep  2 23:55:12 bex-vdr vdr: [5010] loading /etc/vdr/plugins/graphTFT/themes/avp/avp.theme
Sep  2 23:55:12 bex-vdr vdr: [5010] loading /etc/vdr/plugins/graphTFT/themes/DeepBlue/DeepBlue.theme
Sep  2 23:55:12 bex-vdr vdr: [5010] Loaded 2 themes
Sep  2 23:55:12 bex-vdr vdr: [5010] Activated theme 'Alien vs. Predator 0.3.1'
Sep  2 23:55:12 bex-vdr vdr: [graphTFT] Listener established!
Sep  2 23:55:12 bex-vdr vdr: [5036] GraphTFT plugin tcp communication thread started (pid=5010)
Sep  2 23:55:12 bex-vdr vdr: [graphTFT] Open touch device '/dev/input/event3'
Sep  2 23:55:12 bex-vdr vdr: [5037] TouchTFT-Thread thread started (pid=5010, tid=5037)
Sep  2 23:55:12 bex-vdr vdr: [graphTFT] fb settings are (800/480) with a color depth of (16)
Sep  2 23:55:12 bex-vdr vdr: [graphTFT] Info: Font path configured to './fonts:../../fonts'
Sep  2 23:55:12 bex-vdr vdr: [graphTFT] Info: Adding font path '/etc/vdr/plugins/graphTFT/themes/avp/./fonts'
Sep  2 23:55:12 bex-vdr vdr: [graphTFT] Info: Adding font path '/etc/vdr/plugins/graphTFT/themes/avp/../../fonts'
Sep  2 23:55:12 bex-vdr vdr: [graphTFT] Info: Adding font path '/etc/vdr/plugins/graphTFT/fonts/'
Sep  2 23:55:12 bex-vdr vdr: [graphTFT] GraphTFT plugin display thread started (pid=5010)
Sep  2 23:55:12 bex-vdr vdr: [5010] setting current skin to "EnigmaNG"
Sep  2 23:55:12 bex-vdr vdr: [5010] loading /etc/vdr/themes/EnigmaNG-DarkBlue.theme
Sep  2 23:55:12 bex-vdr vdr: [5039] LIRC remote control thread started (pid=5010, tid=5039)
Sep  2 23:55:12 bex-vdr vdr: [5010] ERROR: remote control XineRemote not ready!
Sep  2 23:55:12 bex-vdr vdr: [5010] remote control graphtft-fe - keys known
Sep  2 23:55:12 bex-vdr vdr: [5010] remote control LIRC - keys known
Sep  2 23:55:12 bex-vdr vdr: [graphTFT] Open touch device '/dev/input/event3'
Sep  2 23:55:13 bex-vdr vdr: [5024] CAM 1: module present
Sep  2 23:55:13 bex-vdr vdr: [5027] CAM 3: module present
Sep  2 23:55:14 bex-vdr vdr: [5024] CAM 1: module reset
Sep  2 23:55:14 bex-vdr vdr: [5027] CAM 3: module reset
Sep  2 23:55:14 bex-vdr vdr: [5024] CAM 1: module ready
Sep  2 23:55:14 bex-vdr vdr: [5025] CAM 2: module ready
Sep  2 23:55:14 bex-vdr vdr: [5027] CAM 3: module ready
Sep  2 23:55:15 bex-vdr vdr: [5024] CAM 1: replies to QUERY - multi channel decryption possible
Sep  2 23:55:15 bex-vdr vdr: [5025] CAM 2: replies to QUERY - multi channel decryption possible
Sep  2 23:55:15 bex-vdr vdr: [5027] CAM 3: replies to QUERY - multi channel decryption possible
Sep  2 23:55:15 bex-vdr vdr: [graphTFT] Section changed from '<none>' to 'NormalSysinfo'
Sep  2 23:55:15 bex-vdr vdr: [graphTFT] init libgtop (2.22)
Sep  2 23:55:16 bex-vdr vdr: [5010] switching to channel 1
Sep  2 23:55:16 bex-vdr vdr: [5043] receiver on device 1 thread started (pid=5010, tid=5043)
Sep  2 23:55:16 bex-vdr vdr: [5044] TS buffer on device 1 thread started (pid=5010, tid=5044)
Sep  2 23:55:16 bex-vdr vdr: [5010] OSD size changed to 1280x720 @ 16:9
Sep  2 23:55:16 bex-vdr vdr: [5045] EnigmaNG effects thread started (pid=5010, tid=5045)
Sep  2 23:55:16 bex-vdr vdr: [5043] cVideoRepacker: switching to MPEG1/2 mode
Sep  2 23:55:16 bex-vdr vdr: [5043] cVideoRepacker: operating in MPEG1/2 mode
Sep  2 23:55:21 bex-vdr vdr: [5045] EnigmaNG effects thread ended (pid=5010, tid=5045)
Sep  2 23:55:32 bex-vdr vdr: [5032] EPGSearch: timer conflict check started
Sep  2 23:55:33 bex-vdr vdr: [5071] EnigmaNG effects thread started (pid=5010, tid=5071)
Sep  2 23:55:33 bex-vdr vdr: [5010] switching to channel 2
Sep  2 23:55:33 bex-vdr vdr: [5044] TS buffer on device 1 thread ended (pid=5010, tid=5044)
Sep  2 23:55:33 bex-vdr vdr: [5043] buffer stats: 142316 (6%) used
Sep  2 23:55:33 bex-vdr vdr: [5043] receiver on device 1 thread ended (pid=5010, tid=5043)
Sep  2 23:55:33 bex-vdr vdr: [5073] receiver on device 1 thread started (pid=5010, tid=5073)
Sep  2 23:55:33 bex-vdr vdr: [5074] TS buffer on device 1 thread started (pid=5010, tid=5074)
Sep  2 23:55:33 bex-vdr vdr: [5073] TS continuity error (0)
Sep  2 23:55:33 bex-vdr vdr: [5073] TS continuity error (3)
Sep  2 23:55:33 bex-vdr vdr: [5073] cVideoRepacker: switching to MPEG1/2 mode
Sep  2 23:55:33 bex-vdr vdr: [5073] cVideoRepacker: operating in MPEG1/2 mode
Sep  2 23:55:33 bex-vdr vdr: [5073] TS continuity error (15)
Sep  2 23:55:34 bex-vdr vdr: [5016] changing pids of channel 2 from 110+110=2:120=deu,121=2ch;125=deu:0:130 to 110+110=2:120=deu,121=2ch;125=deu:131=deu:130
Sep  2 23:55:34 bex-vdr vdr: [5010] retuning due to modification of channel 2
Sep  2 23:55:34 bex-vdr vdr: [5010] switching to channel 2
Sep  2 23:55:34 bex-vdr vdr: [5010] cTS2PES got 0 TS errors, 2 TS continuity errors
Sep  2 23:55:34 bex-vdr vdr: [5010] cTS2PES got 0 TS errors, 1 TS continuity errors
Sep  2 23:55:34 bex-vdr vdr: [5074] TS buffer on device 1 thread ended (pid=5010, tid=5074)
Sep  2 23:55:34 bex-vdr vdr: [5073] buffer stats: 94940 (4%) used
Sep  2 23:55:34 bex-vdr vdr: [5073] receiver on device 1 thread ended (pid=5010, tid=5073)
Sep  2 23:55:34 bex-vdr vdr: [5075] receiver on device 1 thread started (pid=5010, tid=5075)
Sep  2 23:55:34 bex-vdr vdr: [5076] TS buffer on device 1 thread started (pid=5010, tid=5076)
Sep  2 23:55:34 bex-vdr vdr: [5075] cVideoRepacker: switching to MPEG1/2 mode
Sep  2 23:55:34 bex-vdr vdr: [5075] cVideoRepacker: operating in MPEG1/2 mode
Sep  2 23:55:35 bex-vdr vdr: [5016] changing pids of channel 276 from 0+0=2:410=deu:0:0 to 0+0=0:410=deu:0:0
Sep  2 23:55:35 bex-vdr vdr: [5016] changing pids of channel 273 from 0+0=2:710=deu:0:0 to 0+0=0:710=deu:0:0
Sep  2 23:55:35 bex-vdr vdr: [5016] changing pids of channel 274 from 0+0=2:810=deu:0:0 to 0+0=0:810=deu:0:0
Sep  2 23:55:38 bex-vdr vdr: [5071] EnigmaNG effects thread ended (pid=5010, tid=5071)
Sep  2 23:55:39 bex-vdr vdr: [5032] EPGSearch: timer conflict check finished
Sep  2 23:55:42 bex-vdr vdr: [5083] EnigmaNG effects thread started (pid=5010, tid=5083)
Sep  2 23:55:42 bex-vdr vdr: [5010] EnigmaNG: cPluginSkinEnigma::LoadChannelLogo: LOGO "Radio Bremen TV.xpm" NOT FOUND in /etc/vdr/plugins/skinenigmang/[hq]logos
Sep  2 23:55:42 bex-vdr vdr: [5010] switching to channel 3
Sep  2 23:55:42 bex-vdr vdr: [5076] TS buffer on device 1 thread ended (pid=5010, tid=5076)
Sep  2 23:55:42 bex-vdr vdr: [5075] buffer stats: 115244 (5%) used
Sep  2 23:55:42 bex-vdr vdr: [5075] receiver on device 1 thread ended (pid=5010, tid=5075)
Sep  2 23:55:42 bex-vdr vdr: [5084] receiver on device 1 thread started (pid=5010, tid=5084)
Sep  2 23:55:42 bex-vdr vdr: [5085] TS buffer on device 1 thread started (pid=5010, tid=5085)
Sep  2 23:55:42 bex-vdr vdr: [5084] TS continuity error (14)
Sep  2 23:55:42 bex-vdr vdr: [5084] TS continuity error (8)
Sep  2 23:55:42 bex-vdr vdr: [5084] cVideoRepacker: switching to MPEG1/2 mode
Sep  2 23:55:42 bex-vdr vdr: [5084] cVideoRepacker: operating in MPEG1/2 mode
Sep  2 23:55:45 bex-vdr vdr: [5016] changing pids of channel 403 from 0+0=2:2001=deu;2002=deu:0:0 to 0+0=0:2001=deu;2002=deu:0:0
Sep  2 23:55:47 bex-vdr vdr: [5083] EnigmaNG effects thread ended (pid=5010, tid=5083)
Sep  2 23:56:00 bex-vdr vdr: [graphTFT] still running, tcp is not connected

sieht soweit doch alles gut aus, das bild wird auch korrekt angezeigt, allerdings ja nur wenn der vdr beendet wird.
Die letzte zeile, liegt da das problem ? googlen brachte leider kein erfolg.

Mahlzeit

Keiner ne idee ? Gibs ne möglichkeit im laufenden vdr betrieb ein "signal"/"bild" manuell ans display zu schicken ?

Kommt mir so vor als würde das signal von irgend etwas geblockt, denn wie gesagt wenn man den vdr beendet wird plötzlich die info von letzten sender im display angezeigt.

Hab auch schon mal in der config auf log 10 geschaltet, dann lässt sich im log aber auch keine fehler meldung erkennen, zumindest für mich laien nicht.

weiß ned mehr weiter

EDIT:

also wenn ich während laufenden vdr ein "echo "" >/dev/fb0" wird ein aktuelles Signal/bild von graphtft angezeigt.
Warum wird das nur nicht automatisch gemacht ?

Hi,

beschreib doch mal wie? du was? angeschlossen hast?

Willst du per Framebuffer ausgeben und gleichzeitig einen X-Server in Betrieb haben, beide Post sind sehr konfus...., dass man das überhaupt blicken könnte.

Gruß
Wolfgang

hy wbreu

also display ist über usb angeschloßen, der treiber stellt ein /dev/fb0 zur verfügung.

als test system hab ich debian lenny 64bit gnome mit vdr 1.7.7 plain, nur der graphtft patch aus etobis packet. Xserver aktiv .

wenn der vdr läuft wird kein bild im display angezeigt. beende ich vdr dann kommt ein bild mit den daten des zuletzt gesehen senders also die epg daten.

nun hab ich mal während der vdr läuft ( xine über xserver) einfach ein echo "" > /dev/fb0 gemacht, und siehe da ein aktuelles graphtft bild wird auf dem display angezeigt. Es scheint also so als wenn irgendwas die automatische aktualisierung blockiert.

Also das problem ist eigentlich "nur" das das display nicht aktualisiert wird, weder wenn ich den sender umschalte noch sonst wie. das einzige was das display aktualisieren lässt ist ein in die console gehacktes [ echo "" > /dev/fb0 ] .

Im Logfile steht auch nix von irgendwelchen fehlern bezüglich graphtft, das scheint alles ordnungsgemäß zu laufen.

Keine ahnung woran das liegt

So mit nem dirty Hack gehts nun. soweit so gut, allerdings ist mir aufgefallen das wenn man die kanalliste aufruft, diese erst im display erscheint und dann erst auf dem fernseher, nach knopfdruck dauert es ne gefühlte sec bis die liste auf dem fernseher zu sehen ist. Als ob erstmal graphtft bedient wird, und dann erst der vdr/xine.

Ist das bei euch auch so ?

Ansonsten ein Klasse Plugin ! Riesen Dank an den/die Programmierer .

nabend nochmal

auch wenn ich hier den allein unterhalter spiel, nach ein paar tests scheints wirklich so zu sein als ob graphtft immer zuerst bedient wird, und dann erst das frontend.

hier mal ein video damit man sehen kann was ich mein. desweiteren ist mir aufgefallen das beim beenden der programmübersicht erst kurz noch die "programmdaten" angezeigt werden, obwohl die zurücktaste gedrückt wurde.
also eigentlich sollte das menü angezeigt werden, es wird aber kurz "dazwischen" die programm info angezeigt.

hab nur ich das problem ?

hoffe man kann das auf dem video erkennen.

>> VIDEO <<

P.S.: wenn der browser das video nicht abspielt, rechte maustaste speichern unter ...