Danke cinfo für Deine Tips. Auf Ubuntu mit den Oibaf PPA´s gäbe es das scheinbar alles. NUC12 wird also scheinbar VA-API seitig weiter unterstützt.
Frage: Wenn auf meinem Rechner Debian-Bullseye läuft, kann ich das zusammen mit dem Oibaf-PPA betreiben, oder zerschieße ich mir mit dem "mixen" das ganze System?
M.f.G.
Michael
Der neue Kernel ist drauf, ein DualChannel DVB-C Empfänger funktioniert auch.
Gerade möchte ich softhddevice und softhdvaapi installieren, stolpere aber über den Satz von Stefan:
QuoteBenötigt der NUC-12 nicht den Intel-Media-Treiber? Funktioniert softhddevice mittlerweile damit? Ich dachte, softhddevice geht nur mit dem vaapi-Treiber.
Kann einer der Spezialisten etwas dazu sagen?
M.f.G.
Michael
Dann werde ich das mal auf meinem NUC-12 ausprobieren, wenn bei ihm das Kernel-Update 5.19 gelaufen ist.
Der jetzige Kernel 5.10 unterstürzt nämlich den AlderLake noch nicht richtig ...
Wenn ich Debian-Bullseye zusammen mit dem LXDE Desktop als Oberfläche nutze, hab ich wahrscheinlich
unter der Haube auch den X11 Server (also XORG) am Laufen, und muß wahrscheinlich softhdvaapi nehmen.
Das probier ich bei Gelegenheit mal aus. Danke für die Tip´s ...
Danke cinfo für die Info.
Das mit dem fehlenden IR beim NUC-12 kenne ich. Das läuft dann bei mir über USB.
Kann man in zwei/drei Sätzen beschreiben, wie die drei Pakete zusammenspielen?
M.f.G.
Michael
Hallo zusammen,
ich hab bei mir zwei Intel NUC´s mit Debian-Bullseye und LXDE Desktop am laufen. Da ist jeweils VLC drauf, ein Web-Browser, ein Bildbetrachter, als auch das VDR-System von Debian mit dem xineliboutput-sxfe Plugin. Seit dem ich das in der Standard HDMI Auflösung nutze hab ich ständig Probleme mit Bild und Ton (nach dem Umschalten läuft der Ton manchmal nicht sofort los, und das Bild wirkt manchmal im oberen viertel als zusammengesetzt aus 25% altem und 75% neuem Bild.
Für Eure Rückmeldung - was sich da bewährt hat und was mittlerweile auch stabil läuft - wäre ich Euch dankbar.
M.f.G.
Michael
p.s. Da mein Beamer nur HD hat reicht mir Full-HD Auflösung. Beim Audio bin ich mit Stereo unterwegs. Ich nutze auch keine CI Karten, sondern bekomme mein Programm über Kabel-TV
Wenn jemand noch die Konfiguration meines Produktivsystems NUC-10 interessiert, die sieht wie folgt aus:
Das zweite System zum Ausprobieren und Testen ist ein NUC12WSHi5 mit i5 Alder Lake Prozessor. Ob da drauf das vaapi schon sauber läuft - keine Ahnung
Das VDR System ist ein VDR (2.4.1.-4.1), das vdr-plugin-xineliboutput (2.1.0+git20191101-1.1)
Ich kämpfe mich gerade Stück für Stück nach vorne ...
Ich hab jetzt die Debian-Quellen zu softhddevice aus meinem Stand geholt, und gehofft daß ich
dann bei einem Compare mit den rofafor Sourcen eine Hand voll Stellen finde, die ich nachziehen
muß. Aber das sind ja hunderte von Stellen wo sich das unterscheidet ...
Der Stand trägt den Namen "softhddevice-0.6.0+git20160108". Ich bekomme damit sogar ein Bild,
bei HD kommen aber weiterhin die schon bei meinem Vorgängersystem aufgetauchten Bildstörungen
(und die Meldung HW-Accelerator failed to decode picture) ...
m.f.G.
Michael
Hallo zusammen,
ich möchte mit meinem Skylake Intel-NUC auch noch einmal das VA-API zum Laufen bringen.
Mit welchem der beiden Repositories (siehe die beiden Links im Anfangs-Post) zu starten ist sinnvoller?
Das von Rofafor, oder das von Johns?
Mir geht es nicht um 4K-TV (da sind bei Johns schon weitere Auflösungen drin), solch einen TV hab ich nicht.
Mir geht es darum, daß ich nicht die ganzen Patches die in den letzten 2-3 Jahren zu VA-API kamen einzeln aufsammeln muß ...
Und welcher der beiden für Standard Auflösungen stabiler und ggf. problemloser läuft ...
Und an ck3d: Du hast dann vom Intel Treiber die Sourcen geholt, und ihn neu mit X11 Support übersetzt?
Mein System: Intel-NUC, mit Debian Stretch Linux 4.9.30 und VDR 2.2.0
Vielen Dank im Voraus
Michael
Kannst Du uns verraten, wie und womit Du das aufgesetzt hast?
Hallo TEN,
ich hab mir die Quellen von inputlirc besorgt, und dann inputlircd übersetzt. Die zwei Zeilen hab ich im Code in der Funktion processevent() eingefügt, und in den Syslog getraced. Die eine Zeile oben, wo die ganzen Events reinkommen und noch alle Events zu sehen sind (auch die, die später gar nicht an VDR weitergeleitet werden (Misc und Syn)), die zweite Zeile unten, kurz bevor der Event an lircd weitergeleitet wird ...
Damit kann ich genau nachverfolgen welche Events reinkommen (aka was die Fernbedienung liefert, und vom IR-Sensor auch erkannt wird), und welcher Teil davon an lircd weitergegeben wird ...
Mit etwas Spielen an den Zeiten, hab ich dann Werte herausgefunden, mit denen Repeatkommandos an den lircd weitergegeben werden ...
Irgend einen Fehler hab ich in der Generierung noch drin gehabt, denn mit dem selbstgenerierten inputlircd hat mein VDR überhaupt keine Tasten von der Fernbedienung bekommen, aber ich konnte den Output im Syslog verfolgen, ob der paßte oder nicht. Mit den gleichen Zeiten und dem ursprünglichen inputlircd Treiber ging es dann auch mit VDR.
Ich hänge unten mal den Code ran, mit dem ich das getestet habe ... (such mal nach MIZE)
m.f.G.
Michael
Hallo zusammen,
hier die Event´s die ich jetzt bekomme, in einer selbst generierten Version von inputlirc ...
- Inputlircd info 1 ist oben im Inputlircd, wo die ganzen Event´s ankommen (Type 1=KEY, Type 4=MISC, Type 0=SYN)
- Inputlircd info 2 ist unten im inputlircd, wo der Event Richtung über /var/run/lirc/lircd an VDR weitergegeben wird (1: Tastencode in Hex, 2: Repeat-Zähler, 3: Text String "Key_Code_" mit Tastencode dezimal angehängt; 4: Empfängerdevice)
Man sieht schön, wie der Repeat-Zähler hochgezählt wird. Werden Repeat Tastendrücke von der FB erkannt, wird eine Taste-Losgelassen Meldung erzeugt, und ein Stück später die Taste als erneut gedrückt gemeldet. Damit erkennt VDR wiederholte Tastendrücke (auch wenn die FB dauerhaft betätigt wurde).
m.f.G.
Michael
Hallo zusammen,
Praxis ist bekanntlich wenn´s geht, und keiner weiß warum ...
Nachdem ich gestern mit den Zeiten herumexperimentiert habe, hatte ich den Rechner mit der verlängerten Zeit
in der /etc/default/inputlirc (OPTIONS="-g -m 0 -r 750 -d /var/run/lirc/lircd") stehengelassen.
Gestern Abend ging plötzlich zum ersten mal der Tastenrepeat !!!
Die Frage: Hat da Mittags beim Test der längeren Zeit ein Reboot gefehlt??? Schau ich mit heute Abend noch mal an,
und melde mich. (Den Patch von seahawk hab ich mir zwar mal angesehen, aber nicht installiert bzw. das Script nicht
bewußt laufen gelassen ... Warum das plötzlich geht, ist mir völlig schleierhaft.)
m.f.G.
Michael
Hallo fnu,
ich hab in der Zwischenzeit mal mit den Zeiten gespielt - keine Veränderung. Der Tastenrepeat funktioniert nicht.
Wenn ich für 2-3 sec den Lautstärke luter Knopf an der FB drücke, geht im VDR das Fenster mit dem Balken für die
Lautstärke auf und um einen Tick nach rechts. Nach 2-3 sec. geht das Fenster wieder zu, obwohl ich noch immer
die Taste auf der FB drücke.
Gestern hab ich mal die Sourcen von devinput geholt und reingeschaut: Devinput geht nur auf das EV-KEY Device.
Damit wandelt sich das Problem für mich zu: Wie stelle ich den Kernel (-driver) auf die Repeat Zeit meiner FB ein.
Solange das Input device auch bei 3 sec Taste auf der FB drücken nur einen Tastendruck zeigt (siehe oben), kriegt
inputlirc und vdr keine wiederholten Tasten mit.
Nur wie ich das Inputdevice vom Kernel konfigurieren kann - dazu finde ich nichts ...
m.f.G.
Michael
Hallo fnu,
weißt Du, ob Inputlirc die EV-MSC (Miscellaneous) Events verwendet, oder die scheinbar bereits von Linux gelieferten EV-KEY Events?
Wie mir scheint hat die FB ca. 250ms Zeit, den Tastendruck zu wiederholen, dann bleibt der Eventkey unverändert (Taste bleibt gedrückt).
Wenn die FB länger als 250 ms keinen Repeat mehr gesendet hat, generiert Linux (der Linux-Treiber?) selbständig einen Event Taste losgelassen.
Dazwischen können 1000 Repeats kommen - Linux schickt keine neuen EV-Key Meldungen ...
m.f.G.
Michael
Hallo zusammen,
Hat keiner für mich keiner einen Tip, wie ich den Tastenrepeat ordentlich zum Laufen bekomme?
Ich nutze inputlirc, und das normale Bedienen mit der Fernsteuerung klappt. Nur der Repeat nicht.
Wenn ich mit ir-keytable -t beim längeren Druck auf eine Taste auch Repeat Tastendrücke
erkenne (mehrfache scancodes, aber nur einen einzelnen key-down und key_up), später dann
mit irw nur einen einzelnen Tastendruck angezeigt bekomme, wo kann ich da weiter suchen?
Vielen Dank im Voraus,
Michael
Hallo seahawk1986,
vielen Dank für die schnelle Antwort. Das Maskieren von lircd und lircd-uinput hat geholfen. Klasse.
Zwei Fragen noch, wenn ich darf (vielleicht kannst Du oder ein anderer Leser noch was dazu sagen) ...
Ich hatte das so verstanden, daß "lirc" alleine nicht mehr reicht, man sollte jetzt auf die input/event
Schnittstelle und inputlirc umstellen, oder alternativ auf eventlirc umstellen ...
War das eine Fehlinterpretation, d.h. lirc unterstützt genausogut die input/event - Schnittstelle,
und es wäre geschickter auf inputlirc zu verzichten (weil überflüssig)? Dann bräuchte ich aber doch
neben lirc den Eventlirc Unterbau, damit etwas an "/var/run/lirc/lircd" ankommt. Bei inputlirc komme
ich ohne eventlirc aus, und emittiere gleich nach "/var/run/lirc/lircd". Also neben lirc muß man einen
von beiden haben: inputlirc oder eventlirc. Richtig? Welcher ist zukunftsträchtiger?
Vielen Dank im Voraus,
Michael
Hallo zusammen,
nach einem halben Jahr Betrieb mit meinem Intel-NUC Skylake wollte ich ein Problem mit dem Tastenrepeat der Fernbedienung
beheben, und hab erst mal ein Dist-Upgrade auf die aktuelle Version gemacht. Damit kam die Version 4.8 auf meinen Rechner ...
(ganz genau: uname -a liefert Linux Intel-NUC 4.8.0-2-amd64 #1 SMP Debian 4.8.11-1 (2016-12-02) x86_64 GNU/Linux)
Nach dem Upgrade lief VDR wieder, nur die Fernbedienung ging nicht mehr ...
Nach etwas Analyse des Problems sehe ich folgendes Verhalten:
Die Regeln zum automatischen Einlesen der Keymap und des Einrichtens des Input-Devices greifen (sonst hätte
ich schon mit ir-keytable -t nicht die korrekte Bezeichnung der gedrückten Tasten gesehen ...
Nur nicht daß sich da Debian weiterentwickelt (ich lese da etwas von einem "Started lircd(8) initialization helper tool."
und dann startet da ein "lircd-uinput" der "Reading data from /var/run/lirc/lircd, writing to /dev/uinput" und mir ggf.
das Input-Device belegt ...
Ein Grep nach lirc bringt folgendes zu Tage ...
Kann da ein Spezialist von Euch etwas dazu sagen, warum ich diesen inputlirc Neustart benötige?
m.f.G.
Michael
p.s. ich wußte jetzt nicht, ob das lirc spezifisch ist (und in´s Fernbedienungs-Forum gehört), oder ob das
Debian spezifisch ist (vermute ich als erstes). Wenn es anders herum geschickter ist, bitte sagen ...
Hallo SurfaceCleanerZ,
was spricht gegen Softhddevice?
Klar, SofthHdDevice wäre für mich auch der letzte Ausweg, wenn ich VDR-SXFE nicht sauber zum Laufen bekomm.
VDR-SXFE gefällt mir halt besser, weil dann VDR auch im Hintergrund laufen kann, wenn VDR-SXFE nicht gestartet ist ...
Ich hatte die Hoffnung, daß es einen Trick gibt, dies auch unter HD stabil zum Laufen zu bekommen,
An den VAAPI Treibern liegt es auf jeden Fall nicht. Die laufen ja mit VLC auch astrein, und damit ist auch
bewiesen daß die Aufzeichnung und der USB DVB-C Receiver klaglos seinen Dienst tut.
Ich hatte gehofft, von Seahawk noch einen Tip zu bekommen, ob er mit LXDE und openbox Probleme sieht (bzw. wo das
sein könnte, oder ob sich da openbox und light-dm in die Quere kommen). Mal sehn, vielleicht meldet er sich ja noch, oder
ein anderer Spezialist gibt mir einen Tip was ich hier untersuchen könnte ...
m.f.G.
Michael
Ich schau mir gerade die verschiedenen Varianten an, die es gibt: das müßte LXDE gewesen sein
(ich hab damals schon nach etwas schlankem gesucht ...).
Und in der LX-Session Konfiguration sagt er, openbox wäre der Windows Manager.
Hallo zusammen,
seit etwa einem Jahr eiere ich mt meinem Intel Broadwell NUC (i3) herum, und bekomme die Ausgabe über
xineliboutput-sxfe mit HD nicht ordentlich zum Laufen. SD Programme gehen ja noch so, aber wenn ich HD
Material im Fernsehen ansehen möchte, bekomme ich ständig Bildaussetzer (lauter Klötzchen im Bild, und
es dauert in etwa eine halbe Sekunde, bis das Bild wieder stabil ist).
Zuletzt war ein paar Monate Pause. Heute hab ich ein upgrade auf libva-1.7.0 gemacht (die ganz aktuellen
Stände von Debian Stretch), VA-API 0.39, ... (weil ich gemeint habe, das liegt evtl. an Bugs in VA-API für
Broadwell) - doch weiterhin unverändertes Verhalten.
Wenn ich sxfe manuell von der console aus starte, mit
event.code < key_min)
vdr-sxfe --verbose --video=vaapi --audio=alsa
bekomme ich ständig Zeilen mit
[h264 @ 0x7f9a8c0603a0] hardware accelerator failed to decode picture
[h264 @ 0x7f9a8c0603a0] hardware accelerator failed to decode picture
[h264 @ 0x7f9a8c0603a0] hardware accelerator failed to decode picture
200 frames delivered, 16 frames skipped, 0 frames discarded
[h264 @ 0x7f9a8c0603a0] hardware accelerator failed to decode PictureAnsehen einer HD-Aufzeichnung (von BR3) mit ...
Ich weiß jetzt nicht, wie ich den Fehler weiter eingrenzen kann.
Wenn einer einen Tip für mich hätte, wie ich auf Debian, VDR 2.2 den vdr-sxfe zum Laufen kriege
(oder mit was der Fehler zusammenhängt, und wie ich ihn weiter eingrenzen könnte), wäre ich dankbar.
Auch wüßte ich gerne, ob einer von Euch VDR-SXFE und VA-API zusammen am Laufen hat ...
Vielen Dank im Voraus, für evtl. Hilfestellung.
m.f.G.
Michael
Hallo zusammen,
der Absturz ist raus - das waren Log-Einträge die ich beim Start des softhddevice in ein File in /var/log/...
geschrieben habe. Dort darf man als normaler User scheinbar nicht rein schreiben ...
Folgender Effekt bleibt:
=> wie kann ich softhddevice dazu bringen, bei Fehlern etwas in´s Log zu schreiben???
p.s. auch das Eintragen des X-Servers hat nichts gebracht - kein Bild und Ton nach Rechner booten.
Ohne Trace komme ich nicht weiter ...
m.f.G.
Michael
Hallo Seahawk,
Danke für Deine schnelle Antwort ...
Das muß "-d :0" heißen, richtig. Und mit "vdr --showargs" sehe ich jetzt auch, daß die Parameter richtig übergeben werden.
Mein eigentliches Problem bleibt aber weiter bestehen - das mit den Parametern war es also nicht ...
Ich sehe, daß das Plugin geladen, und etwas später initialisiert wird. Danach bekomme ich einen segfault ...
vdr: [1525] initializing plugin: softhddevice (0.6.1rc1 MIZE V-01 2015-12-21 17:45): Ein Software und GPU emulieres HD-Gerät
vdr[1525]: segfault at 0 ip 00007fe41fc0a9bb sp 00007fff50f5c6b0 error 4 in libc-2.21.so[7fe41fb14000+19a000]
Dec 21 21:36:24 Intel-NUC systemd[1]: vdr.service: Main process exited, code=killed, status=11/SEGV
Dec 21 21:36:24 Intel-NUC systemd[1]: Failed to start Video Disk Recorder.Und daß das ein paar mal hintereinander erfolgt, daß ist das Ergebnis des VDR Startscriptes, welches nach Absturz des VDR s
ogleich versucht ihn wieder zu starten ...
Frage: Wie komme ich nun mit dem Absturz in der libc weiter? (Sonst bei Aufruf aus einer Konsole mit Root-Rechten klappt es ja.
Bei einer Konsole mit User Rechten war glaube ich der gleiche Absturz. Muß gleich noch mal nachschauen.) Kann das die X-Server
Geschichte sein, daß der XServer die Zugriffe von dem User vdr ablehnt?
p.s. Auch in einer User-Console stürzt der VDR mit obiger Fehlermeldung ab: "error 4 in libc-2.21.so[7fe41fb14000+19a000]".
Ein sudo davor, und der VDR startet (zwar bleibt das Bild schwarz, aber der Ton ist da. Ein Channel up/down und man hat
auch Bild und Ton) ...
m.f.G.
Michael