Beiträge von pbrb

  • [osdteletext] 2.3.1 released

    Release 2.3.0 ist fertig, hat aktuell noch Status "Pre-Release":


    Falls nichts weiter auffällt die nächsten Tage, dann wird der zum Final-Release konvertiert.


    https://github.com/vdr-project…etext/releases/tag/v2.3.0


    Feature:

    • extend 24-Line-Toggle with a 3rd option to display hint lines for standard keys
    • add support for half bright standard colors and ETSI colors 16-31

    Bugfix

    • long option fix "key-levels", add-missing "osd-preset"
    • limit DrawMessage box to maximum box size

    General

    • code cosmetics


    In Planung ist noch, das "Kanalwechsel" eine Liste mit Sendernummern anzeigt (z.B. Top 20), damit man sich nicht soviel merken muß...


    Wer noch sinnvolle Ideen hat, was man denn in den neuen 2 optionalen Zusatzzeilen sonst noch so anzeigen könnte...bitte melden...wird ja Winter ;)

  • [reelbox] [eHD] Kernel Modul auf 64-bit portiert + reelbox-plugin funktionsfähig

    Zitat von M-Reimer

    Vielleicht ist pbrb da andere Meinung, aber die eHD ist schon immer etwas fummelig gewesen. Es gibt heute wirklich keinen Grund die noch in Betrieb zu nehmen. Bei einem "Mainboard das man einfach kaufen kann" ist heute in aller Regel eine Grafikkarte, die der eHD überlegen ist, auch einfach so direkt mit drauf. Also in der CPU die du da drauf setzen wirst.

    Also für einen neuen VDR würde ich auch keine eHD mehr nutzen. Hab meine alte ReelBox aktuell schlafen gelegt und die neue mit einem Intel ITX J3455 am laufen mit Softdevice usw, und würde nicht mehr zurück bauen. Paar Tipps findet man hier: https://github.com/pbiering/ReelBoxNG/wiki


    Ausgabe ist ein 75" Panasonic-TV, bei allem HD-Material super, und alte SD-Aufnahmen müßte ich mal prüfen, dachte, da entsprechend gute Einstellungen gefunden zu haben.


    Was inzwischen auch auffällt, daß die eHD beim Vor- & Rückspulen und Springen immer etwas klemmt (wer in den Code schaut, findet auch den "üblen" Workaround dazu...), mit SoftHDDevice geht das wunderbar...


    Nachteil vom eHD ist auch die Kernel-Modul-Abhängigkeit und daß mir bis heute leider nicht die Buildumgebung zugelaufen ist, um neue Images für eHD zu erzeugen, um da ggf. noch was zu fixen. Hier der letzte Stand an Binaries: https://github.com/pbiering/Re…tree/main/bin-reelvdr/eHD


    Und dann wäre noch das OSD-Problem, was wohl aus technischen Gründen niemals auf HD umbaubar ist...und wer einmal mit Skindesigner gearbeitet hat und die Full-HD-OSD-Auflösung genießt, der will ggf. nicht mehr zurück...


    Zusammenfassung:

    - man kann mit eHD immer noch einen VDR aufbauen, auch mit 64-bit-Kernel (hab ja das Kernel-Modul entsprechend gepatcht)

    - ob man es wirklich will...ich würde davon abraten, außer man hat gute Gründe und tiefe Kenntnisse...es lief unter Fedora 34 soweit stabil auch mit dem passenden justierten Plugin dazu...aber 100% sauber ist der Code immer noch nicht (ReelMultimedia hat da etliche Bugs hinterlassen...)


    BTW: aktuell habe ich kein lauffähiges eHD-Fedora34-Testsystem mehr...der ehemalige Testaufbau ist nun produktiv ohne eHD...die alte Reelbox muß ich erstmal umstellen auf neues OS.

  • VDR output plugins mit aktueller CPU -> HW-Decoder?

    ggf. hilft der Tipp: [gelöst]ansible-focal neue Hardware

  • [osdteletext] 2.2.1 released

    Zitat von rell

    Funktioniert, wenn man nach dem Einstellen mit der roten Taste die Hintergründe einmal durchschaltet.

    Danke für's Testen, in dieser Ecke hatte ich gar nichts gefixt. Der Fix war bzgl. der Änderungen im OSD-Konfig-Menü.


    Leider habe ich noch eine 2. Ecke übersehen, die schon bemerkt wurde...Änderung der Transparenz im Setup-Menü hatte keine Instant-Auswirkung....gefixt in 2.2.0.alpha.6: https://github.com/vdr-project…text/tree/milestone-2.2.0

  • [osdteletext] 2.2.1 released

    Zitat von lnj

    My reseach.

    Background transparency is read only at the moment of start, when changing a parameter in the menu, no reaction, the effect will be after restart.

    0 - background is transparent, 255 - background is dark, is that correct? As I understand it, the maximum value must correspond to the maximum transparency, otherwise it is the darkening of the background, but not background transparency.

    Thank you for reporting, confirmed, there must be a bug somewhere...will dig and find for sure next days. The value is remembered somehow, but not used on next OSD creation...one can replay using the OSD line 25 "config" mode for "BackTrans" -> proper value is displayed and can be changed (and will be remembered). But if OSD is closed and re-displayed, it starts from a different value...will keep you updated.


    And good, that the OpenGL issue was finally found!

  • [osdteletext] 2.2.1 released

    hmm, sollte die Überblendung aber nicht gesteuert werden von "bool Overlay" (default "false").


    Jetzt müßte mal eine Umfrage her, bei welchen Output-Plugins (SW und HW) das aktuell funktioniert wie erwartet und bei welchen es zu diesen Überlagerungseffekten kommt...eine der beiden Gruppen hätte dann eine fehlerhafte Implementierung...und das wohl schon länger...

  • [osdteletext] 2.2.1 released

    die Zeichen werden normalerweise einzeln geschrieben und nur das notwendigste, das war schon immer so:

    Code
             cBitmap charBm(w, h, 24);
         charBm.DrawRectangle(0, 0, w, h, bg);
	 charBm.DrawText(0, ttSetup.txtVoffset, buf, fg, 0, font);
         osd->DrawBitmap(vx, vy, charBm);

    das sich die Ausgabeplugins unterschiedlich verhalten, habe ich an den VDR-Maintainer gemeldet und warte auf die Rückmeldung, wie es eigentlich wirklich sein sollte.


    Bei mir läuft: vdr-softhddevice-1.1.0 (https://github.com/ua0lnj/vdr-plugin-softhddevice)

    und das kann übrigens auch "cuvid" (ich habe hier Intel VA-API im Einsatz).


    BTW: auch mit Versionen < 0.9.9 sollte das Verhalten genauso sein, weil an dem Dirty/DirtyAll Mechanismus habe ich nichts geändert meineswissen.

    Man könnte natürlich vor dem DrawBitmap noch ein DrawRectangle direkt auf dem OSD auslösen ("Putzjob") -> entweder als Workaround oder als Dauerzustand....je nach Ergebnis vom VDR-Maintainer...


    Mit dem Meldungsfenster hatte ich übrigens die vom OSDTeletext selbst gemeint, z.B. "Kanalwechsel" (cache oder live), nur mal aktivieren und mit OK wieder schließen, dann wird dieser Bereich neu gezeichnet, und dürfte dann keine "Schatten" mehr haben, der Rest schon.

  • [osdteletext] 2.2.1 released

    da ich das hier wohl nicht nachstellen kann, brauch ich noch eine Zusatzinfos:


    sind die Message-Boxen (z.B. Kanalwechsel), die so auftauchen können, vom Hintergrund OK und was passiert, wenn die wieder verschwinden...sind da auch noch alte Textfragmente sichtbar oder ist der Bereich, in dem die Message-Box gezeichnet wurde, nach dem Verschwinden anders wie der Rest?

  • [osdteletext] 2.2.1 released

    Zitat von rell

    Die original Software Implementierung von VDR?

    Wenn du mehrere ->DrawBitmap in ein OSD, sprich auf pixmap[0] machst, ohne das OSD dazwischen zu löschen, sollten sich die Draws mit dem jeweiligen Alpha entsprechend überlagern. Das Foto sieht danach aus.

    Ok, in dem Fall wäre die von mir benutzte "softhddevice"-Variante nicht gemäß "Standard".

    Zitat von rell

    Wird das OSD oder die pixmap irgendwann gelöscht, ausser, wenn osdteletext geschlossen wird?

    Das OSD wird neu erzeugt bei Größen/Positionsveränderungen und Hintergrundänderung...sonst nicht....ich werd die nächsten Tage mal einen Schalter einbauen, der der bei einem Dirty-Char (das OSD wird tw. nur selektiv aktualisiert) den entsprechenden Bereich löscht...vielleicht reicht das schon.


    War das eigentlich schon immer so oder ist das durch die Optimierungen aufgetreten...wenn ja, ab welcher Version (noch besser: git-commit...)

  • [osdteletext] 2.2.1 released

    Hmm, da scheinen sich aber die OSD-Implementierungen recht unterschiedlich zu verhalten...


    es funktioniert alles problemlos mit:

    sowohl Überschreiben der Zeichen als auch Online-Änderung der Hintergrund-Transparenz (z.B. via Config-Menu im 25-Zeilen-Modus)


    Die Zeichen werden alle mit "osd->DrawBitmap" gemalt, ich versteh nicht, wieso (wie beim Bild oben) der alte Text da überhaupt grau werden kann aber noch sichtbar bleibt...ist da irgendein Ausblend-Effekt aktiv, der nicht vollständig durchläuft - oder addiert sich da die Semi-Transparenz vom neuen Bitmap mit dem alten.


    ...dann wäre die Frage, welche OSD-Implementierung denn nach Vorgabe funktioniert bei Drübermalen von Bitmaps mit Alpha-Kanal.


    softhddevice putzt wohl, andere scheinen zu überlagern...


    BTW: beim Ändern der Transparenz (online) wird das ganze OSD neu aufgebaut (Display::SetMode), da sollten eigentlich keine Artefakte auftauchen...sofern das alte OSD auch von der Implementierung vollständig weggeputzt wird...

  • [osdteletext] 2.2.1 released

    Welche Version von osdteletext hast Du getestet? Ich erinnere mich dunkel, daß da schon mal jemand was gemeldet hat...find nur grad den Post nicht mehr...damals klang es danach, als das "softhdcuvid" ein Problem in der OSD-Implementierung hat.


    Kannst Du mal ein Foto posten (so rechtes oberes Viertel), wie das aussieht. Stell dazu aber vorher mal so 70% Größe ein und Rahmen von 10 Pixel.

  • [dynamite] Freigeben von ungenutzten Tunern

    Wirklich helfen kann ich aktuell wohl nicht, aber man könnte ggf. in mcli eine API (und ggf. ein svdr-Kommando) einbauen, was einzelne unbeschäftigte Tuner abmeldet. Allerdings müßte man dann auch verhindern, daß die danach gleich wieder gefunden werden automatisch. Klingt nach "list tuner" und dann "blacklist tuner <ID>" und wenn man's wieder braucht: "whitelist tuner <ID>" bzw. "whitelist tuner *" - ob's (so einfach) geht, müßte mal einer versuchen zu programmieren...ich kann mir dann den Patch mal anschauen und mergen, wenn ok.

  • [osdteletext] 2.1.1 (ex 2.1.0) released

    Version 2.1.1 wäre im "master" - wäre super, wenn's noch einer testen könnte:


    https://github.com/vdr-projects/vdr-plugin-osdteletext


    - release receiver on live channel switch earlier in sequence to use even on 2-tuner systems by default only one tuner

    - release device on non-live -> non-live channel switch earlier to avoid locking on 2-tuner systems


    und kosmetisch sind noch paar Meldungen unterdrückt, die eh gleich wieder überdeckt wurden von der nächsten.