Posts by jansi

    Bei TCP kann es (im Gegensatz zu UDP) nicht so ohne weiteres zu Paketverlusten bei der Übertragung kommen, da der Empfang jedes Pakets bestätigt werden muss und im Fehlerfall neu versendet wird. Das macht die Verbindung zuverlässiger.

    Ob das bei einer stabilen Netzwerkverbindung Sinn macht ist eine andere Frage, schaden kann es aber nicht denke ich.

    Nachteil ist der höhere Overhead der aber in diesem Anwendungsfall vernachlässigt werden kann.


    Die Receiver sind einmal TT-connect S2-3600 und einmal DVBSky S960 (glaube ich).


    Das ganze ist aber wie gesagt erst seit zwei Tagen im Einsatz, nicht auszuschliessen, dass da doch noch Probleme auftauchen.

    Hallo Forum.


    EPGScanTimeout = 0 und satip.EnableEITScan = 0 haben den "Transfer-Mode kann nicht gestartet werden"-Fehler tatsächlich verschwinden lassen.


    Ich hatte allerdings jede Menge weitere Probleme mit dem Digibit Twin Server. Immer mal wieder nur schwarzes Bild wenn das Frontend vorher detached war, manchmal half ein reboot, manchmal nicht. Immer mal wieder auch längere Aussetzer wenn der Fernseher mehr als eine halbe Stunde lief, Unterirdische Umschaltzeiten usw usf..

    Der Digibit ist jetzt rausgeflogen und wurde vor zwei Tagen durch einen Banana Pi mit minisatip im TCP-Modus und zwei DVB-S2 USB-Receivern ersetzt (hatte ich alles noch im Keller liegen). Bis jetzt läuft es rund, Keine Hänger und super Umschaltzeiten.

    Das Digibit-Ding scheint einfach Grütze zu sein.


    Grüße.

    Ich habe das gleiche Problem, auch schon mit yavdr-0.6. Bin jetzt auf ansible/bionic und es ist noch immer da.

    Auch satip (Telestar digibit twin).

    Tritt auch bei mir nur gelegentlich auf und meistens genau dann, wenn ich vom Anschauen einer Aufnahme zurück ins Live-Programm komme.


    Ich habe jetzt mal ein paar nicht benutzte Plugins runtergeschmissen (permashift, osd2web, markad), sowie EPGScanTimeout = 0 und satip.EnableEITScan = 0 in der setup.conf gesetzt.


    Mal schauen ob das was bringt, werde berichten.

    Räusper, dann war ich das wohl irgendwie selbst. Klarer Fall von PEBKAC :wand:

    669 apt-get install eventlircd inputlirc


    Hab inputlirc jetzt weggeputzt und die FB scheint jetzt zuverlässig zu funktionieren.


    Was soll ich sagen? Tausend Dank für dein Engagement und die schnelle Reaktion. Ohne Deine Hilfe wäre es wohl auf eine Neuinstallation hinausgelaufen (Die ist extrem nervig auf der lahmen Atom-Kiste).


    Gibt es einen Donate Button irgendwo?


    Cheers,

    Stephan

    Moin Seahawk.


    Der lircd.socket ist deaktiviert:

    Code
    1. stephan@yavdr:~$ sudo systemctl status lircd.socket
    2. ● lircd.socket
    3.    Loaded: loaded (/lib/systemd/system/lircd.socket; disabled; vendor preset: en
    4.    Active: inactive (dead)
    5.    Listen: /run/lirc/lircd (Stream)

    Allerdings ist eventlircd.socket aktiv. Das soll so, oder?:

    Code
    1. stephan@yavdr:~$ sudo systemctl status eventlircd.socket
    2. Failed to dump process list, ignoring: No such file or directory
    3. ● eventlircd.socket
    4.    Loaded: loaded (/lib/systemd/system/eventlircd.socket; enabled; vendor preset: enabled)
    5.    Active: active (running) since Fri 2019-07-05 08:19:16 CEST; 9min ago
    6.    Listen: /run/lirc/lircd (Stream)
    7.    CGroup: /system.slice/eventlircd.socket
    8. Jul 05 08:19:16 yavdr systemd[1]: Listening on eventlircd.socket.

    /run/lirc/lircd sieht so aus:

    Nach einem sudo systemctl restart eventlircd sieht das allerdings nicht anders aus (und dann geht es ja):

    Code
    1. stephan@yavdr:~$ sudo systemctl restart eventlircd
    2. stephan@yavdr:~$ sudo fuser -v /run/lirc/lircd
    3.                      BEN.        PID ZUGR.  BEFEHL
    4. /run/lirc/lircd:     root          1 F.... systemd
    5.                      nobody      761 F.... inputlircd
    6.                      root       1654 F.... eventlircd


    Die Datei /etc/lirc/lirc_options.conf ist unverändert (habe deinen obigen PS jetzt gerade erst wahrgenommen).

    stephan@yavdr:~$ cat /etc/lirc/lirc_options.conf


    .. es kann schon sein, dass ich da irgendwas verbastelt habe. Ich hatte nach der Installation direkt das seahawk1986-hotmail ppa eingebunden. Da ich aber Probleme mit der Sprache hatte (hat sich im nachhinein als Fehlconfiguration von localepurge herausgestellt) habe ich dann wieder ein Downgrade gemacht indem ich die vdr-Pakete entfernt habe und das Playbook nochmal habe laufen lassen.

    Kann auch sein, dass ich alle lirc-relevanten Pakete raus genommen und vom Playbook neu habe installieren lassen.

    Außerdem fällt mir gerade ein, dass ich lircd.service manuell aktivieren musste, das sollte doch eigentlich automatisch funktionieren wenn ein Atric im system erkannt wird?

    Weiterhin ist /etc/lirc/lircd.conf.d/atric2.conf vom alten yavdr-0.6 übernommen. Aber lirc an sich funktioniert ja.


    Soll ich mal diese Teile des Plabooks nochmal laufen lassen?

    Code
    1. ansible-playbook yavdr07.yml -b -i 'localhost_inventory' --connection=local --tags="yavdr-remote"
    2. ansible-playbook yavdr07.yml -b -i 'localhost_inventory' --connection=local --tags="autoinstall-atric-usb"


    Viele Grüße,

    Stephan

    Hi Seahawk.


    Danke für die schnelle Antwort.

    Mit der Änderung in 98-eventlircd.rules hält der vdr die Füße still, wenn eventlircd gestoppt wird, schonmal gut.

    Ausserdem funktionert es jetzt nach einem eventlircd und vdr Neustart, auch gut.


    Das Problem der nicht funktionierenden FB nach dem Systemstart bleibt allerdings.


    Grüße,

    Stephan

    Hallo Forum.


    Ich habe folgendes, mir unerklärliches Problem:

    Ich nutze einen Atric USB-Empfänger mit Lirc. Der funktioniert auch soweit, irw /var/run/lirc/lircd0 zeigt mir die Tastendrücke brav an.

    Irgendwie wird das aber nicht vom eventlircd aufgegriffen, so dass irw /var/run/lirc/lircd nichts zurück gibt und die Fernbedienung somit nicht funktioniert.

    lircd2uinput funktioniert augenscheinlich auch, geprüft mit evtest.

    Stoppe ich eventlircd, so schaltet der VDR die Kanäle von alleine einfach durch, warum denn das?

    Jul 04 10:21:22 yavdr vdr[950]: [950] switching to channel 8 S19.2E-1-1107-17501 (ProSieben)

    Jul 04 10:21:26 yavdr vdr[950]: [950] switching to channel 9 S19.2E-1-1107-17508 (SAT.1 NRW)

    usw


    Starte ich eventlircd wieder, so funktioniert irw /var/run/lirc/lircd, aber ich bekomme den vdr nicht dazu mit dem rumschalten aufzuhören, systemctl restart vdr bringt da auch nichts.


    Manchmal hingegen funktioniert es einfach. Offensichtliche Fehler finde ich nicht im Log (Angehängt).

    :/


    Wer hat eine Idee?


    Vielen Dank,

    Stephan

    Files

    • journalctl.txt

      (156.71 kB, downloaded 125 times, last: )

    Guten Abend zusammen.


    Kennt jemand eine Möglichkeit um gezielt einzelne Treiber aus Staging zu aktivieren bzw. eine Custom .config einzubauen?
    Ich würde gerne den Treiber für AS102 einschalten, ich habe den "Pinnacle PCTV 74E" DVB-T Stick. Ausserdem könnte man die Compile-Zeiten drastisch reduzieren, wenn man nur Treiber für die tatsächlich vorhandene Hardware mitnimmt.


    Am besten so, dass dir Konfiguration bei einem Update des linux-media Pakets erhalten bleibt.


    Viele Grüße!

    Hallo zusammen.


    So habe ich die Fernbedienung der TT S2-3600 ans laufen gekriegt:


    Nach der Yavdr-Installation habe ich einen V4L-Snapshot von Hand eingespielt, sollte aber denke ich mit v4l-dvb-dkms genauso funktionieren. Bei mir lief die Fernbedienung von der s2-3600 mehr oder weniger out of the box, nur fehlten die Mappings auf POWER2, ESC und MENU. Versuche mit evmaps haben nicht funktioniert, dann habe ich die Doku auf http://yavdr.org/documentation/de/ch02s02.html gestossen.


    So sieht es aus (auf das Wesentliche gekürzt):



    Ein eventlircd-Device habe ich nicht entdeckt, in der Doku steht es sollte vorhanden sein wenn eventlircd läuft...


    Code
    1. root@yavdr:~# ps aux | grep lirc
    2. ...
    3. root 5865 0.0 0.0 10520 836 ? S<s 20:25 0:00 /usr/sbin/eventlircd -f --repeat-filter --socket=/var/run/lirc/lircd
    4. ...


    ir-keytable sagt table rc-tt-150:

    Code
    1. root@yavdr:~# ir-keytable
    2. Found /sys/class/rc/rc0/ (/dev/input/event2) with:
    3. Driver (null), table rc-tt-1500
    4. Supported protocols:
    5. Enabled protocols:
    6. Repeat delay = 500 ms, repeat period = 125 ms


    Also habe ich mir laut Doku eine keymaps erstellt:


    Und diese via rc_maps.cfg eingebunden:

    Code
    1. root@yavdr:~# cat /etc/rc_maps.cfg | grep -v ^# | grep .
    2. * rc-tt-1500 tt_s2-3600
    3. ir-kbd-i2c * /lib/udev/rc_keymaps/pvr350
    4. * rc-imon-pad /lib/udev/rc_keymaps/imon_mce
    5. mceusb * /lib/udev/rc_keymaps/HOPLOrc6
    6. mantis_core * /lib/udev/rc_keymaps/skystarhd2


    Mapping der drei Tasten ist auch ok jetzt:


    Code
    1. root@yavdr:~# irw
    2. 164 0 KEY_POWER2 devinput
    3. 8b 0 KEY_MENU devinput
    4. 1 0 KEY_ESC devinput


    Ich habe den SHUFFLE key in MENU umgewidmet und bin vollstens zufrieden. Für VDR und XBMC muss nichts weiter konfiguriert werden. Auch die Probleme mit dem prellen der Fernbedienung sind weg. Die Doku ist auch super (insbesondere die Zeichnung).


    Vielen Dank nochmal, YAVDR ist echt ma coole Software ;-)