Gibt es keine Lösung für das Problem der SW Darstellung des graphtft? Oder hat das Problem sonst niemand?
Wo kann ich denn nach sehen? Die Ausgabe erfolgt über die 2.DVB karte.
Bitte um tipps - Danke
Gibt es keine Lösung für das Problem der SW Darstellung des graphtft? Oder hat das Problem sonst niemand?
Wo kann ich denn nach sehen? Die Ausgabe erfolgt über die 2.DVB karte.
Bitte um tipps - Danke
ZitatOriginal von ischgucke
Gibt es keine Lösung für das Problem der SW Darstellung des graphtft? Oder hat das Problem sonst niemand?
Wo kann ich denn nach sehen? Die Ausgabe erfolgt über die 2.DVB karte.
Bitte um tipps - Danke
Hi,
ich glaube das Problem gab es schon einmal, damals lag es an einer falschen Auflösung der DVB Ausgabe seitens des Plugin. Diese habe ich als Bugfix seit dem hardcoded auf 720x576 gesetzt. Ggf. geht hier beim Skalieren des Themes etwas schief (nur eine Vermutung, ich kann die DVB Ausgabe hier nicht testen).
Hast du es schon mal mit dem DeepBlue versucht, das ist in 720x576 erstellt und muss damit nicht skaliert werden.
Grüße
horchi
Here it's an updated italian trasnlation of the plugin.
Hope this can be usefull.
Diego Pierotto.
Bei mir startet der VDR nicht wenn ich graphtft aktiviere.
Feb 12 21:15:18 vdr vdr: [9579] initializing plugin: nordlichtsepg (0.9): Erweitertes EPG
Feb 12 21:15:18 vdr vdr: [9579] initializing plugin: osdteletext (0.5.1): Displays teletext on the OSD
Feb 12 21:15:18 vdr vdr: [9579] initializing plugin: pluginsetup (0.0.6): Plugin Setup
Feb 12 21:15:18 vdr vdr: [9579] initializing plugin: radio (0.2.4): Hintergr.Bilder/RDS-Text für Radiosender
Feb 12 21:15:18 vdr vdr: [9579] initializing plugin: skinclassic (0.0.2): Classic VDR Skin-Plugin
Feb 12 21:15:18 vdr vdr: [9579] initializing plugin: sleeptimer (0.7): Sleep-Timer for VDR
Feb 12 21:15:18 vdr vdr: [9579] initializing plugin: streamdev-client (0.3.3-20070921): VTP Streaming Client
Feb 12 21:15:18 vdr vdr: [9579] initializing plugin: streamdev-server (0.3.3-20070921): VDR Streaming Server
Feb 12 21:15:18 vdr vdr: [9579] initializing plugin: sysinfo (0.1.0a): System information plugin
Feb 12 21:15:18 vdr vdr: [9579] initializing plugin: undelete (0.0.6): undelete for recordings
Feb 12 21:15:18 vdr vdr: [9579] setting primary device to 1
Feb 12 21:15:18 vdr vdr: [9579] assuming manual start of VDR
Feb 12 21:15:18 vdr vdr: [9579] SVDRP listening on port 2001
Feb 12 21:15:18 vdr vdr: [9579] skin "EnigmaNG" not available - using "classic" instead
Feb 12 21:15:18 vdr vdr: [9579] loading /etc/vdr/themes/classic-default.theme
Feb 12 21:15:18 vdr vdr: [9579] starting plugin: skinenigmang
Feb 12 21:15:18 vdr vdr: [9579] starting plugin: graphtft
Feb 12 21:15:18 vdr vdr: [9579] Device is 'not configured, probing'
Feb 12 21:15:18 vdr vdr: [9579] Loading themes
Feb 12 21:15:18 vdr vdr: [9579] loading /etc/vdr/plugins/graphTFT/themes/avp/avp.theme
Feb 12 21:15:18 vdr vdr: [9583] video directory scanner thread ended (pid=9579, tid=9583)
Feb 12 21:15:18 vdr vdr: [9584] video directory scanner thread ended (pid=9579, tid=9584)
Feb 12 21:15:18 vdr vdr: [9579] loading /etc/vdr/plugins/graphTFT/themes/DeepBlue/DeepBlue.theme
Feb 12 21:15:18 vdr vdr: [9579] Loaded 2 themes
Feb 12 21:15:18 vdr vdr: [9579] Activated theme 'Alien vs. Predator 0.3.1'
Feb 12 21:15:18 vdr vdr: [9596] TouchTFT-Thread thread started (pid=9579, tid=9596)
Alles anzeigen
Irgendwie bleibts dort hängen. Woran könnte das liegen? Das TouchDevice befindet sich unter /dev/input/touchtft, das hab ich auch in der setup.conf so eingestellt. Oder gibts für graphTFT eine seperate conf? Habe den VDR selbstgebaut auf Debian.
EDIT: Sehe noch kurz den Start-Screen von graphtft.
Hello Gringooo,
thanks, i will take care of it in the next version.
He TheChief,
so ist schweer zu sagen was da schief läuft, wie es sich anhört crashed der VDR beim aktievieren der Touch-Schnittstelle, kannst du bitte den BT posten?
Danke, Grüße
Jörg
hi,
mal ne frage zur weiteren entwicklung
gibts pläne auch für die developer version von vdr anpassungen vorzunehmen?
momentan compiliert es nicht mehr mit vdr 1.7.4
in der dspitems.c muss man die Variable FRAMESPERSEC durch DEFAULTFRAMESPERSECOND ersetzen aber dann schlagen doch die änderungen in der remux.c durch
g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -fPIC -g -ggdb -O0 -c -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DUSE_DVLFRIENDLYFNAMES -DUSE_GRAPHTFT -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"graphtft"' -DHAVE_IMAGE_MAGICK -DHAVE_IMLIB -DWITH_SYSINFO -DWITH_TCP_COM -DWITH_TOUCH -DHAVE_DFB -DHAVE_FFMPEG -DHAVE_SWSCALE -I/usr/src/v4l-dvb/linux/include -I../../../include -I/usr/src/v4l-dvb/linux/include -I. -I./imlibrenderer -I./imlibrenderer/fbrenderer -I./imlibrenderer/dvbrenderer -I./dfbrenderer -I./imlibrenderer/dmyrenderer `pkg-config libgtop-2.0 --cflags` `directfb-config --cflags` -I/usr/include/libavcodec -I/usr/include/libavutil -I/usr/include/libavcodec -I/usr/include/libavutil/libavcodec `pkg-config libswscale --cflags` -o transfer.o transfer.c
transfer.c: In constructor ‘cGraphTFTTransfer::cGraphTFTTransfer(Renderer*, const cChannel*)’:
transfer.c:33: error: new initializer expression list treated as compound expression
transfer.c:33: error: no matching function for call to ‘cRemux::cRemux(const int*)’
../../../include/vdr/remux.h:25: note: candidates are: cRemux::cRemux()
../../../include/vdr/remux.h:25: note: cRemux::cRemux(const cRemux&)
make: *** [transfer.o] Fehler 1
ZitatAlles anzeigenOriginal von IG88
horchi
hi,
mal ne frage zur weiteren entwicklung
gibts pläne auch für die developer version von vdr anpassungen vorzunehmen?
momentan compiliert es nicht mehr mit vdr 1.7.4
in der dspitems.c muss man die Variable FRAMESPERSEC durch DEFAULTFRAMESPERSECOND ersetzen aber dann schlagen doch die änderungen in der remux.c durch
Codeg++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -fPIC -g -ggdb -O0 -c -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DUSE_DVLFRIENDLYFNAMES -DUSE_GRAPHTFT -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"graphtft"' -DHAVE_IMAGE_MAGICK -DHAVE_IMLIB -DWITH_SYSINFO -DWITH_TCP_COM -DWITH_TOUCH -DHAVE_DFB -DHAVE_FFMPEG -DHAVE_SWSCALE -I/usr/src/v4l-dvb/linux/include -I../../../include -I/usr/src/v4l-dvb/linux/include -I. -I./imlibrenderer -I./imlibrenderer/fbrenderer -I./imlibrenderer/dvbrenderer -I./dfbrenderer -I./imlibrenderer/dmyrenderer `pkg-config libgtop-2.0 --cflags` `directfb-config --cflags` -I/usr/include/libavcodec -I/usr/include/libavutil -I/usr/include/libavcodec -I/usr/include/libavutil/libavcodec `pkg-config libswscale --cflags` -o transfer.o transfer.c transfer.c: In constructor ‘cGraphTFTTransfer::cGraphTFTTransfer(Renderer*, const cChannel*)’: transfer.c:33: error: new initializer expression list treated as compound expression transfer.c:33: error: no matching function for call to ‘cRemux::cRemux(const int*)’ ../../../include/vdr/remux.h:25: note: candidates are: cRemux::cRemux() ../../../include/vdr/remux.h:25: note: cRemux::cRemux(const cRemux&) make: *** [transfer.o] Fehler 1
Hi,
diese Version würde ich auch sehr gern verwenden und dann auch sofort das Plugin anpassen!
Leider hänge ich hier auf der 1.7.0 fest da ich keine neuere VDR Version zum laufen bewegen kann :(. Ich verwende auf meinem Entwicklungssystem xineliboutput da ich dort keine FF Karte habe. xineliboutput scheint noch nicht mit der neues Version (TS) zusammenzuarbeiten, wenigstens war das Ende letzten Jahres noch so.
Grüße
horchi
Dann solltest Du mal den aktuellen CVS-Stand vom Xineliboutput-Plugin auschecken. Damit läuft vdr-1.7.4 bei mir ziemlich gut.
hi,
habe mal ein wenig rumprobiert und erstmal einen schnellen fix gefunden
da ich mit mit /dev/fb0 arbeite brauche ich vermutlich nicht was in der transfer.c abläuft, das zeug ist für dvbrenderer sprich ff-karte
habe jetzt in der transfer.c die definition der variable _remux auskommentiert, das plugin compiliert und funktioniert auch
da ich kein c++ kann ist das ein wenig raten mit probieren aber was solls es geht
> xineliboutput scheint noch nicht mit der neues Version (TS)
> zusammenzuarbeiten
ich nutze eine eHD und die ist von haus aus schon ts fähig da rmm hd-inhalte schon immer in ts abwickelt
ZitatOriginal von udobroemme
Dann solltest Du mal den aktuellen CVS-Stand vom Xineliboutput-Plugin auschecken. Damit läuft vdr-1.7.4 bei mir ziemlich gut.
Danke werde ich versuchen, mein letzter Test liegt auch schon wieder 2 Monate zurück
Grüße
Jörg
hallo horchi,
ich zitiere jetzt mal nur den user "gda":
ZitatOriginal von gda
[..]Die 1800 MHz
hat er auch nur weil das Graphtft-Plugin soviel Last macht.
Gestern habe ich gesehen, dass das wahrscheinlich an der Animation vom
REC-Symbol liegt, das werde ich heute mal abschalten.
das verhalten muß ich hier zuhause auch bestätigen - nutze das AvP von "data" (deepblue habe ich nicht getestet). so sieht's mit "top" aus:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
7239 root 20 0 700m 92m 16m S 47 4.6 23:23.03 vdr
22255 root 20 0 146m 8416 2940 S 33 0.4 1:52.30 graphtft-fe
..
eventuell sollte auch der vdr-prozess(e) beim aufnehmen (rec) nicht soviel in anspruch nehmen?
im einsatz ist "svn-r22".
gruß, ciax
edit: vllt. doch nicht ganz unwichtig :): "gda" hat - soweit ich es ganz stark in erinnerung habe - das REC-Symbol "abgeschaltet" ..
Hi,
xineliboutput und VDR 1.7.4 funzen prima !
im SVN ist nun Ronys Makefile Patch, die Portierung für den aktuellen VDR und die italienische Übersetzung enthalten.
Gringooo
the SVN is updateted and include your update of the italian translation.
Due to i try to support the old i18n and the new gettext way i always put new translations into i18n.c and create the po files using the i18n-to-gettext.pl script. Therefore your updates in the po file got lost on next i18n.c change :(. If i can find some time (and i have a mind to ;)) i try to merge your changes to i18n.c.
Grüße
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
ZitatAlles anzeigenOriginal von 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
danke! gruß, ciax
ZitatHe TheChief, so ist schweer zu sagen was da schief läuft, wie es sich anhört crashed der VDR beim aktievieren der Touch-Schnittstelle, kannst du bitte den BT posten? Danke, Grüße Jörg
Könntest Du mir nochmal sagen, wie ich das mache?
ZitatOriginal von TheChief
Könntest Du mir nochmal sagen, wie ich das mache?
Hi,
eigentlich ist das schon so oft beschrieben das es eine Sünde ist hier nochmals Platz dafür zu opfern Gibt glaube ich auch ein Howto im VDR Wiki.
Wie auch immer.
1. Core files freigeben
#> ulimit -c unlimited
2. VDR in diesem Environment starten
3. Den Absturz provozieren (geht ja bei dir beim Starten von selbst)
4. mit gdb ansehen
#> gdb /wo..auch..immer/vdr ./core-file-name
5. am gdb Prompt bt eingeben und Ausgabe posten
Grüße
horchi
Danke, habs inzwischen ans Laufen gebracht.
Allerdings wird mein System ziemlich langsam, wenn ich graphtft aktiviere. Mit 800x600 gehts einigermaßen, aber bei 1024x768 ist der VDR kaum nutzbar. Die CPU Last geht sofort auf 70-100%, sobald ich ein Menü öffne. Hab eben nur nen AMD 2500+ drin.
Kann ich da noch irgendwas tun? Die 0.1.19alpha lief damals noch wesentlich flotter.
Hi,
mit welchen Theme? Welches Ausgabe Device verwendest du?
Du kannst den Log Level des Plugins mal hoch drehen und ein Log Ausschnitt (wenn du im Menü bist du die hohe last hast) posten, ggf. erkennt man was. So hoch sollte die Last nicht sein
Grüße
horchi
Sowohl DeepBlue als auch AvP. Ausgabe über FB.
Werd mal probieren, ob ich dem VDR ein Log eintlocken kann.
EDIT: Anbei mal das LOG
EDIT2: Hmm, X und Y Offset haben bei mir auch keinen Einfluss. Auf 1024x768 zeigt es an der korrekten Position an, bei 800x600 liegt das Plugin teilweise ausserhalb des TFTs. Hab mal X Offset auf 100 und Y auf 50 gestellt, passieren tut aber nichts, auch nicht nach Neustart des VDR. Hab übrigens die CVS Version von Deinem Plugin.
EDIT3: Erledigt, musste noch den korrekten Mode in der directfbrc einstellen.
Hi,
noch ein paar Fragen zum eingrenzen:
- Passiert das in allen Menüs oder nur in bestimmten?
- Du verwendest SkinEnigma?
- ist wenn die Last so hoch ist ein animiertes Skin Item zu sehen, wie z.B. das REC Symbol oder eine Laufschrift, das scrollen einer Menüzeile, ... ?
Zu EDIT3, mit erledigt meinst du, vermute ich, das Problem mit dem Offset nicht das mit der hohen Last?
Grüße
horchi
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!