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

Nachdem ich ja schon auf Maintainer geworden bin von

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

kann ich mich gerne noch um

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

kümmern, und mindestens mal den aktualisierten 4bpp-Patch und den anderen von

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

nachfahren, einen Release 0.9.8 machen und dann schauen wir weiter, was sonst noch so in der "Welt" draußen gutes ist diesbezüglich.

Mindestens der Fedora-Paket-Maintainer könnte dann schon mal umstellen von projects.vdr-developer.org auf das Github-Repo.

Bzgl. Patches und Testen: ich werde bis auf weiteres wohl beide Plugins nutzen (+skindesigner und extrecmenung, die aktuell auf gitlab bei kamel5 gepflegt werden und schon manche Erweiterungen+Fixes in letzter Zeit abbekommen haben...) und softhddevice.

Releases sollten halbwegs "gut" getestet sein, im master können sich dann die akzeptierten PRs wiederfinden...

Quote from pbrb

kann ich mich gerne noch um

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

Dann schau dir mal meinen Patch von hier an:

softhddevice Bug in OpenGl OSD-Bug (mit osdteletext)

ich habe mir mal nun angeschaut: https://github.com/rofafor/vdr-pl…/tree/vdr-2.3.x

dessen Branch (der neuer ist als sein master) wurde gemergt nacht https://github.com/vdr-projects/vdr-plugin-osdteletext

=> https://github.com/vdr-projects/vdr-plugin-osdteletext ist somit eher der "Master"

Hab mal 2 weitere PRs erzeugt:

Streifen:

https://github.com/vdr-projects/v…teletext/pull/2

OpenGL-patch

https://github.com/vdr-projects/v…teletext/pull/3

In meinem Master ist aktuell alles zusammengemergt: https://github.com/pbiering/vdr-plugin-osdteletext

Wäre super, wenn noch jemand testen könnte...dann wär's zum nächsten Release 0.9.8 nicht mehr weit...

Was da doch nicht alles für Patches auftauchen...

Pull-Requests habe ich mal alle übernommen. Ich warte mal bis zum Wochenende und dann würde ich das Repo unterhalb "vdr-projects" erstmal in der Liste als offizielle "Quelle" markieren und "Community maintained" eintragen. Falls rofafor selber als "Hauptentwickler" weiterentwickeln will ist das ja schnell änderbar und er kann die inzwischen aufgelaufenen Patches direkt vom "Community-Repo" pullen.

Würde meinem Ziel "Null Patches bei Arch Linux" auf jedem Fall wieder einen Schritt weiter helfen. Nur noch gefühlt tausende Plugins die geprüft werden müssen...

Danke für die Annahme der PRs!

Btw. falls man auf einen guten Repo/Fork stoßt, dessen Maintainer den PR "vergessen" hat, notfalls kann sich der Master das auch selbst zurückholen vom Fork...zweites Repo einbinden, dann merge/checkout/cherry-pick.

Bei mir (auf einer S2-6400) crasht diese Version. (Noch) keine Ahnung, warum.

Gruss,

S:oren

Laß mal den OpenGL-Patch weg...die anderen sollten eigentlich keinen Unfug anstellen

Ja, wäre hilfreich. Wenn dem so ist fliegt der vor einem Release wieder raus.

Eventuell ist der auch längst überflüssig. Bei yaVDR wird auch viel Ausgabe mit OpenGL genutzt und die haben nur den "remove empty lines" patch drin.

Quote from S:oren

Bei mir (auf einer S2-6400) crasht diese Version. (Noch) keine Ahnung, warum.

Es war ein (bekanntes) Problem mit skinnopacity und epgsearch. osdteletext in Version d614fc0 funktioniert bei mir auf der S2-6400, Entschuldigung fuer den Fehlalarm.

Quote from M-Reimer

Würde meinem Ziel "Null Patches bei Arch Linux" auf jedem Fall wieder einen Schritt weiter helfen. Nur noch gefühlt tausende Plugins die geprüft werden müssen...

Vielen Dank fuer das Pflegen der neuen Repositories. Ich steige gerne auf diese um, wenn man dann keine weiteren Patches mehr braucht.

Gruss,

S:oren

Quote from S:oren

Es war ein (bekanntes) Problem mit skinnopacity und epgsearch.

Das ist zwar hier OT. Wenn es aber das Problem mit Timerkonflikten ist, kannst Du bitte mal den letzten Stand von skinnopacity auf projects.vdr-developer.org testen, ob der crash damit weg ist.

Grüße

kamel5

Quote from kamel5

Das ist zwar hier OT. Wenn es aber das Problem mit Timerkonflikten ist, kannst Du bitte mal den letzten Stand von skinnopacity auf projects.vdr-developer.org testen, ob der crash damit weg ist.

Grüße

kamel5

Ich werde das hier mal teste... Danke!

Gruß

Uwe

Quote from Uwe

Ich werde das hier mal teste... Danke!

Funktioniert, Danke für das finden dieses Bugs!

Sorry, das hier ... ist gestern bei mir untergegangen!

Quote from kamel5

Wenn es aber das Problem mit Timerkonflikten ist, kannst Du bitte mal den letzten Stand von skinnopacity auf projects.vdr-developer.org testen, ob der crash damit weg ist.

Scheint weg zu sein. Aber der Crash passierte nicht jedes Mal. Werde es weiter beobachten.

Danke,

S:oren

Bei mir klappt das opengl OSD nun mit den Untertiteln.

Hi,

I get "Warning: out of bounds write access to teletext page" on the console, but works.

CU

9000h

Dieses "out of bounds" kommt, wenn die Uhrzeitanzeige im Setup aktiv ist (die eigentlich völlig unnötig ist).

Der DrawText in DrawClock müsste bei Index 31 beginnen.

Die Uhrzeit wird doch ordentlich rechtsbündig dargestellt!?

Auch finde ich sie ganz und gar nicht unnoetig.

Gruss,

S:oren

Quote from TomJoad

Dieses "out of bounds" kommt, wenn die Uhrzeitanzeige im Setup aktiv ist (die eigentlich völlig unnötig ist).

Der DrawText in DrawClock müsste bei Index 31 beginnen.

Ausprobiert, hilft aber nicht...andere Idee?

Quote from 9000H

I get "Warning: out of bounds write access to teletext page" on the console, but works.

den habe ich auch schon gesehen...aber nicht immer, manchmal aber auch beim VDR-Shutdown

Hab mal Fehlermeldung erweitert, hier kommt es her:

Warning: out of bounds write access to teletext page (MakeDirty, x=72, y=51)

und zwar massenhaft manchmal (Limit ist bei 25, von 46-52) - ich such mal weiter

vielleicht geht einem über Nacht ein Licht auf, das ist der Trigger:

ClearMessage: MessageX=429 MessageY=453 MessageW=422 MessageH=53 OffsetX=3 OffsetY=3 ScaleX=66365 ScaleY=67147

ClearMessage: Call MakeDirty with area x0=35/y0=46 <-> x1=72/y1=52

wie man sieht, ist y0 und y1 > 25, irgendwie wird ein zu großer Bereich errechnet

BTW: das Spacing paßt auch nicht so ganz, die Kante der farbigen Hintergrundbalken (Privatsender Teletext) ist oben identisch mit dem Buchstaben...da fehlen imho mindestens 2 Pixel, dann wär der Text horizontal mittiger.