Posts by pbrb

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

    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

    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!

    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...

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

    Code
    1. cBitmap charBm(w, h, 24);
    2. charBm.DrawRectangle(0, 0, w, h, bg);
    3. charBm.DrawText(0, ttSetup.txtVoffset, buf, fg, 0, font);
    4. 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.

    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?

    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".

    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...)

    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...

    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.

    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.

    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.

    Danke für die Logs. Das Verhalten ansich läßt sich nun erklären.


    • 2.0.x -> stoppt den Receiver relativ früh und gibt damit Tuner "DVB 0" wieder frei
    • 2.1.0 -> stoppt den Receiver später, damit ist Tuner "DVB 0" noch blockiert und VDR nimmt den verfügbaren, aber bei Dir nicht funktionierenden Tuner "DVB 1" für den neuen Kanal her

    Das wurde schon in [osdteletext] 2.1.0 released vermutet.


    Generell wäre es hilfreich, den 2. Empfänger entweder zu deaktivieren oder (viel besser) mit Signal zu versorgen.

    Code
    1. Usage: vdr [OPTIONS]
    2. -D NUM, --device=NUM use only the given DVB device (NUM = 0, 1, 2...)
    3. there may be several -D options (default: all DVB
    4. devices will be used); if -D- is given, no DVB
    5. devices will be used at all, independent of any
    6. other -D options

    Du dürftest nämlich in das gleiche Problem laufen, wenn Du parallel eine Aufnahme startest und dann zu einem Kanal auf einem anderen Transponder wechselst. VDR würde "DVB 0" für "recording" nehmen und "DVB 1" für neues Live-TV (oder andersrum)...aber einer davon kann ja nichts empfangen.


    Bisher ist das sonst wohl keinem aufgefallen, weil wer hat im VDR schon gerne Tuner registriert, die nicht aktiv nutzbar sind...das kann auch bei 2 parallelen Aufnahmen von Kanälen auf verschiedenen Transpondern unerwartete Effekte haben (keine Timer-Kollision wird angezeigt, aber 2. Aufnahme ist leer).


    Probier mal:


    https://github.com/pbiering/vd…teletext/tree/major-2.1.x


    da gebe ich den Receiver früher frei.


    BTW: bei Tests ist aufgefallen, daß in einem 2-Tuner-System das Zapping von einem "non-live" (aka "tuned") Channel zum nächsten "non-live" noch nicht funktioniert...muß ich noch nacharbeiten.