Posts by minixjr

    OK, offensichtlich bin ich doof.

    Versuche ich es jetzt also so:

    Code
    1. //vdr:000:0 = S19.2E-1-1078-28676
    2. tvm:14:2 = S19.2E-1-1078-28676
    3. tvsp:CC:1 = S19.2E-1-1078-28676

    Wenn es keinen Eintrag mit 0 gibt, ist Mischen aktiv!?

    Dann werden die Daten von 1 verwendet und wenn nichts gefunden wird von 2.

    Hab ich's jetzt verstanden?

    Vielleicht verstehe ich die Frage nicht, aber ich dachte ich hätte genau das im 1sten Post geschrieben.

    Solange nur EPG-Daten von epgData vorhanden sind, werden die Timer angelegt, aber sobald EPG-Daten über DVB vom Sender kommen, werden die Timer wieder gelöscht.

    Vom Sender kommt der Titel "That '70s Show", das dürfte das Problem sein.


    Aktuell habe ich in der channelmap.conf folgendes eingestellt:

    Code
    1. vdr:000:0 = S19.2E-1-1078-28676
    2. tvm:14:2 = S19.2E-1-1078-28676
    3. tvsp:CC:1 = S19.2E-1-1078-28676

    Damit kommen jetzt keine DVB Daten mehr.

    Der nächste (Auto)Timer ist für Montag programmiert, also Daumendrücken ;)

    Bei mir liefert

    Code
    1. epgd-showmerge S19.2E-1-1078-28676

    Also kommt der englische Titel über DVB, obwohl ich im VDR Sprache Deutsch eingestellt habe.

    Code
    1. EPGLanguages = deu


    Jemand eine Idee?

    Ich werde es mal nur mit tvsp und tvm probieren.


    Hat zwar nichts direkt mit deinem Eingangsposting zu tun, aber soweit ich weiß, gehen nur zwei Einträge pro Sender in der channelmap.conf.

    So wie ich das hier verstehe LINK, ist 0 bis 2 zulässig.

    Was meinst Du mit Quelldaten?

    Die epgdata sind OK, im übermittelten file steht "Die wilden Siebziger".

    Ich habe auch schon versucht die Priorität der vdr Daten zu reduzieren, leider ohne Erfolg.

    Code
    1. // 'Comedy Central/VIVA'
    2. vdr:000:2 = S19.2E-1-1078-28676
    3. tvm:14:1 = S19.2E-1-1078-28676
    4. epgdata:532:0 = S19.2E-1-1078-28676

    Vielleicht liefert der HD Sender aber auch die richtigen Daten. Die HD Version habe ich aber nicht.


    Wie kann ich verifizieren welche Daten über dvb kommen?

    Hallo zusammen,


    habe gerade ein Problem mit dem epg von Comedy Central.

    Ich würde gern die Serie "Die wilden Siebziger" aufnehmen, leider funktioniert dies nicht mehr.

    epgd programmiert brav die Timer im Voraus (Daten von epgdata), solange es noch kein epg über dvb gibt, aber ca. 2-3 Tage vor der Aufnahme werden die Timer wieder gelöscht.

    Soweit ich das sehe liefert CC über dvb den Titel "That '70s Show" was nicht zu den Daten von epgdata passt, das Mergen also nicht funktioniert.

    Kann man sowas irgendwie korrigieren?

    Vielleicht per SQL und einem cron-Job, "update ... SET titel ... where ..."?

    Bin ratlos.


    Gruß

    minixjr

    Das Fernbedienungsproblem von Frodo erinnert mich stark an diese beiden Beiträge und mein eigenes Problem.

    yavdr-ansible-zweite-fernbedienung-mceusb-wird-nicht-richtig-eingebunden

    mce-remote-mit-1804-ansible-verhält-sich-komsich

    Für mich habe ich es mit der System-Unit gelöst.

    Zum Einen wird das richtige Protokoll eingestellt und zusätzlich die Lirc-Module entladen, da sie trotz Blacklist nach jedem Reboot wieder aktiv sind.

    Natürlich nur ein Workaround, aber für mich funktioniert es.

    Das eigentliche Problem erkenne ich leider nicht :(

    set-mce-remote-protocol.service

    Ich habe nur einen Empfänger, e scheint also nicht zwingend etwas mit der Anzahl der Empfänger zu tun zu haben.

    Ich nutze Bus 002 Device 003: ID 0471:0815 Philips (or NXP) eHome Infrared Receiver

    Diablo ,

    ich nehme an,

    Quote

    Das Skript was ich hier gefunden hatte war wohl eher für einen Headless Server gedacht.

    bezog sich auf meine Rolle LINK

    Bei dem headless ging es mir eigentlich nur um die fehlende Konfiguration der Fernbedienung. Darüber hatte ich mir keine Gedanken gemacht, weil ich sie
    nicht benötige und nicht getestet habe.

    Anbei ein Update der Rolle, funktioniert bei mir auf zwei Rechnern ohne Probleme.

    autoinstall-sundtek-static_V3.tar.gz

    Als Hinweis, eine vorhandene udev-Regel 80-mediasrv-sundtek.rules wird überschrieben, da die alten Versionen mit --start=5 nicht zuverlässig funktionieren, siehe auch LINK


    Ja, funktioniert, habe es mit dem ersten Rechner aus meiner Signatur probiert.

    Besten Dank.

    Code
    1. TASK [yavdr-xorg : check /etc/yavdr/autoinstalled if a nvidia driver has been installed]
    2. changed: [yavdrbox] => {"backup": "", "changed": true, "found": 1, "msg": "1 line(s) removed"}
    3. TASK [yavdr-xorg : set_fact | nvidia_driver_installed]
    4. ok: [yavdrbox] => {"ansible_facts": {"nvidia_driver_installed": true}, "changed": false}

    Hallo seahawk1986 ,


    Du hast in der Rolle yavdr-xorg im task detect-xorg.yml eine Prüfung hinzugefügt, ob ein NVIDIA Treiber installiert ist.

    Leider funktioniert diese Prüfung nur lokal und nicht wenn ich die Installation remote ausführe.

    Bei mir habe ich folgende Änderung vorgenommen.

    Damit läuft es durch, bin mir aber nicht sicher ob die Umsetzung so ganz korrekt ist.

    @Morpheus1607,

    ich vermute Du versuchst die main.yml direkt auszuführen?

    Das geht tatsächlich nicht.

    Das Vorgehen sollte wie folgt sein:

    - die Rolle entpacken nach yavdr-ansible/roles/

    - bei einer Standardinstallation die Rolle vdr-mounter der Datei yavdr07.yml im Bereich roles:am Ende hinzufügen.

    Code
    1. ...
    2. - wakeup # set up wakeup methods for rtc etc.
    3. - grub-config # configure grub
    4. - vdr-mounter
    5. ...

    - die Installation mit ansible-playbook yavdr07.yml -b -i 'localhost_inventory' --connection=local --tags="vdr-mounter" starten


    Das sollte es gewesen sein.

    Viel Erfolg.

    Ich hatte etwas Schwierigkeiten mit meinem Sundtek USB Stick.

    Bei ca. jedem zweiten Neustart wurde er nicht eingebunden, weil der sundtek.service auf die Bretter gegangen ist.

    Nach nun 5 von 5 erfolgreichen Starts, gehe ich von einer fehlerhaften udev Regel, bzw. einem Fehler im Programm /opt/bin/mediaclient aus.

    Leider kann ich aktuell nicht mehr nachvollziehen wie die Regel ihren Weg auf meinen Rechner gefunden hat, habe aber das Paket dvb-driver-sundtek in Verdacht.

    Die Regel sah wie folgt aus:

    SUBSYSTEM=="usb", ACTION=="add", RUN+="/opt/bin/mediaclient --start=5 --systemdcheck"

    Vermutlich wird --start=5 vor --systemdcheck ausgeführt und dann hat der Systemd Service ein Problem Start request repeated too quickly

    Ich habe das --start=5 aus der Regel entfernt, seitdem startet der Service (5 von 5).

    Heißt natürlich noch nichts. Werde es beobachten.

    seahawk1986 , habe mal getestet.

    Ich habe die Variable übergeben

    Code
    1. vdr_svdrphosts:
    2. - 192.168.64.0/24

    Die xineliboutput/allowed_hosts.conf wurde bearbeitet und das Subnetz eingetragen.

    An der xineliboutput.conf hat sich nichts geändert

    Der Download der Channels.conf hat funktioniert.

    Mit der Variablen vdr_allowed_hosts (das ist standardmäßig eine leere Liste) kann man das für alle Dateien ausrollen, die einen IP-basierten Zugriff verwalten, und wie im Commit beschrieben auch gezielt für einzelne Dienste/Plugins übersteuern.

    Hört sich gut an, ich glaube nur für xineliboutput ist noch eine zusätzliche Variable notwendig.

    In xineliboutput.conf soll das Interface angegeben werden auf dem gelauscht wird und in der allowed_hosts.conf sollen "externe" Adressen oder Bereiche angegeben werden.

    Oder, wenn das geht: Wenn die Variable xineliboutput_allowed_hosts einen Wert hat, dann in der xineliboutput.conf keine <LOCALIP> eintragen.

    Wenn xineliboutput_allowed_hosts definiert ist, kann man wohl davon ausgehen, dass Zugriff von extern gewünscht ist.


    Weiter Plugins fallen mir im Moment nicht ein.

    Alles klar, so tief stecke ich da nicht drin.

    Bleibt also nur die Variante über die ansible Variablen, vdr_svdrphosts und weitere.

    Ich nehme mal an Lars hatte Bedenken, dass hier ungewollte Services freigegeben werden.

    Ich würde eher dafür plädieren, dass es per default so bleibt, und wenn man remote darauf zugreifen will, muss man es konfigurieren.


    Lars

    Aus dieser Sicht wäre es vielleicht besser die Option --remote in der xineliboutput.conf wegzulassen, dann kann ich den Remotezugriff über OSD aktivieren (mal abgesehen von allowed_hosts.conf).


    Oder per ansible eine Variable abfragen und wenn sie existiert, den Inhalt als <LOCALIP> eintragen.


    Gruß

    Frank