[ANNOUNCE] graphtft 0.3.1

Zitat

Original 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

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

Zitat

Original 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

Code

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

Alles anzeigen

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

Zitat

Original 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

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

Zitat

Original 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

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

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