[osdteletext] 2.0.0 released

  • Major Features:

    • add "Text Font" option to OSD config
    • add support for "G0 character with diacritical mark" by implementation related support of X/26
    • introduce new page cache storage format VTXV5 to cover X/25-28 and M/29 extension

    Cosmetics / Minor Features

    • clear teletext page on channel switch
    • display PageId always in case OSD was restarted (useful e.g. for subtitle pages)
    • selected background color kept on OSD restart
    • cached pages of non-live channel: display page IDs in different color and a 'c' mark, do not trigger useless 'Pause'
    • channel switch: display message, on empty OK return to live channel
    • draw bi-colored message frame, increase frame on high resolution, change font on high resolution
    • stop updating clock and blink in case of page update was stopped
    • display sender name in case page is not found
    • blacklist Italic and Oblique fonts from being selectable (which causes anyhow issues on displaying because of kerning)

    Fixes:

    • additional fixes found during regression tests related to translations and others
    • many fixes found during regression tests related to MessageBox, too often CleanDisplay calls, ...
    • improve font scaling
    • fix not working selection of cache-system 'legacy'


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

  • Vielen Dank! Super Arbeit


    :respekt

    MP-Logos (Kanallogos für VDR) - Picons2VDR (Kanallogos für VDR) - MV_Backup (Backup mit RSync) - Skin FlatPlus (Fork)


    "75 GB sind genug für jeden." [Dt. Telekom], 2013

    ___

    Gen2VDR V7; VDR 2.5.1; Gehäuse: Antec Fusion V2 Black & iMon LCD (15c2:ffdc); Atric IR-Einschalter Rev. 4; Board: Intel DH77EB, Core i5-3550, NVidia GTX 750 Ti, 4 GB RAM; DVB: 1x Digital Devices CineS2 Quad V6.5 [VDR-User #1540]

  • Vielen Dank! Super Arbeit

    Danke für's Lob....jetzt muß ich nur das Meisterstück schaffen:


    https://github.com/vdr-project…gin-osdteletext/issues/11

  • Ich hatte zuletzt vor etwa 2-3 Wochen zuletzt auf den damaligen git-Stand aktualisiert und heute nun die 2.0.0 installiert. Was ich nun aber bemerke ist, dass sich die Umschaltzeit deutlich erhöht hat, mindestens um 1 Sekunde. Ohne osdteletext ist die Umschaltzeit normal.

    Testweise habe ich die Änderung aus dem commit "clear teletext page on channel switch" entfernt, aber das hat nichts geändert.



    so sieht es ohne osdteletext aus:



    uns so zum Vergleich die Version 1.1.1


    ACT-620, Asrock B75 Pro3-M, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

  • Ich hatte zuletzt vor etwa 2-3 Wochen zuletzt auf den damaligen git-Stand aktualisiert und heute nun die 2.0.0 installiert. Was ich nun aber bemerke ist, dass sich die Umschaltzeit deutlich erhöht hat, mindestens um 1 Sekunde. Ohne osdteletext ist die Umschaltzeit normal.

    Testweise habe ich die Änderung aus dem commit "clear teletext page on channel switch" entfernt, aber das hat nichts geändert

    in menu.c sind 3x sleep 1 sekunde eingebaut, um die Message-Fenster nicht gleich wieder verschwinden zu lassen, ggf. ist das die Bremse und ich muß mir was schlaueres einfallen lassen...z.B. einen temporären OSD-Update-Stop für einstellbare Sekunden...


    Lösche mal den "kritischen" in Funktion "void TeletextBrowser::ChannelSwitched(int ChannelNumber, const bool live)" an der markierten Stelle:

    Code
    1. Display::DrawMessage(str, ttcBlue);
    2. sleep(1); <--- !!!!
  • Lösche mal den "kritischen" in Funktion "void TeletextBrowser::ChannelSwitched(int ChannelNumber, const bool live)" an der markierten Stelle:

    Code
    1. Display::DrawMessage(str, ttcBlue);
    2. sleep(1); <--- !!!!

    Das hilft bei mir... die Umschaltzeiten sind damit wieder wesentlich besser...

  • Hilft auch bei mir. Kann sein, dass es damit schon wieder exakt auf dem vorherigen Niveau ist - muss ich nochmal weiter beobachten.

    Was für eine Message soll denn da bei einem Kanalwechsel angezeigt werden?? Und sollte das nicht besser nur dann erfolgen, wenn das Plugin auch aktiv ist (also nicht nur im Hintergrund läuft)?

    ACT-620, Asrock B75 Pro3-M, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

  • Hilft auch bei mir. Kann sein, dass es damit schon wieder exakt auf dem vorherigen Niveau ist - muss ich nochmal weiter beobachten.

    Was für eine Message soll denn da bei einem Kanalwechsel angezeigt werden?? Und sollte das nicht besser nur dann erfolgen, wenn das Plugin auch aktiv ist (also nicht nur im Hintergrund läuft)?

    Sorry...hab die Meldung an der falschen Position eingebaut :-( -> verschoben, jetzt wird's nur angezeigt, wenn OSD aktiv ist.


    Hier zum Testen, Feedback wäre super

    https://github.com/pbiering/vd…ext/tree/2.0.1-regression


    Fixt auch:

    https://github.com/vdr-project…gin-osdteletext/issues/43

  • Hier ist das Umschaltverhalten wieder ok mit der Version 2.0.1! :thumbup:

  • in den Einstellungen sind die Tastenbezeichnungen in Englisch.

    danke für's Testen, umgestellt, im worst case wird nun versucht, st_modes doppelt zu übersetzen....Branch aktualisiert:

    https://github.com/pbiering/vd…ext/tree/2.0.1-regression

  • Hi,

    mir gefällt es daß immer noch und wieder weiterentwickelt wird.

    Eines ist mir aufgefallen:

    Im Vergleich des osdteletext 0.9.8 und 2.0.0 fällt mir auf (und vor allem meiner Frau...) daß die Reaktion auf Fernbedienungs-Eingaben fühlbar träge geworden ist. Das nervt vor allem beim Eingeben einer direkten Seiten-Nummer.

    Beim Vergleichstest stelle ich fest daß das irgendwo zwischen 0.9.8 und 1.1.1 reingekommen ist.

    Hast Du, Peter, direkt eine Idee was der Grund ist oder soll ich mal ein "git bisect" machen?


    Grüsse

    Martin (github madmartin)

  • Hmm, kann mich nicht erinnern, wo ich bei der Eingabe der Seitennummern etwas geändert habe...hier ist alles flüssig...bitte mal suchen gehen, danke!

  • Release 2.0.1 fertig, danke für's Testen:


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

  • Und hier was für experimentierfreudige, die mehr als einen Tuner haben, der Kanalwechsel schaltet den Teletext-Receiver auf einen unterbeschäftigten Tuner und empfängt dann hier die Seiten:


    https://github.com/pbiering/vd…t/tree/2.1.0-second-tuner


    wird noch etliche Regression & Code-Cleanup Runden brauchen....aber als erster Wurf tut's...

  • danke für's Testen, umgestellt, im worst case wird nun versucht, st_modes doppelt zu übersetzen....Branch aktualisiert:

    https://github.com/pbiering/vd…ext/tree/2.0.1-regression

    Das klappt hier nun bei mir auch! (Ist mir zuvor gar nicht aufgefallen...)

  • Das klappt hier nun bei mir auch! (Ist mir zuvor gar nicht aufgefallen...)

    hmm, bei einem klappt die Übersetzung nun, beim anderen nicht...komisch.


    Hintergrund für "potentielle" Doppelübersetzung....im Original-Code wird st_modes (komplettes Array) zugewiesen an


    cTeletextSetupPage::modes = st_modes;


    welches dann später komplett übergeben wird an:


    new cMenuEditStraItem(actionKeyNames[i].userName, (int*)&temp.mapKeyToAction[i], LastAction+1, modes) );


    da kann kein "tr(...)" mehr angewandt werden.


    Man müßte also entweder im laufenden Betrieb das "modes" Array neu aufbauen mit "tr(st_modes[i])" oder es gibt eine schlauere Lösung oder es geht mit 2.0.1 jetzt final doch...

  • hmm, bei einem klappt die Übersetzung nun, beim anderen nicht...komisch.

    Wie schon bei den Beschriftungen der Knoepfe: tr() auf statischen Arrays funktioniert nur zufaellig abhaengig von der Initialisierungesreihenfolge (je nach Compiler und Compilerversion) und ist keine Loesung.

    Man müßte also entweder im laufenden Betrieb das "modes" Array neu aufbauen mit "tr(st_modes[i])"

    Das waere moeglich.

    oder es gibt eine schlauere Lösung

    Vielleicht. Wie machen es denn andere Nutzer von cMenuEditStraItem?

    oder es geht mit 2.0.1 jetzt final doch...

    Nein.


    Gruss,

    S:oren