Beiträge von seahawk1986

    Nun komme ich mit dem Mauspfeil dort aber nicht rauf, denn sobald ich die Maus bewege erlischt die "Sprechblase". Das ist doch sicher so nicht gedacht?

    Selbst wenn du den Link erwischen würdest, würde der nicht viel bringen - im Quelltext sieht das so aus: <a href="http://Jörg, kennst du nen passenden InternetLink?" target="_blank">siehe</a>


    Hier gibt es eine recht brauchbare Übersicht: https://www.regular-expressions.info/tutorial.html

    yaVDR bringt ja bereits einen Samba- und NFS Server mit und das lifeguard-Addon verhindert, dass der Rechner vom VDR heruntergefahren wird, wenn da ein Client noch eine Verbindung hält. Im einfachsten Fall nimmst du also einen yaVDR, passt die Konfigurationsdateien für Samba bzw. NFS (IIRC sind da Templates im Spiel) auf deine Wünsche an und bist fertig.

    Wenn man keinen physischen Schutz (ein GFK- oder Plexiglas-Aufsatz mit steileren Flächen in Sichtrichtung zum Satelliten könnte helfen den Schnee besser abrutschen zu lassen) anbringen kann, bleibt nur die Antenne zu beheizen, regelmäßig freizuräumen oder zu versuchen die Oberfläche weniger haftend zu machen - es gibt diverse Produkte für die Versiegelung von Oberflächen, die einen Lotus-Effekt erzeugen sollen - die Frage ist halt, wie gut das mit der Oberfläche der Selfsat-Antenne funktioniert.


    Ansonsten ist eine Cassegrain-Schüssel (wie die Gibertini Cassegrain CPR 60) eventuell noch eine Idee, die sind konstruktionsbedingt auch nach vorne gekapselt, aber haben eine größere effektive Spiegelfläche und einen abgerundeten Radome. Bei meiner Großmutter klappt das an einem alten Antennenmast auf dem Dach ohne zusätzlichen Wetterschutz seit Jahren zuverlässig mit dem Empfang.

    Wie kann ich das verbessern?

    Ich habe das für irmplircd so gelöst - damit hängt es rein an der Erkennung der Hardware über udev, ob die Systemd-Unit gestartet wird oder nicht:

    Code: irmplircd.udev
    1. ACTION=="add", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="27d9", TAG+="systemd", ENV{SYSTEMD_WANTS}="irmplircd@%k.service"
    2. ACTION=="add", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="4444", TAG+="systemd", ENV{SYSTEMD_WANTS}="irmplircd@%k.service"

    Code: irmplircd@.service
    1. [Unit]
    2. Description=irmplircd - a daemon for IRMP receivers
    3. [Service]
    4. Type=forking
    5. Environment="SOCKET=/var/run/lirc/irmplircd" "KEYMAP=/etc/irmplircd/irmplicd.map"
    6. EnvironmentFile=-/etc/default/irmplircd
    7. ExecStart=/usr/bin/irmplircd -t ${KEYMAP} -d ${SOCKET}-%I /dev/%I
    8. SuccessExitStatus=0 71

    Und das Paket yavdr-hardware-irmp ergänzt dann das Drop-In für lircd2uinput:

    Code: irmplircd@.service.d/lircd2uinput-hooks.conf
    1. [Service]
    2. ExecStartPost=/usr/bin/lircd2uinput-add ${SOCKET}-%I
    3. ExecStopPost=/usr/bin/lircd2uinput-remove ${SOCKET}-%I

    Gibt es denn da für neue Leute Möglichkeiten einzusteigen?

    Ja, wenn jemand Zeit und Lust hat sich da reinzufuchsen gerne. Diablo hat z.B. schon ein paar Sachen für die Hardware-Erkennung und den Firmware-Download für DVB-Karten beigetragen und CKone hat über die Feiertage fleißig getestet und ich habe bei der Gelegenheit das yavdr-addon-pip und die grundsätzliche Anbindung von lircd und anderen Diensten, die einen lirc-kompatiblen Sockel bereitstellen, an eventlircd überarbeitet.


    Erfahrungsgemäß geht ein guter Teil der Zeit dafür drauf Dinge zum Aufbau des System oder zu Ansible zu erklären, eine ordentliche Dokumentation zum Aufbau fehlt leider noch, dafür ist noch zu viel im Fluss.



    Abhängig davon was du an Wissen und Fähigkeiten besitzt (bzw. dazu lernen willst), findet sich das sicherlich etwas, das du beitragen kannst :)

    So ungefähr wie man checkt die Tasklist und sieht "dieses und jenes Startscript muss umgestellt werden". Checkt die Daten aus und lädt die Änderungen wieder hoch?

    Für das ansible-Playbook und yaVDR-Kernpakete sind pull-Requests über GitHub kein Problem, bei anderen Paketen, die in den PPAs liegen, gibt es oft kein Git - da könnte man die Pakete mit Änderungen in ein eigenes PPA hochladen oder mir diffs schicken.


    Leider kommt man selten in der Verlegenheit, dass man einfach das Upstart-Skript als Systemd-Unit umschreiben kann. Oft muss man dann auch noch die zugehörigen Pakete auf systemd umstellen, udev-Regeln überarbeiten und idealerweise sollte es noch jemanden geben, der das ganze Testen kann, bevor es im Playbook bzw. PPA landet...


    yavdr-ansible muss dann noch (wenn das Grundgerüst mal steht) so umgestellt werden, dass ein zukünftiges Webfrontend die Rollen gezielt aufrufen kann, um das System umzukonfigurieren - quasi als Ersatz für die actions und events, die es bislang in yavdr-utils gab.

    Was ich mir von einer neuen Distri wünschen würde, das es eine DAU taugliche, wenn auch eingeschränkte Version gibt, die das Thema HD-TV abdeckt, ähnlich den LINUX TV Boxen.

    HDTV ist an sich ist mit nvidia-Grafik kein Problem (Meltdown und Spectre animieren mich aktuell nicht wirklich für VAAPI-Experimente neue Hardware zu kaufen), HD+ ist eine andere Geschichte (die mich nicht wirklich interessiert - wer hat schon Zeit für Werbefernsehen...).


    Aber nachdem man sich das oder die PPAs für die VDR-Pakete nach Belieben aussuchen kann und jeder (der Zeit und Lust hat) eine Rolle für das Ansible-Playbook schreiben kann, das da die nötige Vorarbeit leistet, sehe ich das nicht als großes Problem an. Man muss ja kein DAU bleiben, sondern kann sich zum Nutzer mit gefährlichem Halbwissen aufschwingen ;)

    So wie im deinem ersten Post erwähnt - alles, was einen lirc-kompatiblen Sockel anbietet wird an lircd2uinput gehängt, das reicht die Tastendrücke an eventlircd weiter und VDR und KODI arbeiten am Sockel von eventlircd als Lirc-Clients.


    Damit das bei KODI funktioniert, braucht es eine Lircmap.xml, die Definitionen für ein Gerät mit dem Namen "devinput" enthält - die könnte z.B. so aussehen: https://github.com/yavdr/yavdr…s/userdata/Lircmap.xml#L4 und diese Tasten werden dann über die remote.xml auf KODI-interne Tastennamen gemapped.


    Ich habe heute noch mal die aktuelle Version von lircd2uinput mit einer bekannt prellenden Fernbedienung (die sendet 3 Frames für einen einzelnen Tastendruck) auf ein KODI 17 losgelassen, das hat die initialen Tastenwiederholungen genauso brav weggefiltert wie der VDR.

    Zur fehlgeschlagenen Installation mit dem ISO: Da ist soweit ich das nachvollziehen konnte in den Ubuntu-Paketquellen ein virtuelles Paket geändert worden für das der Installer keinen passenden Installationskandidaten findet (und damit schlägt die Installation des KODI-Pakets auf dem ISO) fehl.

    Gegen das Problem hilft letztendlich nur ein neues ISO mit einem aktualisierten yavdr-essential Paket (das die benötigte zusätzliche Abhängigkeit für KODI einführt, die der Installer nicht selbstständig auflösen kann) - das müsste mini73 mal bauen.


    Alternativ zur Methode den Netzwerkstecker während der Installation zu ziehen kann man die Installation mit einem Ubuntu Server ISO plus nachgeladener preseed-Datei machen - vgl. 0.6.1 Installation: Kein Netzwerk, keine Tastatur nach 1. Boot und der nachfolgende Post.


    Zur Frage wie es mit yaVDR weitergeht:

    Das Hauptproblem ist die Umstellung von Upstart auf Systemd, denn damit funktionieren die ganzen über Jahre gewachsenen Upstart-Skripte nicht mehr. Gleichzeitig ist das die Gelegenheit, um möglichst viel überflüssig gewordenes Zeug loszuwerden.


    Es gibt bereits Pakete für Ubuntu 18.04: Für das Basismaterial https://launchpad.net/~yavdr/+…perimental-main/+packages und für den VDR 2.3.8 https://launchpad.net/~yavdr/+…e/ubuntu/experimental-vdr


    In https://github.com/yavdr/yavdr-ansible/tree/bionic entsteht nach und nach ein Ansible-Playbook, das einem ausgehend von einer Ubuntu Minimal- bzw. Server-Installation ein nutzbares yaVDR-System einrichtet. Der interessierte Nutzer bekommt damit die Möglichkeit nahezu beliebige Anpassungen vorzunehmen, also z.B. gleich mit den gewünschten PPAs und angepassten Konfigurationsdateien zu starten, statt erst den Installer laufen zu lassen und dann später Dinge von Hand so hinzubiegen, dass sie den eigenen Wünschen entsprechen.


    Mit dem aktuellen Stand sollte man (wenn eine nvidia-Grafikkarte verbaut ist) ein nutzbares Grundsystem bekommen, dem halt noch gewohnte Features wie das WFE und eine Menge Details fehlen.

    Ok, wenn ich lircd2uinput -a nutze, ist sind die endlosen Tastenwiederholungen weg, allerdings kommt das Programm bei der Reihenfolge der Tasten-Events durcheinander, wenn release-timeout=0 gesetzt ist (und dann ignoriert eventlircd die Wiederholungs-Events):

    Code: irw /run/lirc/lircd0
    1. 1516014427.509139: 00000000000002c5 00 KEY_DOWN harmony_kls_vdr_1.6
    2. 1516014427.621137: 00000000000002c5 01 KEY_DOWN harmony_kls_vdr_1.6
    3. 1516014427.733153: 00000000000002c5 02 KEY_DOWN harmony_kls_vdr_1.6
    4. 1516014427.845125: 00000000000002c5 03 KEY_DOWN harmony_kls_vdr_1.6
    5. 1516014427.965126: 00000000000002c5 04 KEY_DOWN harmony_kls_vdr_1.6
    6. 1516014428.077128: 00000000000002c5 05 KEY_DOWN harmony_kls_vdr_1.6
    7. 1516014428.237263: 00000000000002c5 06 KEY_DOWN harmony_kls_vdr_1.6


    Wenn man den release-timeout erhöht (z.B. 150 ms), sendet er einen Key-Repeat am Ende zu viel:

    Code
    1. 1516014216.702177: 00000000000002c5 00 KEY_DOWN harmony_kls_vdr_1.6
    2. 1516014216.814162: 00000000000002c5 01 KEY_DOWN harmony_kls_vdr_1.6
    3. 1516014216.974323: 00000000000002c5 02 KEY_DOWN harmony_kls_vdr_1.6

    Code
    1. Event: time 1516014216.702225, type 1 (EV_KEY), code 108 (KEY_DOWN), value 1
    2. Event: time 1516014216.702225, -------------- SYN_REPORT ------------
    3. Event: time 1516014216.814216, type 1 (EV_KEY), code 108 (KEY_DOWN), value 2
    4. Event: time 1516014216.814216, -------------- SYN_REPORT ------------
    5. Event: time 1516014216.958897, type 1 (EV_KEY), code 108 (KEY_DOWN), value 2
    6. Event: time 1516014216.958897, -------------- SYN_REPORT ------------
    7. Event: time 1516014216.964420, type 1 (EV_KEY), code 108 (KEY_DOWN), value 0
    8. Event: time 1516014216.964420, -------------- SYN_REPORT ------------
    9. Event: time 1516014216.974373, type 1 (EV_KEY), code 108 (KEY_DOWN), value 2
    10. Event: time 1516014216.974373, -------------- SYN_REPORT ------------

    Also dann mal so: yaVDR 0.6.1 basiert auf Ubuntu 14.04 (trusty tahr). Die KODI-Entwickler schaffen es nicht KODI 18 Pakete dafür zu bauen,, du ziehst dich auf die Position zurück, dass du ein DAU bist (was man ja nicht bleiben muss), und glaubst, dass du nicht in der Lage bist KODI 18 Pakete dafür zu bauen, also gibt es keine KODI 18 Pakete für Ubuntu 14.04/yaVDR 0.6.1.