Vermutlich ein Ausgabeplugin mit H.265-Dekoder benutzen...
Gruss,
S:oren
Posts by S:oren
-
-
Die 6400 war vom Start weg rar. Man könnte auch sagen: Nur ein paar ausgewählte Personen haben so ein Teil.
Ausgewaehlt wuerde ich nicht sagen. Wer das Geld ausgeben wollte, hatte auch eine.
Würde mich ja tatsächlich mal interessieren wie viele davon tatsächlich damals verkauft wurden. Mehr als 100 Stück oder weniger?
Es gab ein paar Entwicklungsexemplare, dann 1000, soweit ich weiss. Ob es danach noch weitere Serien gab, weiss ich nicht.
Gruss,
S:oren
-
Bei der "überwältigenden Unterstützung" aus der Community, die ich auf der Mailingliste bekomme, kann das schon passieren.
-
Da bin ich ja mal neugierig. Glaube eher nicht, dass daraus was wird.
Was soll bitte nichts werden, wenn Linus selbst den Unfug revertet hat?
-
Das koennte erklaeren, warum ich bei OSD Größe 1280x720 im dvbhddevice-Plugin so einen Effekt nicht sehe. Bei fester OSD-Aufloesung muss nicht auf ein Signal gewartet werden.
Gruss,
S:oren
-
Wahrscheinlich ist das auch noch stark von der restlichen Harware abhängig.
Ach ja, ich hatte den Spezial-Support fuer steinalte Hardware (z.B. armv5, Cyrix C7) aus dem Treiber entfernt. Aber fuer alles halbwegs aktuelle (armv7+, x86 Core-Whatever, alles 64bittige) sollte es da keinen Engpass geben.
Gruss,
S:oren
-
1 Sec vergeht bei mir übrigens auch beim Skin LCARS, wenn ich das Menü aufrufe.
Das klingt doch fast so, als ob die vdr-interne OSD-Implementierung hier beim ersten Aufruf irgendwie recht lange braucht. Ist jetzt nur eine Idee aufgrund vorheriger Posts, ich habe da nichts getestet. Eine Sekunde vergeht bei mir nicht, das wuerde mich wahnsinnig machen. Oder mein Zeitgefuehl ist komplett kaputt.
Ich habe im dvbhddevice-Plugin OSD Größe 1280x720 und TrueColorFormat ARGB8888 eingestellt, das hat vermutlich Einfluss...
Gruss,
S:oren
-
Die einzig wichtige Änderung ist das Deaktivieren der Threads. Das führt gefühlt zu einem etwas langsameren Aufbau der Info-Ansicht. Allerdings werden dadurch alle OSD-Elemente gleichzeitig angezeigt. Das halte ich persönlich für die bessere Lösung (auch bei der TT6400), ist aber grundsätzlich auch Geschmackssache und kann bei langsamer Hardware durchaus etwas länger dauern.
Ich bin leider noch nicht dazu gekommen, hier mal draufzuschauen (und werde leider auch sobald keine Zeit haben). Aber wenn es mit den neuen Änderungen langsamer wird als im light-Branch (auch ohne die ganzen Threads), dann stimmt irgendwas nicht. Da muss ich nicht im Sekundenbereich warten (auf der S2-6400).
Gruss,
S:oren
-
Vielen Dank schon mal fuer die ganzen Updates. Leider bin ich noch nicht dazu gekommen, das auszuprobieren. Kann auch leider noch laenger dauern. Klingt aber alles schon mal gut.
- weniger Threads (sind jetzt so weit wie möglich eliminiert)
Dieser Punkt ist Hauptgrund (und der einzig wichtige), warum ich die light-Version verwende. Die vdr-PLUGINS.html ist da eindeutig:
Ein Skin-Plugin darf also nicht mit mehreren Threads auf das OSD zugreifen. Wenn es doch funktioniert, dann nur zufällig.
Wenn die Threads so weit wie moeglich eliminiert sind, welche gibt es noch?
Möglicherweise liegt das am dvbhddevice Plugin.
Soweit ich weiss benutzt dvbhddevice die Standard-OSD-Implementierung von vdr (im Gegensatz zu dvbsddevice). Erst das fertig gerenderte OSD wird auf die Hardware uebertragen. Das cPixmap::Lock() hat somit nichts mit der Hardware oder dem Plugin zu tun, denke ich. Wird da auch mit mehreren Threads drauf zugegriffen? Oder passiert bei dem ersten Aufruf irgendeine Initialisierung, die vielleicht auch Hardware-Parameter abfragt?
Gruss,
S:oren
-
Hier 'rumzubasteln ist keine Lösung.
Das ist eine klare Regression im Linux-Kernel, und das geht gar nicht.
Danke fuer das schnelle finden, noch waehrend 5.14-rc3.
Gruss,
S:oren
-
Am Treiber selbst hat sich zwischen 5.12 und 5.13 nichts geaendert. War nur ein Rebase auf die neue Kernelversion.
Fuer mich sieht die Fehlermeldung auch nicht nach Compilerproblemen aus, mit dem Tumbleweed-Build-Flow kenne ich mich leider auch nicht aus.
Gruss,
S:oren
-
Nicht speziell für 2.5.6, aber generell seit meinem Umstieg auf 2.5.x nutze ich diesen beiden Patches. Der erste ist für mich nötig, damit die Fernbedienung wieder so schnell reagiert, wie ich es von vdr-2.2.0 gewöhnt war. Der zweite nutzt die beiden Devices einer HD-FF in einer (für mich) angenehmeren Art, insbesondere wird der Liveview nicht gestört, wenn eine Aufnahme auf dem selben Transponder startet. Für nicht-FF-Karten sollte sich das Verhalten nicht ändern, aber die Device-Auswahl ist immer ein Minenfeld und sicher auch ein Stück weit Geschmackssache.
Vielleicht hat noch jemand Verwendung dafür...
Gruß,
S:oren
-
Mir ist erst jetzt aufgefallen: es gab noch Patches im Devel-Light-Branch. Hab es ausprobiert, funktioniert alles .
Ueberhaupt hatte ich (mit diesem Branch) schon lange keinerlei Abstuerze oder andere Probleme mehr. Funktioniert fuer mich perfekt.
kamel5 Waere es mal wieder Zeit fuer eine neue Version? Oder bist Du gerade noch an den oben angekuendigten Anpassungen dran?
Gruss,
S:oren
-
Wie schon geschrieben, man kann es ganz sicher auch anders machen. Das IR-Device ist nur das letzte, was der Treiber initialisiert. Wenn das da ist, sind sicher auch die DVB-Devices der S2-6400 einsatzbereit. Und auf die ist schwieriger zu testen (insbesondere wenn ich /dev/tt6400ir sowieso anlege weil die Konfiguration des Remote-Plugins dann einfacher ist).
Wenn jemand eine einfachere oder elegantere Moeglichkeit weiss, auf das Laden und Initialisieren des Treibers zu warten, von mir aus gerne...
Gruss,
S:oren
-
Sörens Hinweis trifft übrigens nur zu, wenn Du den IR-Empfänger der S2-6400 nutzt,
Ähm, nö!?
systemd wartet mit dem vdr-Start darauf, dass dieses Device erscheint, was natuerlich nur nach dem erfolgreichen Laden des Treibers passiert. Und ja, ich nutze diesen Link dann auch fuer das remote-Plugin, aber da weiss systemd nichts davon.
Gruss,
S:oren
-
Was sollte ich genau in der Datei 'vdr.service' eintragen, damit der Start des vdr auf den fertig geladenen Treiber wartet?
Da gibt es sicher sehr viele Moeglichkeiten.
Ich habe eine /etc/udev/rules.d/99-tt6400-ir.rules mit
und eine /etc/systemd/system/vdr.service mit unter anderem
Gruss,
S:oren
-
Leider nicht.
Gruss,
S:oren
-
Naja, meldet sich wieder mit 2.0.2_38_gb2f5e02 als Version weil kein Tag vorhanden ist.
Das finde ich genau richtig so. Ist ein separater Entwicklungsbranch, und der hat noch keine Versionsnummer oder Tag (mehr s.u.).
...wenn das immer noch nicht gefällt, dann mach ich nur noch PRs und um das Hauptrepo und die Einsortierung kund Taggen ann sich jemand anders kümmern...
Du bist Maintainer, kannst also machen, was Du willst.
Ich hatte beschrieben, wie ich es handhaben wuerde, wenn ich Maintainer waere. Diese Regeln sind natuerlich nicht die einzig sinnvollen, haben sich aber in anderen großen Community-Projekten (linux, u-boot) bewaehrt. Ob man sich hier darauf einigen moechte, wurde ja noch nicht mal diskutiert.
Das Einhalten solcher Regeln erfordert Disziplin, ermoeglicht aber auch eine einfachere Zusammenarbeit und ergibt eine bessere Qualitaet und Wartbarkeit des Codes. Der Branch milestone-2.1.0 erfuellt wieder quasi alle meine Regeln nicht (muss er auch nicht, ich bin ja nicht der Maintainer). Aber so weiss ich weder, was ich testen sollte (welche Features/Fixes,...), noch kann ich irgendwas reviewen (was ist der Grund fuer die Aenderungen, gibt es bessere Implementierungsalternativen), noch ist klar, in welcher Beziehung dieser Branch zum aktuellen master steht, und was der aktuelle Stand (Version/Tag) sein soll.
mein Hauptaugenmerk liegt auf Verstehen und Fixen und Erweitern vom Code
Gerne in dieser Reihenfolge. Besser als vorhandene Features erst aus- und dann wieder einzubauen, oder anerkannte Standardloesungen ignorieren, weil es manchmal trotzdem auch anders funktioniert.
Nun ja, vieles ist Geschmacksache. Es gibt sicher verschiedene Ansichten. Etwas Toleranz von allen Seiten ist fuer ein Freizeitprojekt sicher auch nicht verkehrt.
Unbestritten duerfte sein, dass Du das Plugin weiterentwickelt und neue Features eingebaut hast, was sicher nicht nur fuer mich einen bedeutenden und gern gesehen Fortschritt darstellt. Danke dafuer.
Wie hier eine (weitere) Zusammenarbeit im Sinne eines Community-Projektes aussehen soll, verstehe ich allerdings leider noch nicht. Deine "chaotische Branch-and-Merge-Strategie", wie ich es genannt habe, ist so komplett anders als alles, was ich kenne, dass ich nicht weiss, wie ich damit umgehen soll. Anscheinend geht es anderen Leuten auch so. Und dieses Plugin sollte doch allgemein nutzbar bleiben, waere schade sonst.
Gruss,
S:oren
-
Richtige Handhabung von git ist wohl nicht so trivial...und meine Kenntnisse darin nicht die besten....ich gebe gerne die Leitung vom Haupt-Repo wieder ab
Schade. Waere ja eine gute Gelegenheit zu lernen, wie es besser gemacht werden kann.
Gruss,
S:oren
-
Ein Entwickler-Repo halte ich auch fuer eine sehr gute Idee. Auch gerne mit verschiedenen aktiven Entwicklungs-/Topic-/Test-/Was-auch immer-Branches (neben dem master).
Bitte einen Branch fuer jede Entwicklungslinie, diese Branches immer basierend auf einem getaggten Release, und nur an einer Sache gearbeitet in jedem Branch. Bei auftretenden Problemen gerne mit auch mal mit einem topic-v2-Branch (basierend auf dem selben Tag wie topic), wo mit git rebase (fixup/squash) die Probleme in den Commits des topic(-v1)-Branches gefixt werden und so spaeter noch die wirklich letztendlich sinnvolle Entwicklung nachvollzogen werden kann. Die Commits gerne mit einer sinnvollen Beschreibung, _warum_ man etwas so gemacht hat (was geht ja aus dem Code hervor). Beim Beschreiben merkt meist man selbst recht schnell, ob das so eigentlich wirklich Sinn ergibt.
Wenn dann ein Feature fertig und getestet ist, dann wird das in in den master gemerged (nicht umgekehrt). Ich bin ja eher ein Freund von rebase, wenn sowieso nur ein Entwickler daran arbeitet. Aber auch jeweils ein expliziter Merge-Commit waere ein sinnvolle Strategie, was dann fuer Einheitlichkeit bei Merges von externen Topic-Branches aus Repositories anderer Entwickler sorgt. Dann koennen anschliessend die lokalen topic(-vx)-Branches wieder geloescht werden.
Nach einem oder mehreren Topic-Merges wird dann _im master_ eine neue Version erzeugt und getaggt. Und dieser getaggte master-Branch aus dem Entwickler-Repo wird dann unveraendert in das Haupt-Repo gepusht (nicht gemerged), so dass die git-IDs in beiden Repos fuer Releases identisch sind.
Das halte ich fuer eine sinnvolle git-Entwicklungsstrategie, kann es hier natuerlich nur so vorschlagen. Sicherlich ist das auch nicht die einzig moegliche Strategie, z.B. git-flow sieht noch kompliziertere Regeln vor. Das halte ich hier fuer uebertrieben, ist nur meine persoenliche Meinung.
Letztendlich braucht man auch nicht unbedingt ein zweites Entwickler-Repo, wenn man direkt im Haupt-Repo arbeitet (und sich daran haelt, dort niemals im master zu entwickeln). Dann braucht man auch kein lokales Repo mit mehreren Remotes (was an sich kein Problem waere, ich habe z.B. auch ein lokales Repo mit 4 Remotes). Hier fuer osdteletext funktioniert das nur nicht (gut), weil eben die Releases im Entwicklungs- und Haupt-Repo nicht die selben Commit-IDs haben.
Mal so als Anregung,
S:oren
