videotext plugin fehlerhaft ??

Beitrag von **mb405** » Freitag 2. September 2005, 10:26

also ich hab seit kurzen einen fehler im videotext.

[CPlugins] (id,val):(end_y,555)

[CPlugins] (id,val):(end_x,680)
[CPlugins] (id,val):(off_y,30)
[CPlugins] (id,val):(off_x,4)

[CPlugins] (id,val):(video_format,2)
[CPlugins] (id,val):(pid_vtxt,105)
[CPlugins] (id,val):(fd_lcd,21)
[CPlugins] (id,val):(rcblk_rep,150)

[CPlugins] (id,val):(rcblk_anf,150)
[CPlugins] (id,val):(fd_rcinput,18)
[CPlugins] (id,val):(fd_framebuffer,3)
[CPlugins] try exec...
TuxTxt 1.91
avia_gt_gv: set_input_mode (mode=2)

avia_gt_gv: set_input_size (width=720, height=576)

TuxTxt <pthread_create>: Interrupted system call
TuxTxt: init ok

es kommt beim aufruf nur unten die leiste mit den zahlen, und oben rechts ein graues fenster.

Beitrag von **Nico 77** » Freitag 2. September 2005, 14:54

Ist leider schon lange so, wird halt anscheinend nur noch für die Dream entwickelt.

http://forum.tuxbox-cvs.sourceforge.net ... highlight=

Beitrag von **Houdini** » Freitag 2. September 2005, 15:05

das Problem liegt nicht direkt am Tuxtxt, sonder am System selber, wenn nicht renügend Systemresourcen/RAM zur verfügung steht.
Der Bugfix ist also generell Speicherverbrauch reduzieren, insbesonders die durch die letzten Änderungen (womöglich von mir

) eingebrachten Memoryleaks rauszuwanzen.

Houdini

Beitrag von **Nico 77** » Freitag 2. September 2005, 15:17

Ohh, gut zu wissen.

Das Problem besteht leider schon sehr lange lange.

Beitrag von **Houdini** » Freitag 2. September 2005, 15:25

den Fehler hab ich noch nie gesehen

Beitrag von **Nico 77** » Freitag 2. September 2005, 15:27

Mal bißchen im Teletext schauen und das nach ein paar Tagen wiederholen dann tritt das auf, allerdings weiß nicht genau ob das mit der 1.91 noch ist.

Beitrag von **Houdini** » Freitag 2. September 2005, 15:42

Das erklärt einiges,
meine Box läuft nur maximal 20 Stunden, nachts wird der ganze AV Schrank vom Netz genommen. Das bestätigt meinen Verdacht, dass vor meine Änderungen auch schon Memoryleaks gab.
Ich werde die schon finden

Beitrag von **mb405** » Freitag 2. September 2005, 16:11

@Houdini
kann dir zustimmen, die leaks gab es schon immer. ich bin der festen überzeugung, das es am sectionsd liegt. denn mach einen neustart dessen, ist wieder mehr freier platz.

Beitrag von **Houdini** » Freitag 2. September 2005, 16:22

Das nach Neustart der sectionsds wieder mehr freier Speicher vorhanden ist ist klar da sectionsd die epginfos von allen sendern abspeichert, nach neustart hat er erst ein paar wieder eingesammelt.
Ich denke ich habe noch einige leaks im sectionsdclient gefunden, ob und wieoft die jeweiligen Funktionen überhaupt aufgerufen werden ist mir noch unklar.

Beitrag von **mb405** » Freitag 2. September 2005, 16:38

Houdini
Du machst das schon

Houdini hat geschrieben:Das nach Neustart der sectionsds wieder mehr freier Speicher vorhanden ist ist klar da sectionsd die epginfos von allen sendern abspeichert, nach neustart hat er erst ein paar wieder eingesammelt.
Ich denke ich habe noch einige leaks im sectionsdclient gefunden, ob und wieoft die jeweiligen Funktionen überhaupt aufgerufen werden ist mir noch unklar.

Hi,

dann probier die mal ein nfsroot system mit profiling zu bauen, dann sieht man sehr gut, wann, welche funktion wie oft aufgerufen wird. vielleicht kann man es auch mal mit valgrind starten.

gruss woglinde

Beitrag von **Houdini** » Sonntag 4. September 2005, 21:19

Momentan debugge ich mit den glibc eigenen Funktionen (#include <mcheck.h>)
Ein Aufruf von mtrace() ganz vorne in sectionsd/main einbauen
ein bißchen hin und herzappen, epg schauen und dann hab ich den houskeeping thread dazu missbraucht alle events zu löschen.
Aber dann bleiben eine ganze Reihe leakende Speicherblocks mit aufsteigender Größe übrig, die ich noch nicht zuordenn kann.

Wie funktioniert denn das mit dem profiling?

Houdini

Beim derzeitigen Stand sieht Tuxtext etwas seltsam aus. Als ob der Zeichensatz zu groß für die Zeile wäre. Ist das CVS-bedingt, oder ist in JtG-Snap vom 6.9. da was verquer?
cu
Jens

Ergänzung: Bei 4:3-Darstellung ist alles ok, scheint nur bei verkleinerter Darstellung auf 16:9 aufzutreten.
cu
Jens

Da gibt's wohl zwei Ursachen:

1.) Die Default-Einstellungen für die Tuxtxt-Position in Enigma sind zu klein, d.h. wenn man die nicht anpasst, passen da keine 25 Zeilen a 21 Pixel rein.
2.) Fontforge generiert den .otb-Font nicht korrekt

. Da werden sämtliche Zeichen um 1 Pixel nach unten verschoben.
Ich habe bisher noch nicht herausgefunden, woran das liegt.

(Das war früher nicht so )
Vielleicht liest ja hier ein FontForge-Experte mit, der da weiter weiss...

dbluelle

hier mit enigma vom 06.09. keine probleme auf 16:9.
Regloh

In Neutrino sieht das echt bescheiden aus.
cu
Jens

Beitrag von **rasc** » Donnerstag 8. September 2005, 23:05

dbluelle hat geschrieben:Da gibt's wohl zwei Ursachen:

1.) Die Default-Einstellungen für die Tuxtxt-Position in Enigma sind zu klein, d.h. wenn man die nicht anpasst, passen da keine 25 Zeilen a 21 Pixel rein.

Also tuxtxt sieht schon seit einiger Zeit bei 16:9 angepasster Groesse recht bescheiden aus (sprich: unbenutzbar). Ich weiss aber nicht wann das auftrat - dazu benutze ich Videotext bedingt durch EPG zu wenig.

Wann werden die Fonts denn berechnet? (Oder anders gefragt: was passiert denn wenn ich die Bildgroesse von tuxtxt an mein TV anpasse...?)

Beitrag von **rasc** » Freitag 9. September 2005, 21:41

so sieht das bei einem für 16:9-TV eingestellten tuxtxt aus (direkt aus dem cdk, ohne Änderung).

D.h., die max. Eck-Koordinaten sind so eingestellt, das Videotext auch im Zoom-Modus des TV (4:3 -> 16:irgendwas) noch von der Höhe voll darstellbar ist - vor den Fontbasteleien, war das kein Problem.

Bild

Zum Selbertesten:
Bildbereicheinstellung (Neutrino):

sx=37 sy=83
ex=668 ey=507

Das Problem ist, das Tuxtxt sich genau an die Positionsangaben hält.
Das heisst bei deinen Einstellungen hat Tuxtxt nur 507 - 83 = 424 Pixel vertikal zur Verfügung. Der Font braucht aber mindestens 25 Zeilen x 21 Pixel = 525 Pixel, um korrekt dargestellt zu werden.
Ich denke, ich werde das noch ändern, sodass immer mindestens 525 Pixel verwendet werden.
(Ich verstehe allerdings nicht, warum ihr da so kleine Werte habt, es kann doch nicht sein, dass bei euch nur so wenig vom Bild sichtbar ist

)

Übrigens habe ich auch das Problem mit FontForge gelöst, da gibts dann demnächst auch 'nen überarbeiteten Font, der das ganze etwas besser machen müsste...

dbluelle

Beitrag von **Regloh** » Samstag 10. September 2005, 12:07

in enigma wird m.e. die größe für tuxtxt extra vorgegeben. dank der skins werden die positionen der menüeinblendungen extra definiert. in neutrino ist die darstellung von tuxtxt in abhängigkeit der menüs gelöst. daher habe ich mit enigma keine probleme auf 16:9 und auch keine schwarzen balken oben/unten. bei neutrino kann ich das sehr wohl nachvollziehen.
Regloh

Beitrag von **rasc** » Samstag 10. September 2005, 13:37

dbluelle hat geschrieben:Das Problem ist, das Tuxtxt sich genau an die Positionsangaben hält.

Aehm, nett... das soll es ja auch!

dbluelle hat geschrieben: Das heisst bei deinen Einstellungen hat Tuxtxt nur 507 - 83 = 424 Pixel vertikal zur Verfügung. Der Font braucht aber mindestens 25 Zeilen x 21 Pixel = 525 Pixel, um korrekt dargestellt zu werden.
Ich denke, ich werde das noch ändern, sodass immer mindestens 525 Pixel verwendet werden.

... das löst das Problem ja nicht wirklich, oder?
Das ist dann wie bei Fotos wo Kopf und Fuesse abgschnitten sind.

Ich meine mich persönlich stört es nicht wirklich, da ich den VTXT vom Fernseher dann einfach nehme.

Die verwendeten Koordinaten markieren übrigens den max. mögl. darstellbaren Bereich bei 16:9-TVs im Zoom-Modus (sprich 4:3 auf 16:9 aufblasen).

(Ich verstehe allerdings nicht, warum ihr da so kleine Werte habt, es kann doch nicht sein, dass bei euch nur so wenig vom Bild sichtbar ist )

Du hast kein 16:9 TV, oder?

Mach dir nichts draus. Die Skalierung der Menues auf die max. darstellbare Größe kam in Neutrino auch erst rein, als ich einen 16:9 TV hatte...

Frage:
Warum skalieren die Fonts nicht auf Groesse und Breite?
Schliesslich werden bei VTXT doch keine Proportionalfonts verwendet?

rasc hat geschrieben:Ich meine mich persönlich stört es nicht wirklich, da ich den VTXT vom Fernseher dann einfach nehme.

Da hast du es wirklich gut das deine Box den Fernsehtext nicht blockiert.

Ps: Den konnte ich mir einfach nicht verkneifen.

rasc hat geschrieben: Du hast kein 16:9 TV, oder?
Mach dir nichts draus. Die Skalierung der Menues auf die max. darstellbare Größe kam in Neutrino auch erst rein, als ich einen 16:9 TV hatte...

Doch, habe ich (sonst hätte ich den 16:9-Modus auch nicht in TuxCom und den VNC-Viewer eingebaut

)
Allerdings nutze ich da bei Tuxtxt eben auch den 16:9-Modus, und da wird dann nichts oben und unten abgeschnitten. Folglich passt das bei mir auf der Dreambox mit Enigma wunderbar...

rasc hat geschrieben: Frage:
Warum skalieren die Fonts nicht auf Groesse und Breite?
Schliesslich werden bei VTXT doch keine Proportionalfonts verwendet?

Standardmässig wird von Tuxtxt der fixed-Font verwendet (tuxtxt.otb), der feste Breiten und Höhen hat. Das ist sozusagen eine Weiterentwicklung auf Basis der alten .fon-Dateien von LazyT.
Wenn du in der tuxtxt2.conf den Eintrag "UseTTF 0" durch "UseTTF 1" ersetzt, wird der TrueType-Font verwendet (tuxtxt.ttf). Der wird genau auf Beite und Höhe skaliert. Ob der allerdings bei einer so geringen Höhe noch lesbar ist ...

dbluelle

Beitrag von **rasc** » Samstag 10. September 2005, 15:06

dbluelle hat geschrieben: Wenn du in der tuxtxt2.conf den Eintrag "UseTTF 0" durch "UseTTF 1" ersetzt, wird der TrueType-Font verwendet (tuxtxt.ttf). Der wird genau auf Beite und Höhe skaliert. Ob der allerdings bei einer so geringen Höhe noch lesbar ist ...

... mit UseTTF 1 sieht das doch wieder ganz brauchbar aus...
... und nein, die Fonts sind nicht zu klein und sehr gut lesbar.

Das sollte man noch ins tuxtxt setup-Menue mit einbauen...