Beiträge von seahawk1986

    ENV{ID_VENDOR_ID}=="147a", ENV{ID_MODEL_ID}=="e016", \

    ENV{eventlircd_enable}="true", \

    ENV{eventlircd_evmap}="mce.evmap"

    Die mce.evmap würde ich nicht laden lassen (weil man für rc-core Empfänger eine eigenen Keymap hinterlegen kann und du außerdem ein anderes Protokoll nutzen willst), der Eintrag sollte dann also so aussehen:

    Code
    1. ENV{ID_VENDOR_ID}=="147a", ENV{ID_MODEL_ID}=="e016", \
    2. ENV{eventlircd_enable}="true"

    Dann hast du mit der TTS35AI - soweit ich das in älteren Beiträgen gefunden habe - eine Fernbedienung mit einem RC-5 extended Protokoll.

    Das kannst du so überprüfen:

    Code
    1. sudo stop eventlircd
    2. sudo ir-keytable -c -p RC-5
    3. sudo ir-keytable -t # jetzt solltest du für jede Taste auf der Fernbedienung einen eindeutigen Scancode sehen können

    Die Scancodes ordnest du dann in einer keymap den für yaVDR vorgesehenen Tastennamen zu. Die erste Zeile der Datei sollte dabei so aussehen (und danach folgen Scancode und Tastenname wie in https://www.yavdr.org/document…html#_scancodes_ermitteln ff. beschrieben):

    Code: /etc/rc_keymaps/TTS35AI
    1. # table rc-rc6-mce, type: RC5

    Du kannst die Keytable zum Testen so laden lassen: sudo ir-keytable -w /etc/rc_keymaps/TTS35AI und danach eventlircd starten sudo start eventlircd - jetzt solltest du den VDR und KODI mit der Fernbedienung steuern können.


    Und damit die Keytable beim Start automatisch geladen wird, musst du in der /etc/rc_maps.cfg noch eine Regel (möglichst am Anfang der Datei) einfügen:

    Code
    1. mceusb rc-rc6-mce /etc/rc_keymaps/TTS35AI

    Würde mich freuen von dir zu hören ... - habe jetzt parallel mal nen RPI3 mit MLD 5.4 gestartet und nochmals das Zapping verhalten bei den SK* Kanälen verglichen das ist das bekannte Problem ...

    Ich habe gerade mal die Patches verglichen - die sind bei yaVDR und der MLD praktisch identisch (bis auf eine Präprozessor-Anweisung, die einen zusätzlichen von der VDR-Version abhängigen Patch vermeidet, den die MLD nutzt und ein bisschen Whitespace). Warum es damit auf den Raspberrys funktioniert und auf ausgewachsenen PCs nicht, weiß ich nicht, eventuell sind die Raspberrys (meistens) langsam genug, dass es zufällig funktioniert.

    Ich habe yavdr-base gerade aktualisiert, damit das Skript beim Starten nicht mehr darüber stolpert, wenn die Datei leer ist. Die Logdateien in /var/log/upstart/ kannst du gerne abräumen, wenn die dir zu groß sind, die werden wieder neu angelegt, wenn von Upstart gestartete Jobs etwas auf stdout oder stderr ausgeben.

    Hast du die Konfigurationsdatei für vaapidevice schon wie beschrieben angepasst? Dann musst du vermutlich noch mit dem pulsecontrol-Plugin die Audio-Ausgabe auf den gewünschten Ausgang verschieben.

    Wie ist denn der X-Server aktuell eingestellt? xrandr -d :0.0


    Wenn du magst kannst du auch mal vaapidevice statt softhddevice probieren (vdr-plugin-vaapidevice installieren, vdr-plugin-softhddevice mit vdrctl deaktivieren oder das Paket deinstallieren).


    Die Konfigurationsdatei dafür müsste in etwa so aussehen:

    Code: /etc/vdr/conf.avail/vaapidevice.conf
    1. [vappidevice]
    2. -a pulse
    3. -d :0.0
    4. -D
    5. -w alsa-driver-broken

    Kannst du mal die /var/log/upstart/vdr-frontend.log löschen, softhddevice als Frontend wählen, den Rechner neu starten und dann schauen, ob und was da geloggt wird?

    Und nachdem vdr.conf: vdr is ready ins Syslog geschrieben wurde bitte mal mit initctl list nachsehen, welche Dienste da welchen Status haben.

    Das soll ein reiner Streaming Client werden - daher ist STreamdev- Client geladen - und den würde ich gerne per OSD Konfigurieren ... - Aber ich bekomme wie schon gesagt auch kein OSD.

    Ausschließlich nicht-empfangbare Kanäle in die channels.conf zu stecken kann mit dem VDR 2.4.0 Probleme machen - wenn du unbedingt über das VDR-OSD gehen willst, würde ich die Reihenfolge umdrehen und erst streamdev konfigurieren und später die Kanalliste hinzufügen, ansonsten ist es vermutlich einfacher die zwei Zeilen für die setup.conf von einem anderen Client zu kopieren.

    Die Fehlermeldung wegen VDPAU kommt, wenn softhddevice die Videodecoder selbst durchprobiert (man kann den Videodecoder auch fest in der /etc/vdr/conf.avail/softhddevice.conf setzen). Aber er scheint ja erfolgreich VAAPI zu initialisieren.


    Wie kommt der VDR an das DVB-Signal? Im Log (journalctl -u vdr -l) müsste man sehen können, ob und welche DVB-Devices sich der VDR beim Start greift.


    Ansonsten hätte ich noch die Frage, ob du das Alternative Server Image genommen hast (wie in der README angegeben) oder das "normale" Ubuntu Server Image genommen hast, das die cloud-init-tools installiert - mit dem kommt beim Starten kein yaVDR-Bootsplash und die Video-Ausgabe funktioniert nicht richtig.

    Es gibt sogar ein Blick in die Zukunft. Heute ist der 10.01. In den Zeilen 1337 bis 1339 gibt es Einträge vom 11.01.


    Und außerdem, warum plötzlich in Zeile 1347 noch mal ein Eintrag von gestern erscheint.

    Könnte was mit der Zeit nicht stimmen?

    Das ist ein recht großer Sprung in der Zeitsynchronisation durch ntp:

    Code
    1. Jan 9 17:34:04 HTPC ntpdate[1892]: step time server 91.189.89.199 offset -72717.744280 sec

    Eventuell ist die Batterie auf dem Mainboard leer.

    Ich komme ja auch über das Webinterface auf das System. So habe ich gemerkt, dass sämtliche Einstellungen weg sind.

    Kannst du da noch mal nach Bildschirmen suchen lassen, dann die richtige Auflösung und Bildwiederholrate (50Hz) einstellen und bei den Frontends softhddevice auswählen? Eventuell gibt es da Folgeprobleme von der Zeitspanne als die Festplatte vollgelaufen ist, die sich durch erneutes expandieren der Templates für die Konfiguration des X-Servers und das Frontend beheben lassen. Ich sehe im von dir geposteten Log z.B. nichts vom vdr-frontend Skript, das softhddevice attachen sollte.

    Der VDR bietet die Möglichkeit Befehle nach erfolgter Aufnahme auszuführen: https://projects.vdr-developer…vdr.git/tree/INSTALL#n264

    Du kannst eigene Befehle in der /etc/vdr/recording-hooks/R90.custom eintragen. Beim Start des VDR wird ein Skript aufgerufen, dass die recording-Hooks aus den Verzeichnissen in ein Skript für den VDR zusammenfasst.


    PS: Ich habe das Paket für naludump und das vdr-addon-naludump aus yaVDR 0.5, das über Recording-Hooks automatisch nach der Aufnahme über die Dateien läuft mal nach experimental-main hochgeladen.

    Hast Du die Bildwiederholfrequenz überprüft? yavdr-ansible stellt gerne mal 60Hz ein, was zu Problemen führt..

    Seit Dienstag Abend sollte er auch mit Intel-Grafik 50 Hz vorkonfigurieren (davor hat er nur für nvidia-Grafikkarten die xorg-Konfiguration angepasst), wenn der Monitor in seiner EDID einen passenden Mode hat. Schau mal in die /etc/X11/xorg.conf.d/20-intel.conf, was da erkannt wurde. Dort kann man auch eigene Modelines und den gewünschten Mode setzen.

    - bei ca. 30% aller Sender flimmert es ganz oben im Bild - ca 1% vom Bildschirm - das kenne ich nicht von den RPI´s... - wenn man genau schaut auch ganz unten - und wenn man ganz genau schaut flimmert das ganze bild irgendwie - muss ich bei YAVDR nirtendwo die Auflösung konfigurieren ?

    Das könnte am Deinterlacer oder am Teletext liegen. Beim Raspberry Pi musste ich immer die oberste (und unterste) Zeile vom Bild abschneiden lassen, damit das nicht störend auffällt.

    - Wo kann ich in yavdransible das Aufnahme Verzeichniss ändern ?

    yavdr ansible