Absolut falsches Statement!
Und selbst:
Was gibt Dir das Recht darüber zu entscheiden?
Posts by S:oren
-
-
Schoen, dass es jetzt wieder funktioniert.
Ich hatte tatsaechlich vor Weihnachten auch komische Effekte an einem meiner VDRs (gelegentliche Standbilder oder kein Lock), da war es das Netzteil. Naja, hatte beim Debuggen noch ein paar kleinere Verbesserungen am Treiber eingebaut, das sollte aber im Normalbetrieb keinen Unterschied ergeben.
Gruss,
S:oren
-
Schade, dass Du das Problem nicht finden konntest. Die heißeste Spur ist ja das Softwareupdate im letzten halben (?) Jahr. Nur gab es weder am dvbhddevice-Plugin noch am saa716x-Treiber irgendwelche relevanten Aenderungen in den letzten Jahren.
Wenn es nach einem Stromausfall ploetzlich merkwuerdige Probleme an einem langjaehrig gelaufenen System gibt, waere fuer mich das Netzteil der erste Kandidat, wo ich Hardwareprobleme vermuten wuerde.
Gruss,
S:oren
-
Speziell die Tatsache, dass die tolle FF-Karte ausstirbt und es immer schwieriger wird, sie überhaupt ans Laufen zu bringen ist schon sehr frustrierend.
So schlimm? Die S2-6400 läuft bei mir hervorragend mit vdr-2.2, 2.4, 2.5.x, allerdings habe ich analog-Out bisher nur mit der SD-FF genutzt.
Leider waren auch meine Versuche im SourceCode irgendeinen Anhaltspunkt zu finden, erfolglos.
Auf den ersten Blick sehe ich nicht, warum (auch bei mir) diese Einstelloption nicht angezeigt wird. Es gibt jedenfalls neben dvbhddevice.AnalogueVideo = 0 (disabled) auch die Optionen 1 (RGB), 2 (CVBS + YUV) und 3 (YC (S-Video)).
und bis vor 2 Wochen lief ja alles perfekt.
Und was genau hat sich in den 2 Wochen verändert?
Gruß,
Sören
-
Vermutlich ein Ausgabeplugin mit H.265-Dekoder benutzen...
Gruss,
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
