Posts by Negge

  • [yaVDR-Ansible] "Umfrage" Bootzeiten ...

    Hardware: Intel DH77KC, Celeron G1610, 8GB RAM, 2x 5TB HDD, 2x WD 2TB HDD; 1x 64 GB SSD (root), System Ubuntu 18.4 / YaVDR ansible headless

    Code
    Startup finished in 3.274s (kernel) + 1min 33.453s (userspace) = 1min 36.727s
graphical.target reached after 1min 33.442s in userspace

  • Yavdr ansible und igorPlug-USB

    Hi, ich hab aufgegeben und es jetzt anders gelöst. Das Image von YaVDR0.5 läuft jetzt wieder auf dem Client. Geht und ist weniger gefrickel. Nur der Server ist jetzt neu (vor allem wegen dem EPG-Daemon). Trotzdem danke für die Hilfe.

  • Yavdr ansible und igorPlug-USB

    Hi,

    danke nochmal für deine Hilfe.


    Code
    irw /var/run/lirc/lircd-lirc0
Cannot connect to socket /var/run/lirc/lircd-lirc0: Connection refused


    root@q150:~# irw /var/run/lirc/lircd --> läuft, aber kann ich Tasten drücken wie ich will, passiert nichts. Mit Strg-C abbrechen.


    Zudem habe ich im Aufruf von vdr-sxfe bisher immer den Parameter --lirc=/var/run/lirc/lircd-lirc0 mitgegeben. Jetzt habe ich das gerade mal ohne den Parameter probiert, aber die Fernbedienung funktioniert dennoch so fehlerhaft wie oben beschrieben --> Also offenbar nicht über diesen Lirc-Socket?



    --------


    Zudem ist mir nach dem Reboot aufgefallen, dass die Fernbedienung direkt nach dem Reboot doch nicht direkt funktioniert. Die Keytable wird zwar geladen, aber wohl nicht richtig?!?. Erst nach einem ir-keytable -w /etc/rc_keymaps/igorplugusb geht sie (hatte ich vermutlich beim rumtesten dann immer mal gemacht). In der /etc/rc_maps.cfg steht igorplugusb rc-hauppauge /etc/rc_keymaps/igorplugusb drin. Und nach dem booten gibt

    nach dem ir-keytable -w /etc/rc_keymaps/igorplugusb wird offenbar das Protokoll RC-5 aktiviert?



    Naja, weitere/andere Baustelle mit dem automatischen laden des RC-5-Protokolls, erstmal müssetn die Tastendrücke auch richtig an den VDR weitergeben werden...

  • Yavdr ansible und igorPlug-USB

    Hi,


    die Ausgabe von "lsusb -v" liefert für das Device:

    Nach umbennen von

    /lib/udev/rules.d/98-lircd.rules in /lib/udev/rules.d/98-lircd.disabled

    wird die Fernbedieung initialisiert und funktioniert: Teilweise, so wie oben beschrieben. Es werden nicht alle Tasten an den VDR uebermittelt.



    Mit ir-keytable -t hab dann nochmal die erkannten Codes der Fernbedienung getestst:


    Bsp.: an VDR übermittelte Taste "vol+"

    Code
    root@q150:~# ir-keytable -t
Ereignisse werden getestet. Bitte drücken Sie STRG-C, um abzubrechen.
840.245755: Ereignistyp EV_MSC(0x04): Scancode = 0x1e10
840.245755: Ereignistyp EV_KEY(0x01) key_runter: KEY_VOLUMEUP(0x0073)
840.245755: Ereignistyp EV_SYN(0x00).
840.512029: Ereignistyp EV_KEY(0x01) key_hoch: KEY_VOLUMEUP(0x0073)
840.512029: Ereignistyp EV_SYN(0x00).
^C

    Bsp.: an VDR NICHT übermittelte Taste "Ch+"

    Code
    ir-keytable -t
Ereignisse werden getestet. Bitte drücken Sie STRG-C, um abzubrechen.
947.899349: Ereignistyp EV_MSC(0x04): Scancode = 0x1e20
947.899349: Ereignistyp EV_KEY(0x01) key_runter: KEY_CHANNELUP(0x0192)
947.899349: Ereignistyp EV_SYN(0x00).
948.156031: Ereignistyp EV_KEY(0x01) key_hoch: KEY_CHANNELUP(0x0192)
948.156031: Ereignistyp EV_SYN(0x00).
^C


    Weitere beobachtungen:


    Bei Taste Play hält der VDR das Live-Signal an ? (als ob Taste Pause gedrückt wurde):

    Code
    1123.188103: Ereignistyp EV_KEY(0x01) key_runter: KEY_PLAY(0x00cf)
1123.188103: Ereignistyp EV_SYN(0x00).
1123.314113: Ereignistyp EV_MSC(0x04): Scancode = 0x1e35
1123.314113: Ereignistyp EV_SYN(0x00).
1123.580038: Ereignistyp EV_KEY(0x01) key_hoch: KEY_PLAY(0x00cf)
1123.580038: Ereignistyp EV_SYN(0x00).

    Auf die Taste Pause reagiert der VDR nicht:

    Code
    1209.688127: Ereignistyp EV_MSC(0x04): Scancode = 0x1e30
1209.688127: Ereignistyp EV_KEY(0x01) key_runter: KEY_PAUSE(0x0077)
1209.688127: Ereignistyp EV_SYN(0x00).
1209.779066: Ereignistyp EV_MSC(0x04): Scancode = 0x1e30
1209.779066: Ereignistyp EV_SYN(0x00).
1210.044036: Ereignistyp EV_KEY(0x01) key_hoch: KEY_PAUSE(0x0077)
1210.044036: Ereignistyp EV_SYN(0x00).

    Und die Taste Exit/back auf der Fernbedienung beendet das vdr-sxfe-frontend wie auf die "ESC"-Taste auf der Tastatur (Ich hab den Client im Testbetrieb inzwischen wierder so eingerichtet, dass der Client greift per VDR-SXFE auf den den VDR auf dem VDR-Server zugreift).

    Code
    root@q150:~# ir-keytable -t
Ereignisse werden getestet. Bitte drücken Sie STRG-C, um abzubrechen.
1248.368002: Ereignistyp EV_MSC(0x04): Scancode = 0x1e1f
1248.368002: Ereignistyp EV_KEY(0x01) key_runter: KEY_ESC(0x0001)
1248.368002: Ereignistyp EV_SYN(0x00).
1248.636047: Ereignistyp EV_KEY(0x01) key_hoch: KEY_ESC(0x0001)
1248.636047: Ereignistyp EV_SYN(0x00).

  • Yavdr ansible und igorPlug-USB

    Hallo Seahawk,


    noch mal danke für die Hilfe, ich habe das so gemacht wie von Dir vorgeschlagen. Bin erst jetzt dazu gekommen weiter zu testen, und funktioniert leider nicht?!?


    Wenn ich mittels systemctl mask --runtime --now eventlircd.{socket,service} eventlirc maskiere, dann geht's wie oben beschrieben (nicht alle Tasten werden erkannt) . systemctl mask --now lircd.{socket,service} hatte ich vor einem Reboot ebenfalls ausgeführt, also müsste lircd ja auch maskiert sein? Bring auch nichts wenn ich ein systemctl mask --runtime --now lircd.{socket,service} mache, es werden immer noch Signale von der Fernbedienung erkannt.


    Es gibt übrigens eine Datei "/var/run/lirc/lircd-lirc0" . Hat die damit was zu tun?


    Ich hab ansonsten noch einsystemctl mask --now eventlircd.{socket,service} probiert und rebootet, nach dem Reboot geht die Fernbedienung nicht, auch nicht mehr nach einem ?systemctl mask --runtime --now eventlircd.{socket,service} wie zuvor?!? Jetzt braucht es erst wieder ein ir-keytable -w /etc/rc_keymaps/igorplugusb -t, dann geht die FB am VDR wieder???

  • Yavdr ansible und igorPlug-USB

    Hallo Seahawk,


    nochmal danke für die Hilfe. Also ich habe die entsprechende rc-Keymap nach deiner Anleitung erzeugt:

    cat /etc/rc_keymaps/igorplugusb


    und in /lib/udev/rules.d/98-lircd.rules habe ich auch die 2 Zeilen

    Code
    #SUBSYSTEMS=="rc", \ 
#ENV{eventlircd_enable}="true"

    auskommentiert, damit udev den nicht zuordnet.


    Nach dem Reboot hat der VDR auf die FB-Signale dennoch nicht reagiert.


    Ich hab dann nochmal getestet:

    sudo su

    systemctl mask --runtime --now eventlircd.{socket,service}

    ir-keytable -w /etc/rc_keymaps/igorplugusb -t


    An der ssh-Konsole kann ich erkennen, dass er die Tastendrücke zuordnet , am TV kann ich allerdings erkennen, dass der VDR nur auf einige Tastendrücke reagiert (Zahlen 1-9, hoch, runter, rechts, links, VolUp/Down, ).Allerdings nicht: OK, Back, Menu, ChanUp/Down an der Fernbedienung nicht funktioniert (nur Tastatur).

    ir-keytable -w /etc/rc_keymaps/igorplugusb -t



    Code
    cat /etc/rc_maps.cfg | grep igor

igorplugusb    rc-hauppauge    /etc/rc_keymaps/igorplugusb

  • Yavdr ansible und igorPlug-USB

    Hallo seahawk1986, danke für deine Antwort. Folgendes Resultat:


    Code
    /sys/class/rc/rc0/ gefunden (/dev/input/event3) mit:
        Name: IgorPlug-USB IR Receiver
        Treiber: igorplugusb, Tabelle: rc-hauppauge
        Lirc Gerät: /dev/lirc0
        unterstützte Protokolle: lirc rc-5 rc-5-sz jvc sony mce_kbd rc-6 sharp xmp
        Aktivierte Protokolle: lirc
        bus: 3, Anbieter/Produkt: 03eb:0002, Version: 0x0001
        Wiederholungsverzögerung = 500 ms, Wiederholungsperiode = 125 ms


    Scheint also irgendwie erkannt zu werden?

  • Yavdr ansible und igorPlug-USB

    Hallo,


    ich musste yaVDR05 nach Jahren problemlosen betriebes updaten, vieles funktioniert auch schon, aber z.B. funktioniert die Fernbedienung noch nicht und ich komme da nicht weiter. Der Igor-USB wird erkannt, die lirc.conf der Fernbedienung vom alten VDR ist unter /etc/lirc/lircd.conf.d gespeichert. Leider funktioniert es nicht....


    dmesg | grep igor:

    ?!?

  • Magnetschalter für 220V oder andere Lösung?

    Oder wie schon vorgeschlagen "mechanisch" und ohne Löten wäre der hier http://www.pollin.de/shop/dt/N…Endschalter_XZ_8_108.html oder der hier http://www.pollin.de/shop/dt/N…Endschalter_XZ_8_112.html . Kabel rein, anklemmen und gut...


    Der Endschalter XZ-8/112 ist ip64, aber das Gummi um den Stößes vorn sollte man hin und wieder mit Silikonspray bearbeiten, sonst wird der etwas hakelig. Wenn man den geschützt (z.B. im Haus) irgenwo montiert, kann man das Gummi um den Stößel auch ein wenig wegschneiden, dann reagiert der deutlich flinker (z.B. Als Türkontakt für Licht in einem Abstellraum, Dachboden... )

  • Paar kleine Streaming Probleme

    Soll denn die Aufnahme auf dem Server oder auf dem Client laufen? Wenn auf dem Client, dann landen die Aufnahmen natürlich auf der HDD vom Client und dieser muss genug Tuner vom Server zur Verfügung gestellt bekommen, wie von Seahawk erwähnt. Wenn der Server sich darum kümmmern soll, braucht man am Client soweit ich mich entsinne das plugin extrecmenu, um am client das externe recoding-menu vom server einzubinden (Server Timer).
    Hat man hauptsächlich nur einen Vdr-Client und möchte eigentlich nur den Server bedienen, kann das auch noch anders lösen, indem man das frontend vom vdr-server per remote-frontend auf dem client darstellt. Dann braucht man kein Streamdev. Muss allerdings ein wenig Handarbeit an die config-scripte anlegen, weil letzteres so direkt in yavdr nicht vorgesehen ist.

  • [gelöst] Konfigurationsfehler, nur wo?

    Hi,


    danke für die Hilfe. Genau das war es. "vdr" lief auf dem neuen Client nicht und damit war die pre-start-Bedingung nie erfüllt. Danke für die Hilfe. :tup


    Ich hätte da auch basierend meiem Problem hier ggf. noch eine Anregung für das WFE. Man kann ja im WFE bei "cutsom configuration" durchaus den vdr aus "disabled" setzen, und trotzdem ein frontend auf enabled setzen . Eventuell könnte man da dann ja noch einbauen, dass er dann die pre-start-Bedingung "WAIT_FOR=vdr" automatisch deaktiviert (wobei man die Dateien/templates ja sowiesow per Hand anpassen muss, da man dem frontend ja sagen muss zu welchem remote-vdr er sich verbinden muss). Nur so als Anregung (Code-Vorschlag siehe unten, soweit ich die Syntax verstanden hab. Die else-Bedingung kann man natürlich auch ganz weglassen...).


    Code
    .../vdr-frontend.conf/15_pre-start-start


<?cs if:(vdr.backend != "disabled") ?>
start wait-for-job-state WAIT_FOR=vdr TARGET_GOAL=start WAIT_STATE=running WAITER=vdr-frontend WAIT_FOREVER=1 ||:
<?cs else ?>
# start wait-for-job-state WAIT_FOR=vdr TARGET_GOAL=start WAIT_STATE=running WAITER=vdr-frontend WAIT_FOREVER=1 ||:
<?cs /if ?>


    Danke für die gute Arbeit. :tup

  • [gelöst] Konfigurationsfehler, nur wo?

    Hi,


    an den anderen hab ich nur bei lirc etwas per "template_custom" geändert. Sonst alles original yavdr. Und dieselben templates laufen auch dem anderen Client ja auch problemlos? "initcl list" zeigt in (siehe oben Zeile 9, vdr-frontend stop/pre-start, process 1094), das das vdr-frontend nach dem booten offenbar nicht gestartet wurde?!?


    Der Hinweis vom mini73 ist aber gut. An dem alten Client hatte ich das damals zuerst mit dem lokalen VDR getestet, der lief also/kann prinzipiell laufen (auch wenn der nix zu tun hat). Bei dem neuen Client hab ich den VDR auf dem Client nie eingerichtet.
    Der VDR scheint ja auch auf dem neuen Client nach "initcl list" nicht zu laufen (oder wird der per rc-script gestartet, heute abend mal checken). Ich muss ja zugeben, dass ich den Upstart-Krams bisher noch nicht ganz durchblickt hatte/habe.
    Im Prinzip kann ja in meinem Fall in meinem cutom-template das "start on started vdr" raus, oder? Und viel wichtiger die Bedingung "wait-for-job-state WAIT_FOR=vdr TARGET_GOAL=start WAIT_STATE=running WAITER=vdr-frontend WAIT_FOREVER=1" sollte auch raus, oder? (heute abend mal testen).
    Verständnisfrage: die Bedingung "start on stopped openbox-tools" started das fronted nachdem "stop xbmc" (falls xbmc läuft)? Weil XBMC im Fenstermanger openbox läuft?

  • [gelöst] Konfigurationsfehler, nur wo?

    ~# initctl list (direkt nach dem boot)


    Code
    cat /etc/init/vdr-frontend.conf################################################################################## ##   The following configuration file is generated automatically by the yaVDR    ##     system. Don't change this file as every update of yaVDR will overwrite    ##         the local changes. Instead put your required customizations           ##       into /etc/yavdr/templates_custom/ based on the original templates       ##                      under /usr/share/yavdr/templates.                        ##                                                                               ##            http://www.yavdr.org/developer-zone/template-overview/ ##                                                                               ##                                                                               ################################################################################### yavdr-frontend - Starts vdr frontend#description     "yavdr-frontend"author          "Steffen Barszus <steffenbpunkt@gmail.com>"env HOME=/var/lib/vdrexport HOMErespawnstart on started vdr or stopped openbox-tools or started sound-device \         or vdr-frontend-restartstop on stopping vdr or stopping openboxpre-start script# wait for vdr, Xorg (after wm is running) and the sound devices to be loadedstart wait-for-job-state WAIT_FOR=vdr TARGET_GOAL=start WAIT_STATE=running WAITER=vdr-frontend WAIT_FOREVER=1 ||:start wait-for-job-state WAIT_FOR=sound-device TARGET_GOAL=start WAIT_STATE=running WAITER=vdr-frontend WAIT_FOREVER=1 ||:start wait-for-job-state WAIT_FOR=openbox-tools TARGET_GOAL=stop WAIT_STATE=waiting WAITER=vdr-frontend WAIT_FOREVER=1 ||:# dont start if some other application is runningif [ -e /tmp/.standalone ]; then   vdr-dbus-send /Remote remote.Disable ||:   exit 1fiend scriptnice -10#setuid vdr#setgid vdr#env XINE_BUFFER_LOG=1env USE_AUTOCROP=0export USE_AUTOCROPscriptexport DISPLAY=:1`dbget vdr.tempdisplay`export __GL_SYNC_TO_VBLANK=1export __GL_SYNC_DISPLAY_DEVICE=`/usr/bin/dbget system.x11.display.0.device`HUDOPTS=""XINELIBOUTPUTOPTS="--post tvtime:method=use_vo_driver --buffers=300 --lirc=/var/run/lirc/lircd-lirc0 --reconnect --audio=alsa --syslog --silent --tcp "CONFIG="--config /etc/vdr-sxfe/config_xineliboutput"exec sudo -u vdr /usr/bin/vdr-sxfe $HUDOPTS $XINELIBOUTPUTOPTS $CONFIG xvdr://192.168.1.30:37890end script

  • [gelöst] Konfigurationsfehler, nur wo?

    Hi,


    also das Syslog ist unauffällig. Scheinbar wird weder das "vdr-Frontend" noch "xbmc" beim hochfahren gestartet (ergo kein Fehler, aber auch keine Startmeldung wie beim anderen System). Die Konfiguration ist etwas speziell, weil der/die Client nicht auf den lokalen vdr/xineliboutput zugreifen, sondern auf remote auf das xineliboutput des vdr-Servers (yavdr-headless). Die modifizierten configs aus /etc/yavdr/templates custom/ wurden entsprechen vom alten client auf den neuen übernommen (ebenso wie das server-wake-script). Fernbedienung fehlt noch in Details (andere Empfänger-Hardware), aber ein Problem nach dem anderen...


    WIe gesagt, eigentlich funktioniert dasmit den Konfig's ja auch. "start xbmc" und dann "stop xbmc" => frontent wird gestartet und funktioniert. Also kann da an diesen Konfig-Dateien eigentlich kein Fehler sein. ABER: Beim booten sollte er ja eigentlich automatisch xbmc oder das vdr-frontend mitstarten. Im WFE hab ich auch mehrmals die Ausgabe-Einstellungen geändert. Funktioiert leider nicht. Irgenwo verschluck er sich also, dass er ein frontend beim boot-Process startet. Nur wo und warum?!? :wand

  • [gelöst] Konfigurationsfehler, nur wo?

    Hallo


    ich bin gerade dabei meinen vdr-client om wohnzimmer gegen eine leisere Version auszutauschen. Ich habe die Konfiguration soweit möglich/sinnvoll kopiert, aber beim neuen habe ich nach dem booten nur einen blinkenden Maus-cursor auf dem TV. Gebe ich dann per ssh “start xbmc“ ein, funktioniert xbmc. Gebe ich dann “stop xbmc“ ein, habe ich auch das vdr-frontend-bild. Wo könnte das hängen, dass er direkt zum vdr-frontend durchbooted? Bin ratlos?


    Danke und Gruß

  • TT S2-3600 pctv452e: I2C error müllt dmesg voll [ erledigt ]

    Um mir mal selbst zu anrworten. Alernative, die zu funktionieren scheint. Rsyslog.conf logging so anpassen:


    Code
    :msg, contains, "pctv452e: I2C error -121"  ~
*.*;auth,authpriv.none<><------>-/var/log/syslog


:msg, contains, "pctv452e: I2C error -121"  ~
kern.*<><------><------><------>-/var/log/kern.log


    Und die zugemüllte console kann man in der /etc/sysctl.d/10-console-messages.conf abschalten mit


    Code
    kernel.printk = 2 4 1 7


    --


    Nachtrag:


    Unter Ubuntu 18.4 mit Yavdr-anisble die Datei


    /etc/rsyslog.d/30-pctv452e.conf


    mit Inhalt:

    Code
    #I2C-Fehlermeldungen pctv452e im Log unterbinden
:msg,contains,"pctv452e: I2C error -121"  stop

    erzeugen und danach den rsyslog-daemon neu starten:

    Code
    service rsyslog restart


    Ggf. mit "tail -f /var/log/syslog" prüfen ob alles geklappt hat (beenden mit Strg+c).

  • TT S2-3600 pctv452e: I2C error müllt dmesg voll [ erledigt ]

    Um diesen alten Thread nochmal hochzuholen. Ubuntu/yavdr0.5 nutzt ja rsyslog. Wenn ich den obigen code jeddoch in die /etc/rsyslog.conf eintrage, dann erhalte ich folgende Fehlermeldung. Funktioniert also leider nicht?!?