Posts by VdrMize

    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:


    Quote

    Benö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?

    • Woher kommt die Aussage, der NUC-12 benötigt den Intel-Media-Treiber?
    • Gibt es vaapi (noch) nicht für Alder-Lake (NUC-12),oder gibts das nie?
    • Oder unterstützt softhddevice mittlerweile auch den Intel-Media-Treiber?

    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?

    • Wird das softhddevice nur vom VDR als Ausgabe genutzt, sozusagen als Ersatz
      für das xineliboutput-sxfe Plugin und das sxfe Ausgabefenster?
    • Kann man das Ausgabefenster des Softhd-Devices schließen, während VDR
      läuft und etwas aufnimmt, man aber surfen oder Bilder ansehen möchte?
    • Hat sich jemand die Mühe gemacht, den ganzen vaapi Source Stapel in das
      SoftHdVaapi zu integrieren, oder ist das vaapi unten drunter schon noch nötig?
    • Braucht man das softhddrm nur wenn man verschlüsselte Sender empfangen
      möchte, und ein CI Interface nutzt, oder ist das auch für Standard HD Sender
      die nicht verschlüsselt übertragen werden nötig?

    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.

    • Jetzt weiß ich nicht, ob ich mit xineliboutput-sxfe auf dem richtigen Weg bin,
    • oder ob ich lieber auf softhddevice mit vaapi umsteigen soll,
    • und ob das auf meinem NUC-10 (bzw. dem neuen NUC-12) sauber laufen wird.
    • Vielleicht nutzt man auch mittlerweile ganz etwas anderes ???

    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:

    • OS: Debian GNU/Linux 11 (bullseye) x86_64
    • Host: NUC10i5FNH K61160-306
    • Kernel: 5.10.0-18-amd64
    • Resolution: 1920x1080
    • CPU: Intel i5-10210U (8) @ 4.200GHz
    • GPU: Intel CometLake-U GT2 [UHD Graphics]
    • Memory: 597MiB / 15721MiB

    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

    • OS: Debian GNU/Linux 11 (bullseye) x86_64
    • Host: NUC12WSHi5 M46655-302
    • Kernel: 5.10.0-18-amd64
    • Resolution: 1920x1080
    • DE: LXDE / Openbox / Adwaita [GTK3]
    • CPU: 12th Gen Intel i5-1240P (16) @ 5.600GHz
    • GPU: Intel Device 46a6
    • Memory: 368MiB / 15585MiB

    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) ...


    • Kann mir einer der Spezialisten sagen, ob Squeeze da auf einem alten 0.6.0 stehengeblieben
      ist, den ich im Prinzip vergessen kann, oder ob da in dem git Stand die Patches von Anti und
      co. Einzug gehalten haben (und in den letzten 1-2 Jahren nichts großes dazu gekommen ist)?
    • Falls nicht, bei ca. 350 Unterschieden in 10 Files die mir mein Editor beim Diff findet, macht es
      wahrscheinlich keinen Sinn, das groß zu patchen, sondern eher zu versuchen die 10 unter-
      schiedlichen Files gleich komplett auszutauschen, oder?
    • Und woran mag es liegen, daß ich da immer diese HW-Accelerator Fehler bekomme (alle 1-2
      Sekunde bricht das Bild zusammen und baut sich dann grob Klötzig wieder zusammen ...

    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) ...

    • Wenn ich mit ir-keytable -t beim längeren Druck auf eine Taste auch Repeat Tastendrücke
      erkenne (mehrfache scancodes, aber nur einen key-down und key_up), später dann mit irw
      nur einen einzelnen Tastendruck angezeigt bekomme, wo kann ich da weiter suchen?
    • Die zweite Frage ist (ohne damit jetzt einen Glaubenskrieg entfachen zu wollen): als ich
      vor ca. 1-2 Jahren von meinem 5-10 Jahre altem VDR (mit Linux aus dieser Zeit) auf meine NUC´s
      (und aktuellem Linux) umgestiegen bin, hab ich lange nachgelesen wie ich lirc neu aufsetzen soll.


      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 ...


    • Frage: sind aktuell Umbauten an lircinput bekannt, die das erklären?


    Nach etwas Analyse des Problems sehe ich folgendes Verhalten:


    • (nach Anhalten von inputlirc) bekomme ich mit ir-keytable -t Tastendrücke der Fernbedienung angezeigt.
      Wenn ich länger Drücke bekomme ich auch Repeat Tastendrücke zu sehen, also bis hier geht alles perfekt ...
    • (nach erneutem Start von inputlirc) bekomme ich die Tastendrücke auch mit irw angezeigt.
      Dazu mußte aber nach Rechner Hochlauf inputlirc einmal gestoppt und wieder gestartet sein ...
      (Hier muß ich später weitersuchen, warum der Tastenrepeat der Fernbedienung nicht geht; auch bei längerem
      Drücken der FB zeigt irw immer nur eine einmalig gedrückte Taste ...)
    • Wenn ich danach den VDR starte, läßt sich dieser auch wieder über die FB bedienen. Wenn ich nach Reboot
      des Rechners VDR stoppe, inputlirc restarte und VDR wieder starte, läßt sich VDR ebenfalls wieder mit FB bedienen.


    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


    Code
    vdr-sxfe --verbose --video=vaapi --audio=alsa


    bekomme ich ständig Zeilen mit


    Code
    [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 Picture


    Ansehen einer HD-Aufzeichnung (von BR3) mit ...

    • vdr-sxfe --verbose --video=vaapi --audio=alsa
      =>Klötzchen im Bild, obige Fehler, nur ca. 7% Prozessorauslastung (VA-API arbeitet, aber nicht korrekt)


    • vdr-sxfe --verbose --video=opengl2 --audio=alsa
      => das Bild ist scharf und deutlich, aber 70% Prozessorauslastung (VA-API wird nicht genutzt)


    • Anzeige der VDR Aufzeichnung mit VLC-Player und VA-API (Keine Bildstörung!!!)
      => scharfes und deutliches Bild, 7% Prozessorauslastung, VA-API arbeitet korrekt)


    Ich weiß jetzt nicht, wie ich den Fehler weiter eingrenzen kann.

    • Linux System (Debian Stretch 64 Bit), Installation VA-API, USB DVB-C Eingang läuft ja schon mal,
      sonst würde ich keine funktionierende VDR-Aufzeichnung hinbekommen ...


    • Den Fehler im vdr-sxfe / xineliboutput Plugin vermuten?
      Vielleicht, wird ja nur noch selten genutzt, ist vielleicht nicht gut auf VA-API abgestimmt
      Doch wie soll/kann ich hier weiter suchen?


    • Den "[h264] hardware accelerator failed to decode Picture" Fehler weiter verfolgen?
      Kommt der bei anderen Anwendern auch häufiger vor? (So ca. 5 Fehler in etwa im Sekundenrhytmus,
      könnte von der Abfolge mit den Klötzchen zusammenhängen; in 4 sec. 20 Fehler, und die Meldung
      von 200 Frames delivered 16 Frames skipped)


    • An den Einstellungen vom Light-DM Fenstermanager herumbasteln (gibt ja 1000 Optionen ...)?
      Aber wenn´s mit OpenGL läuft, ist das vielleicht nicht die Ursache ... ?


    • Läßt sich dem VDR-sxfe sagen, welche Teile er über VA-API machen soll, und welche nicht
      (z.B. weil gewisse nachträgliche Bildoptimierungen im VA-API vielleicht nicht korrekt laufen?


    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:

    • es fehlt das Fenster von softhddevice (ich bekomme beim automatischen Start des VDR auch wenn
      das softhddevice Plugin geladen wird (laut syslog) keine Ausgabe von Bild oder Ton (evtl. muß ich
      dem X-Server noch mit xhost sagen, daß er den VDR User akzeptieren soll ...)


      => wie kann ich softhddevice dazu bringen, bei Fehlern etwas in´s Log zu schreiben???


    • beim manuellen Starten von VDR ist manchmal der Bildschirm dunkel (aber der Ton läuft). Ich muß
      erst den Kanal wechseln, bevor auch ein Bild kommt ...

    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 ...


    Code
    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