Suche Patches für VDR 1.7.21

Ich bin natürlich dran, den Extensionpatch wieder hinzubekommen. Einige Änderungen in 1.7.21 machen das aber ziemlich kompiliziert.

Ich könnte im Moment einen Extensionpatch ausliefern ohne: TTXTSUBS, DYNAMITE, LIVEBUFFER und WAREAGLEICON

Moin!

Ich hab da einen kombinierten Patch für dynamite, LNB-Sharing und Unicable:
https://raw.github.com/flensro…unicable+lnbsharing.patch

Da die drei an ein paar gemeinsamen Stellen eingreifen, versuche ich, sie zusammen zu pflegen. Es funktioniert soweit auch alles.
(für vdr 1.7.21 wird übrigens dynamite 0.0.8 benötigt, wenn man es haben will)

Lars.

Ich kann mit dem kombinierten Patch aber nichts anfangen. Ich brauch die einzeln.

Schlimm genug , dass man immer noch den Wareagleicon Patch (und nen Symbolfont) braucht.
Ich glaube den spiele ich schon seit 10 Jahren ein

Gerade der Patch macht mir im Moment am meisten Sorgen. Naja ich wollte Klaus sowieso mal wieder eine Mail schreiben. Vielleicht fällt ihm ja was nettes ein.

Zitat von gandalf247

ich suche folgende 3 Patches für VDR-1.7.21
HARDLINKCUTTER

Da die Änderungen am recorder teilweise zurück genommen wurden, funktioniert beim HL-Cutter wieder die Patch-Version 1.7.14, die noch bis VDR-1.7.19 funktioniert hatte.

---

Und weil ich gerade schreibe, aktuelle Versionen des S2API-Wrappers gibts auch:
Version 0.7 für VDR-1.7.13-VDR-1.7.20 (<-- autsch, vergessen)
Version 0.7 für VDR-1.7.21

Die 0.7 ist eigentlich seit Dezember fertig, irgendjemand hat aber den Upload vertrödelt.
Die 0.7 kann wahlweise bei SD-FF über PES oder TS ausgeben, und übersetzt klaglos mit DVBv5-Headern, sprich: Mit allen Header-Versionen übersetzbar, auf allen Kernel-Versionen lauffähig, und nutzt automatisch vorhandenes S2API des Kernel.

Da S2API aber nun wirklich in allen aktuellen Distris bereits drin ist, dürfte das langsam aber auch das letzte Update sein, dass ich für diesen Patch bringe.

Gruß,

Udo

Zitat von Copperhead

Gerade der Patch macht mir im Moment am meisten Sorgen. Naja ich wollte Klaus sowieso mal wieder eine Mail schreiben. Vielleicht fällt ihm ja was nettes ein.

Wird das noch was mit dem WAREAGLEICON Patch, von mir aus wird er sogar überflüssig weil z.B. KLS den VDRSymbols.ttf etwa nutzen wird und den Patch quasi übernimmt? Jedenfalls trudelte bei meinem Gentoo Update heute ein vdr-1.7.21 ohne WAREAGLEICON, was ich schade finde, nachdem ich schon seit einiger Zeit auch im stable branch des graphlcd Plugins Code eingecheckt habe, welcher diesen Patch und den Font nutzt...

Lösung: Extrecmenu verwenden. Dort wird der Font unterstützt. Und zwar ganz ohne Patches. Auch der Graphlcd-Fix funktioniert zusammen mit Extrecmenu.

Zitat von Mreimer

Lösung: Extrecmenu verwenden. Dort wird der Font unterstützt. Und zwar ganz ohne Patches. Auch der Graphlcd-Fix funktioniert zusammen mit Extrecmenu.

Wirklich lösen tut das nur das Aussehen des Aufnahmemenüs, wenn man mal graphlcd esrtmal aussen vor lässt. Die Kanalliste, die Timer haben keine Icons mehr, und selbst wenn man graphlcd hinbiegt, wird es icons auch nur im recordings-menu (weil sie ja vom extrecmenu bestimmt werden) und in der Schedule (die ja Icons auch ohne den WAREAGLEICON Patch hat), zeigen, und dann gibt es noch yacoto, möglicherweise auch noch andere Plugins die diesen Patch nutzen können.

Ich habe natürlich wie angekündigt mit Klaus darüber gesprochen.

Er sieht das in etwa so:

Ein extra VDR-Font ist nicht drin, da damit alle arabischen und kyrillischen Schriftzeichen weg sind.

Die Skinentwickler sollen sich darum kümmern, richtige Icons zu implementieren.

Zitat von Copperhead

Die Skinentwickler sollen sich darum kümmern, richtige Icons zu implementieren.

Dürfte schwierig werden wenn das VDR OSD System sowas nicht nativ unterstützt.

Wobei WarEagle /nur/ andere Symbole verwendet. Also z.B. in der Timerübersicht wird das Zeichen 0xE00C ausgegeben anstatt ">". Ist jetzt nicht so das überkomplezierte Nur die Fallunterscheidung utf-8 ja/nein verkompleziert das etaws (aber ist auch nicht das Problem, kann man sich bei epgsearch/extrecmenu klauen).

So wie ich das sehe könnte der VDR all seine Symbole in ne extra Header Datei auslagern (symbols.h) und mit Preprozessor Ersetzung arbeiten.

Also, anstelle von
---
!(timer->HasFlags(tfActive)) ? ' ' : timer->FirstDay() ? '!' : timer->Recording() ? '#' : '>'
---
dieses
---
!(timer->HasFlags(tfActive)) ? ' ' : timer->FirstDay() ? ICON_BEDEUTUNG1 : timer->Recording() ? ICON_BEDEUTUNG2 : ICON_BEDEUTUNG3
---

Das würde die Sache doch schonmal deutlich vereinfachen. Dann müsste man die VDR Symbole nur in dieser Header Datei durch die Symbole des VDRSymbols Fonts ersetzen und nicht wild den kompletten VDR Quellcode patchen.

cu

Zitat von Copperhead

Ein extra VDR-Font ist nicht drin, da damit alle arabischen und kyrillischen Schriftzeichen weg sind.

Kann man den Font nicht mit den entsprechenden Unicode-Zeichen aus einer freien Schriftart auffüllen? Gibt es irgend einen wirklich guten Grund nicht komplett auf UTF-8 bzw. Unicode umzusteigen (gerade im Hinblick auf die Unterstützung von nicht-lateinischen Schriften)?

Zitat von Keine_Ahnung

Dürfte schwierig werden wenn das VDR OSD System sowas nicht nativ unterstützt....

Beim ReelVDR geht es doch auch, evtl sollte "man" sich da mal den Sourcecode ansehen.

--> man = Die Skinentwickler

Andere Plugins sollten den Patch garnicht nutzen. Er rüstet lediglich das Nutzen des vdr-symbols-Fonts im VDR nach.

Andere Plugins können selber die entsprechenden Unicode-Zeichen ausgeben um vom Font zu profitieren. Bei einigen Plugins muss ein entsprechendes Define gesetzt sein, dass dies so gemacht wird.

Yacoto setzt leider direkt auf eine Header-Datei vom Patch auf. Es kompiliert ohne, wenn man die "iconpatch.h" in den Plugin-Source legt, das Include im Plugin-Source so patcht, dass es die Header-Datei findet und im Makefile noch das "USE_WAREAGLEICON" hart definiert (zur DEFINES-Variable ein "-DUSE_WAREAGLEICON" anfügen).

Eleganter wäre es, wenn man das Define über eine Variable setzt. So könnte ein "YACOTO_USE_VDRSYMBOLS=1" in der Make.config diese Einstellung erledigen. Auch ein "make YACOTO_USE_VDRSYMBOLS=1 plugins" würde dann gehen.

Würde ich dieses Plugin nutzen, dann würde ich einen entsprechenden Patch mal erstellen. IMHO ist es aber hier klar das Yacoto-Plugin, dass einen Fix braucht. Der Font ist fix und nur um die passenden Unicode-Zeichen zu finden, den Patch vorauszusetzen, ist IMHO "etwas" übertrieben.

Was das EPG angeht: AFAIK braucht es epgsearch und eine passende Hauptmenü-Überschreibung (MAINMENUHOOKS-Patch) dafür. Wenn epgsearch so kompiliert wird, dass es den VDR-Symbols-Font voraussetzt, dann werden die Symbole angezeigt.

Wäre natürlicht nicht falsch, wenn der VDR ohne externe Hilfe die Symbole unterstützen könnte. Einen speziellen Font zu erzwingen ist dafür allerdings eher keine Lösung, die den Weg in den VDR-Source finden wird. Wobei die Idee mit dem TTF als Symbolquelle an sich nicht so falsch ist. Die Technik ist nicht unüblich und erspart uns irgendwelche Monster wie "cairo" im VDR. Man sollte den VDR-Symbols-Fonts lediglich *nur* für die Symbole nutzen. Also unabhängig vom im VDR gewählten Font. Wenn VDR-Symbols-Font da, dann die Symbole daraus nutzen. Wenn er fehlt, dann Fallback auf das aktuelle Verhalten.

Zitat von seahawk1986

Kann man den Font nicht mit den entsprechenden Unicode-Zeichen aus einer freien Schriftart auffüllen?

Anderstherrum, man kann diese Symbole in jeden beliebigen Font einfügen (diese Symbole liegen extra an Positionen die für sowas freigehalten werden). Damit kann auch jeder seine Lieblingsschriftwart nutzen wenn ihm die vom VDR Smbolfont nicht gefällt.

Noch schöner wäre ja ein kompletter Unicodefont (der um diese Symbole ergänzt wird), aber sowas gibts noch nicht.

cu

Zitat von C-3PO

Beim ReelVDR geht es doch auch, evtl sollte "man" sich da mal den Sourcecode ansehen.

--> man = Die Skinentwickler

Der ReelVDR taugt leider eher selten als Referenz.

Wenn ich nicht ganz irre, dann ist es mit einem Skin nicht getan. Die Änderung müsste direkt im VDR geschehen.

Zitat von Keine_Ahnung

Anderstherrum, man kann diese Symbole in jeden beliebigen Font einfügen (diese Symbole liegen extra an Positionen die für sowas freigehalten werden). Damit kann auch jeder seine Lieblingsschriftwart nutzen wenn ihm die vom VDR Smbolfont nicht gefällt.

Das ist im wahrsten Sinne des Wortes "gut gemeint" aber nicht "gut gemacht". VDR sollte auch ohne verbastelte Fonts laufen. Eine mögliche Lösung habe ich bereits beschrieben: Einen puren Symbolfont, der wirklich nur für die Symbole hergenommen wird. Keine Ahnung wie viel man am VDR ändern muss, um dieses "Font-Mischen" im OSD zu ermöglichen.

Zitat von Mreimer

Das ist im wahrsten Sinne des Wortes "gut gemeint" aber nicht "gut gemacht".

Das ist alles was wir haben.

Pre 1.6 wurde im laufenden VDR der Font gepatcht (weil Rasterfont, da ging das).

Zitat von Mreimer

Einen puren Symbolfont, der wirklich nur für die Symbole hergenommen wird. Keine Ahnung wie viel man am VDR ändern muss, um dieses "Font-Mischen" im OSD zu ermöglichen.

Zumindest bräuchten wir dann eine Art Sytax für die Menüs (Weil ein Listeneintrag ist immer ein String). D.h. das Plugin sagt nicht mehr
"1\tDas Erste\t[|||| ]"+0xE00C+"\tToller Film"
sondern
"1\tDas Erste\t[|||| ]<font name="symbol">0xE00C</font>\tToller Film"

Ich hoffe das Beispiel ist verständlich.

HM, nach dieser Art Implementiert müsste am VDR wohl auch nix geändert werden, oder? Das ist dann ja Sache der Skins. Aber trozdem etwas unelegant.

cu