(gelöst) vdr-plugin-osdteletxt-0.9.7

Prima! Was ist Dein Ausgabedevice, welches Ausgabeplugin verwendest Du und ist es vdr 2.2 oder 2.3?

softhddevice mit vdr-2.3.9. Ich werde aber auch noch mit dem RPi testen.

Als Anmerkung hätte ich noch, das die default OSD-Größe ihmo 1350x1080 sein sollte. Kommt ja von 720x576 also Factor 1.25

Ich stelle mir die Breite auch immer manuell so ein, dass es schmaler wird und ein 4:3-Format hat. Ich finde, es ist so einfach besser lesbar. Aber da gehen die Ansichten vielleicht auseinander. Bei vielen 16:9-TVs ist der eingebaute Teletext auch bildschirmfüllend breit. Aber da konnte ich mich nie dran gewöhnen.

Hab es jetzt auch auf den RPi's mit Raspbian und vdr-2.3.9 laufen und für gut befunden

Hallo,

ich moechte es mal probieren und habe eine TT 6400.

Es läuft ein vdr-2.3.8 und die 0.97-er Version des Plugins.

Hier sieht man die Werte der setup.conf

dvbhddevice.HighLevelOsd = 0
dvbhddevice.OsdSize = 0
dvbhddevice.TrueColorOsd = 0
osdteletext.Action_kBlue = 0
osdteletext.Action_kFastFwd = 0
osdteletext.Action_kFastRew = 0
osdteletext.Action_kGreen = 0
osdteletext.Action_kPlay = 0
osdteletext.Action_kRed = 2
osdteletext.Action_kStop = 0
osdteletext.Action_kYellow = 1
osdteletext.autoUpdatePage = 1
osdteletext.configuredClrBackground = 127
osdteletext.HideMainMenu = 0
osdteletext.OSDHAlign = 50
osdteletext.OSDheight = 720
osdteletext.OSDVAlign = 50
osdteletext.OSDwidth = 1280
osdteletext.showClock = 1
osdteletext.txtFontName = teletext2:Medium
osdteletext.txtG0Block = 0
osdteletext.txtG2Block = 0

Mein Problem es kommt keine Teletext-anzeige wenn über Menü --> Videotext ausgewählt wird.

Weiss jamend Rat?

by

highrgb:

das Problem hatte ich auch. Leider unterstützt die aktuelle Version des Plugins nur noch True-Color OSD, warum auch immer der alte Code komplett entfernt wurde. Wird so auch auf dem dvbsddevice nicht mehr laufen.

Wenn Du TrueColor OSD aktivierst wirst Du wieder Teletext sehen.

Mit dem Patch im Anhang wird die Farbtiefe auf 4 bit pro Pixel gestellt. Würde ich eher als schnellen Hack bezeichnen, als als ordentlichen Patch, aber es funktioniert dann auch auf der 6400 im High Level OSD. Und da Teletext ja eh nur 8 Farben hat, sieht man auch keinen Unterschied.

Die Performance ist aber auf der 6400 aktuell nicht so gut, da bei einem Update 1000 kleine Bitmaps gemalt werden, was relativ viel Overhead bedeutet. Ich denke ich schaue mir demnächst mal an, was sich da noch optimieren lässt. Eine Idee wäre immer eine Zeile auf einmal zu zeichnen, dann wären es nur noch 25 DrawBitmap Aufrufe.

Zitat von powarman

Mit dem Patch im Anhang wird die Farbtiefe auf 4 bit pro Pixel gestellt. Würde ich eher als schnellen Hack bezeichnen, als als ordentlichen Patch, aber es funktioniert dann auch auf der 6400 im High Level OSD. Und da Teletext ja eh nur 8 Farben hat, sieht man auch keinen Unterschied.

Die Performance ist aber auf der 6400 aktuell nicht so gut, da bei einem Update 1000 kleine Bitmaps gemalt werden, was relativ viel Overhead bedeutet. Ich denke ich schaue mir demnächst mal an, was sich da noch optimieren lässt. Eine Idee wäre immer eine Zeile auf einmal zu zeichnen, dann wären es nur noch 25 DrawBitmap Aufrufe.

Danke für den Patch, Es funktioniert!!!;-)

Unter VDR 2.4.0 und die 0.97-er OSDTeletext-Plugins + Patch 4bpp.

Performanceeinbussen kann ich keine feststellen

Hmm, dieser Patch macht aus einem farbenfrohen Teletext auf softhddevice (skindesigner und LCARS) eine "graue Maus mit einer Extra-Farbe" - man sollte das schaltbar machen aber nicht hartcodieren...

Falls den Thread hier noch einer liest: hab's mal schaltbar gemacht....

https://github.com/vdr-project…plugin-osdteletext/pull/1

I think it's better to send a request to the https://github.com/rofafor/vdr-plugin-osdteletext.

Genau. Probiere das mal. Dann wüsste man auch ob das Plugin noch aktiv gepflegt ist und könnte auf vdr-projects archivieren.

Hmm:

https://github.com/ua0lnj/vdr-plugin-osdteletext/tree/master -> last change 2018

https://github.com/rofafor/vdr…sdteletext/tree/vdr-2.3.x -> last change 2018

https://github.com/vdr-projects/vdr-plugin-osdteletext -> last change 2018

=> alle 3 sind damit aktuell "stale"

Fedora RPM nutzt aktuell noch https://projects.vdr-developer…vdr-osdteletext-0.9.7.tgz als Basis

+ 2 patches on-top, einer davon der 4bpp "hartcodiert"...

Da ein Community-Projekt starkes Interesse haben sollte, daß die Forks wieder irgendwie in den Master zurück "contributen" sollten, würde ich das auf vdr-projects aktiv lassen und den Maintainer vom "best-fork-of-the-month" darauf Admin-Rechte geben, damit er seinen Fork selbst wieder zurückintegrieren kann.

Denkt denn keiner daran, daß dem "best-fork-of-the-month" mal irgendwas passieren kann und der möglicherweise nicht mehr zugreifbar ist? Im besten Fall sind dann noch irgendwo tar.gz verfügbar, die zurückgespielt werden müßten unter Verlust vom git-log...

BTW: für Packager (Fedora/Ubuntu) ist die aktuelle Situation auch nicht gut, die müssen auch immer wieder mal umstellen auf einen neuen "best-fork-of-the-month" und ggf. darauf noch Patches anwenden....und wenn sich der ehemals benutzte Fork dann wieder als stale erweist..."weiterhüpfen".

Jetzt, wo alles auf Github liegt unter "vdr-projects", sollte es doch wirklich einfach sein, das alles wieder einzusammeln...wenn denn die Maintainer ihren Fork auch wieder zurückspielen wollen...bzw. falls es die Community so sieht: notfalls den "best-fork-of-the-month" selbst zurück in den Master mergen....

Kannst du denjenigen, die das Plugin pflegen, aber nicht vorschreiben. Deshalb ja die Linkliste. Wenn es auf deinen Pull-Request keine Antwort gibt, dann vdr-projects.

Kannst ja beim Pull-Request vorschlagen das auf vdr-projects zu pflegen.

Meine Gedanken zur Problematik, soll nicht heissen, dass dass ich speziell pbrb anzweifeln oder korrigieren will, nur weil die Zitate aus seinem Beitrag stammen.

Zitat von pbrb

alle 3 sind damit aktuell "stale"

Wieso? Das Plugin funktioniert einwandfrei (fuer mich, vermutlich auch andere), insbesondere in der rofafor-Version. Warum sollte es da staendig neue Commits geben?

Zitat von pbrb

einer davon der 4bpp "hartcodiert"

Das war vom Patch-Autor (powarman) als Hack fuer ein spezifisches Problem eines Users entwickelt worden. Wundert mich also nicht, dass das nicht in einem offiziellen Repo landet.

Zitat von pbrb

Denkt denn keiner daran, daß dem "best-fork-of-the-month" mal irgendwas passieren kann und der möglicherweise nicht mehr zugreifbar ist?

Ist alles GPL, man darf auch pullen ohne Pull-Request...

Zitat von pbrb

Da ein Community-Projekt starkes Interesse haben sollte, daß die Forks wieder irgendwie in den Master zurück "contributen" sollten,

Das scheint mir das Hauptproblem zu sein: es gibt keine Einigkeit, was der Master ist. Waere in der Tat schoen, wenn es eine zentrale Anlaufstelle für die aktuellen Plugins gaebe. Nach meinem Verstaendnis war vdr-developer dafuer gedacht, warum braucht man zusaetzlich github/gitlab/wasauchimmer? Das als offene Frage, wahrscheinlich gibt es gute Gruende. Und ja, sowas zu pflegen ist viel Arbeit, die selten angemessen gedankt wird.

Gruss,

S:oren

Zitat von S:oren

Das scheint mir das Hauptproblem zu sein: es gibt keine Einigkeit, was der Master ist. Waere in der Tat schoen, wenn es eine zentrale Anlaufstelle für die aktuellen Plugins gaebe. Nach meinem Verstaendnis war vdr-developer dafuer gedacht, warum braucht man zusaetzlich github/gitlab/wasauchimmer? Das als offene Frage, wahrscheinlich gibt es gute Gruende. Und ja, sowas zu pflegen ist viel Arbeit, die selten angemessen gedankt wird.

Bei vdr-developer gibt es zwei gravierende Hauptprobleme:

- One-man show. Nur einer verantwortlich und wenn der keinen Bock mehr hat ist halt von heute auf morgen alles weg.

- Nach heutigem "modernen" Stand einfach unwahrscheinlich mies zu bedienen

Soll heißen: Ich kann jeden voll und ganz verstehen der sich sagt: Das tue ich mir nicht an. Ich entwickle X andere Open Source Projekte. Warum also nicht mein Plugin einfach mit auf GitHub werfen. Da hab ich auch alles andere und so sind alle meine privaten Projekte an ein und demselben Ort.

Wird zwar jetzt endgültig hart Off Topic hier, aber ich sehe die vdr-projects Organisation erstmal als "Auffanglager" für Plugins die tatsächlich keiner mehr pflegt. Dann lieber erstmal in die vdr-projects Organisation damit, damit unabhängige ein Ziel haben wo man Pull-Requests hinrichten kann. Das soll nicht heißen das die dann wieder raus müssen wenn sich wer "berufen fühlt". Wer will bekommt Maintainer-Rechte (Community-Maintained mit gezielt gewählten Community-Mitgliedern) oder Admin-Rechte (damit kann derjenige, der die hat, auch sein Team komplett frei festlegen).

Wenn der "Hack" von einem Distributor hartcodiert reingenommen wird, dann ist das tatsächlich ein Problem, weil es für alle, die das Problem, welches damit gefixt werden soll, nicht haben, das osdteletext-Plugin deutlich "verschlechtert". Deshalb erstmal sehr gute Idee das schaltbar zu machen. Das verbessert den bisherigen Stand deutlich. Trotzdem wäre es in jedem Fall besser wenn sowas erstmal an den wahrscheinlichsten aktuellen Maintainer geht (in dem Fall https://github.com/rofafor/vdr…sdteletext/tree/vdr-2.3.x). Gerne auch mit Hinweis auf die vdr-projects-Organisation. Sollte er aber den Pull-Request annehmen, dann wäre für mich der aktuelle Stand klar (wird aktuell gepflegt) und bei vdr-projects wird die Verlinkung entsprechend angepasst und das Repo archiviert.

Das mit den Mirrors bringt nämlich garnichts. Die Distributoren müssen wissen wo ein Plugin tatsächlich aktiv gepflegt wird und nicht wo es mit Zeitversatz als Mirror erscheint. Auch potentielle Mithelfer müssen wissen wo man Pull-Requests sinnvoll hinrichten muss. An einen Mirror gerichtete Pull-Requests sind verschwendete Liebesmüh. Was sollte man damit anfangen? Manuell an die richtige Stelle neu erstellen? Auf den Mirror anwenden? Wie kommt das dann sinnvoll ins "Hauptprojekt" zurück und wer soll das alles leisten?

Hoffe das war soweit verständlich...

Zitat von M-Reimer

Hoffe das war soweit verständlich...

Ja, ist es. Ich stimme in vielen Aussagen ueberein. Fuer mich, mit etwas Abstand draufgeschaut, loest es in dieser Form aber wenig Probleme. Das mag fuer einen Distributor etwas anders sein, aber eigentlich sind die Interessen von "einfachen" Usern doch gar nicht so verschieden. (Dafuer die Ansichten zum "besten" Vorgehen sicher bei jedem individuell unterschiedlich. Und eine objektiv beste Vorgehensweise schwer zu finden.)

Zitat von M-Reimer

Trotzdem wäre es in jedem Fall besser wenn sowas erstmal an den wahrscheinlichsten aktuellen Maintainer geht (in dem Fall https://github.com/rofafor/vdr…sdteletext/tree/vdr-2.3.x).

Und das ist genau nicht so einfach. Ich habe gerade vor wenigen Tagen nach aktuellen Versionen dieses Plugins (osdteletext) gesucht (Umstieg von vdr-2.2.0 auf vdr-2.5.1). Die vdr-developer-Version ist 0.9.7, hat aber das Problem mit den Streifen in der ASCII-Art, die rofafor-Version ist 0.9.6, hat aber den Patch, der das behebt. Fuer mich war die aktuellere Version erstmal 0.9.7, und es hat einiges Suchen hier erfordert, den Status-quo zu erkennen.

Das Problem an dieser Stelle ist also nicht, dass es zu wenige Maintainer gibt, sondern zu viele, und damit inkonsistente Versionen in verschiedenen Repositories. Idealerweise einigen sich die vorhandenen Maintainer auf ein Haupt-/Upstream-Repo, aber das kann man nun mal nicht erzwingen. Der Ansatz von vdr-developer war, dort die neuesten Versionen zu sammeln, auch neue Versionsnummern zu vergeben, damit eine aktuelle Pluginsammlung zu haben, wo man auch sieht, dass sie aktuell ist. Diesen Ansatz ("Meta-Maintainer," wo es keinen richtigen Maintainer gibt) halte ich immer noch fuer sehr gut und sehr hilfreich (fuer Nutzer und Distributoren), wenn er konsequent umgesetzt wird. Somit denke ich auch, dass man Tobi nicht gerecht wird mit "mies zu bedienender one-man-show".

Alles Weitere wuerde hier in der Tat zu sehr off-topic.

Gruss,

S:oren

Zitat von S:oren

Und das ist genau nicht so einfach. Ich habe gerade vor wenigen Tagen nach aktuellen Versionen dieses Plugins (osdteletext) gesucht (Umstieg von vdr-2.2.0 auf vdr-2.5.1). Die vdr-developer-Version ist 0.9.7, hat aber das Problem mit den Streifen in der ASCII-Art, die rofafor-Version ist 0.9.6, hat aber den Patch, der das behebt. Fuer mich war die aktuellere Version erstmal 0.9.7, und es hat einiges Suchen hier erfordert, den Status-quo zu erkennen.

Stimmt. Solange aber noch die Wahrscheinlichkeit besteht das jemand noch aktiv weiterentwickeln will ist auch schwer das an einer Stelle wieder zusammenzuführen. Ich hab einfach mal nachgefragt:

https://github.com/rofafor/vdr-plugin-osdteletext/issues/5

Zitat von S:oren

Diesen Ansatz ("Meta-Maintainer," wo es keinen richtigen Maintainer gibt) halte ich immer noch fuer sehr gut und sehr hilfreich

Genau das bin ich ja gerade dabei etwas voranzutreiben. Allerdings bin ich zudem der Meinung das man es den "Mitwirkenden" so einfach wie möglich machen sollte.

Ja, man kann auch ohne Pull-Requests von irgendwo her pullen. Man kann auch ganz altmodisch Patches via Mail hin und herschicken. Die Frage ist aber: Will man mit so einem Mehraufwand einen potentiellen Helfer direkt abschrecken?

Das ist aber alles nur meine Meinung. Jeder darf und soll nutzen was er möchte und letztlich wird es auf https://vdr-projects.github.io/ auch Links auf projects.vdr-developer.org geben wenn die entsprechenden Projekte nicht schon woanders hin abgewandert sind.

Mirrors sind auf jeden Fall immer falsch. Egal wo man sie macht. Was ein Distributor und auch Nutzer wissen muss ist wo das Projekt gepflegt wird. Deshalb werde ich in der vdr-projects Organisation auch jedes bestehende Repository archivieren oder löschen wenn der zuständige Entwickler nicht vorhat dort auch aktiv einzuchecken.

Zitat von M-Reimer

Solange aber noch die Wahrscheinlichkeit besteht das jemand noch aktiv weiterentwickeln will ist auch schwer das an einer Stelle wieder zusammenzuführen.

Ich sehe nur 2 sinnvolle Moeglichkeiten. Entweder einigen sich die vorhandenen Maintainer und uebernehmen gegenseitig die commits (auf Anfrage des jeweils anderen Maintainers oder einer anderen Person, genau wie bei Deiner Anfrage oben), sehr sinnvoll. Oder ein "Metamaintainer", wie auch immer man das nennen will, uebernimmt immer die Patches aller anderen, auch wieder auf Request von wem auch immer, und bleibt dabei immer am Ball, auch noch brauchbar.

Problematisch wird es dann, wenn man sich nicht ueber die Qualitaet oder Sinnhaftigkeit von einzelnen Patches einigen kann, dann auch nicht bereit ist, verschiedene Branches zu pflegen, und sich im schlimmsten Fall noch einen "Krieg der Versionsnummern" liefert. Da helfen eigentlich nur klare Absprachen und Einigkeit ueber die jeweiligen Ziele der eigenen Entwicklungstätigkeit. Nicht immer wird das klappen, nicht jeder will den zusaetzlichen Aufwand investieren. Aber die Hoffnung stirbt vielleicht zuletzt. Selten streiten sich mehrere Maintainer ueber die Vorherrschaft, meistens werden doch neue Repos nur aufgemacht, wenn der bisherige Maintainer nicht (schnell genug) reagiert. Dann wird normalerweise das aktuellere Repo die neueren Versionsnummern haben, hier bei osdteletext hat es leider nicht funktioniert. Aber auch da will ich niemandem boesen Willen unterstellen. Vielleicht aergern sich viele Leute umsonst, haben einfach nur noch nicht nach einem Update gefragt. Hast Du ja gerade m.E. richtig gemacht. Ich war auch zu faul dazu.

Zitat von M-Reimer

Allerdings bin ich zudem der Meinung das man es den "Mitwirkenden" so einfach wie möglich machen sollte.

Klar, dem kann sicher jeder zustimmen. Aber dann wird es schon kompliziert. Ich persoenlich bevorzuge klar git-send-email, keine pull-requests auf irgendeiner Platform.

Ich habe lokale git-Repositories mit mehreren remotes, haette auch kein Problem, parallel Aenderungen in verschiedene oeffentliche Repos zu pushen. Da sehe ich auch kein Problem mit mehreren Mirrors, solange sie konsistent sind.

Ich moechte jedenfalls nicht von einem Workflow irgendeiner Platform abhaengig sein. Keiner weiss, wie lange diese Platform aktuell ist, keine komischen Aenderungen der Nutzungsbedingungen macht, irgendwann altbacken und "mies zu bedienen" ist. Auch ich sehe den Trend zu grafischen Benutzer-Oberflaechen, bleibe aber ein Freund der Kommandozeile. Mit git ist zum Glueck beides moeglich. Die verwendete Platform zur Veroeffentlichung sehe ich zweitrangig (ich veroeffentliche z.B. den saa716x-Treiber auf github, finde es als Platform aber nicht besonders toll).

Was letztendlich zaehlt ist der Code, und es muss sich jemand finden, Patches einzupflegen. Auch da ist m.E. nicht unbedingt das Problem, dass niemand die Aufgabe uebernehmen will, sondern eher die Unklarheit, wie man zu dem Job kommt und wie man ihn wieder los wird.

Gruss,

S:oren

Zitat von S:oren

Entweder einigen sich die vorhandenen Maintainer und uebernehmen gegenseitig die commits (auf Anfrage des jeweils anderen Maintainers oder einer anderen Person, genau wie bei Deiner Anfrage oben), sehr sinnvoll. Oder ein "Metamaintainer", wie auch immer man das nennen will, uebernimmt immer die Patches aller anderen, auch wieder auf Request von wem auch immer, und bleibt dabei immer am Ball, auch noch brauchbar.

Ich bin ja nichtmal Maintainer von osdteletext und werde ich auch nicht werden. Ich würde osdteletext, wenn sich kein "fester Maintainer" mehr findet, eben bei vdr-projects anlegen und ich hätte auch keinerlei Bedenken pbrb als "Maintainer" mit einzutragen. Vorher eben checken was man von wo noch zusammentragen muss. Vorarbeit mache ich gerne und das wird für die ganze Plugin-Liste auch noch etwas dauern. Ist ja Lockdown Aber wenn das mal zusammengetragen ist hoffe ich für jedes Projekt irgendwann wenigstens einen zu finden der das Ding noch nutzt und einen Pull-Request wenigstens ausprobieren kann bevor er ihn mergt.

Das wichtigste ist aber gut abzuwägen ob es nicht doch noch jemanden gibt, der ein Projekt gerne weiterführen will. Das ist immer am einfachsten jemand, der den Code schon kennt, führt das Projekt auch fort.

Zitat von S:oren

Da sehe ich auch kein Problem mit mehreren Mirrors, solange sie konsistent sind.

Ich auch nicht. Ich habe selber z.B. graplcd-base parallel bei mir auf GitHub und auf projects.vdr-developer.org. Aber ich pflege das Projekt aktuell auch. Wenn mir jemand auf GitHub einen Pull-Request schickt, dann geht der fast zeitgleich auch bei projects.vdr-developer.org rein. Das ist etwas anderes wenn jemand unbeteiligtes Mirrors anlegen will. Das muss dann zwangsläufig über einen Cron-Job laufen (also meist nicht sofort aktuell) und so ein "Mirror-Dienst" kann auch mal unbemerkt ausfallen.