Beiträge von TEN

    Auswirkungen des von UnityMedia wie angedroht gestern durchgezogenen "Change Day" sind eingearbeitet:

    http://vdr-wiki.de/wiki/index.…nW%C3%BCrttemberg-KabelBW

    Haufenweise Homeshopping-Sender z.T. sogar im Simulcast.

    Auslandssender weitgehend wegverschlüsselt.

    Einigermaßen störfeste 64QAM gönnen S.I.E. unter den freien Bouquets nur noch ihrer eigenen Videothekenwerbung, ansonsten die überaus anfällige 256QAM soweit das klötzchengeplagte Auge reicht.


    Thread DVB-C Qualität - QAM 256 ist ja leider gesperrt, kann evtl. ein Admin/Mod wieder aufmachen...

    Ist irgendjemand mit Kodi auf VDR-Verzeichnisstrukturen weitergekommen?
    Dauerhaft VDRnfoFS darüberzulegen, kann wohl kaum die Lösung sein, wo Scraper doch mit geschachtelten Pfaden und mehreren pro Verzeichnis zusammenzufassenden Segmenten umgehen können sollen.


    Offengebliebene Fragen gibt es einige:
    [Howto]: VDR Aufnahmen & Datenbank (mit Fanart)
    http://forum.kodi.tv/showthread.php?tid=129821&pid=2524380#pid2524380
    VDR-Aufnahmen in XBMC einbinden
    https://www.kodinerds.net/inde…enbank-und-VDR-Aufnahmen/
    https://www.heise.de/forum/hei…d-596630/#posting_3210235

    In /usr/share/app-install/desktop/xineliboutput-sxfe:vdr-sxfe.desktop installiert Ubuntu 16.04.2 LTS ja wieder mal ein --lirc zuviel (wodurch VDR die Fernbedienungskommandos doppelt oder gar nicht mehr erkennt).
    Dieses Mal lässt es sich aber leider nicht dort alleine austreiben, und ~/.local/share/applications ist auch leer.
    Offenbar wird nun wieder /usr/share/applications/vdr-sxfe.desktop verwendet, die ebenfalls diesen Bug enthält:
    https://bugs.launchpad.net/ubu…ineliboutput/+bug/1001818

    Ja, du müsstest schon alle Pakete aus meinem PPA nutzen, die sind ja abhängig voneinander. [...]
    Soweit ich das sehe bietet keine Linux Distribution einen VDR in der Form an wie es die verschiedenen Repositories von easyVDR, yaVDR, meines etc. bieten. Nur in diesen lassen sich so Dinge wie neuere xine-lib-1.2 oder ffmpeg umsetzen. Die Pakete aus dem Distro-Archiv reichen für einfachsten VDR Betrieb (Server?) aus

    ...allerdings z.B. bei Ubuntu schon über mehrere LTS so, dass vor dem "Betrieb" selbst mit Erfahrung etliche Hürden stehen und ein nach Installation lauffähiger Einstieg kaum möglich ist (in der Regel ohne dass die Distros auf manuell erforderliche Schritte hinweisen). D.h. für Neuzugänge: "probiert&deinstalliert", v.a. solange Bugs im Launchpad über Jahre unassigned und damit auch unerledigt bleiben.
    So stehen dann immer nur mehrere kleine, eigentlich automatisierbare, aber zur manuellen Anpassung mühsam aufzufindende Schritte im Weg, wodurch wer keinen lauffähigen VDR kennt, ihn auch kaum kennenlernt.

    Zitat

    und das wird sich nie ändern. Mit Debian nutzt man auch schon eh und je eTobi's oder Oliver's Repository.

    Habe einfach aus Interesse gefragt, da ich (viel unterwegs) VDRs eher in mehrjährigen Abständen und oft z.T. weitgehend remote aufsetze, unter Verwendung nicht allein dafür dedizierter Maschinen.
    Wie auch bei Welches ppa für Ubuntu Xenial? ergibt sich daraus das verständliche Anliegen, möglichst nah an der jeweiligen LTS zu bleiben: Der Wunsch nach mehr Unterstützung in den großen Distros selbst sollte aber natürlich nicht als Kritik an den PPAs mißverstanden werden.

    Korrekt, vdr-plugin-markad oder vdr-plugin-noad gibt es nicht im Ubuntu Archiv, weder für 12.04 LTS, 14.04 LTS noch 16.04 LTS und auch keine Zwischenversion.

    Evtl. demnächst in (D)einem PPA https://launchpad.net/~fnu/+archive/ubuntu/main-fnu/+packages?field.name_filter&field.status_filter=published&field.series_filter=xenial - oder woher zieht man sie sich die ganzen Jahre, wenn im Übrigen möglichst ein Standard-Debian oder -Ubuntu verwendet werden soll?

    Zitat

    Dort finden sich nur die Plugins, die man auch unter Debian findet, ebenfalls ohne markad oder noad.

    Welches der beiden nimmt man, um nachträglich Sprung-/Schnittmarken für bestehende Aufnahmen anlegen zu lassen (o.g. standalone) ?

    Warum tut man sich Ubuntu Software freiwillig an? apt kann doch alles, was man benötigt

    Weil ich das System gerade erst installiert und nicht erwartet hatte, dass Informationsgehalt und Funktionalität der Default-Softwareverwaltung weiter so abgebaut haben würden. Die allzu simple GUI-Suchzeile findet ja Pakete selbst dann kaum, wenn man sie beim Namen nennt.

    --local=sxfe macht nur sinn, wenn sich das xineliboutput-Plugin ähnlich wie softhddevice verhalten soll, also das Plugin selbst das Ausgabefenster erzeugen soll. Das lässt sich aber nicht sinnvoll in eine normale Ubuntu-Desktop Installation integrieren, da es in dem Fall keine pulseaudio-Unterstützung gibt und man dafür sorgen müsste, dass der User vdr auf Ressourcen der eigenen Desktop-Sitzung zugreifen darf. --local=none passt, wenn du die Ausgabe mit vdr-sxfe umsetzt.

    Vielen Dank, an Pulseaudio hätte ich jetzt nicht als erstes gedacht, und die Priorisierung funktioniert nach -p wieder wie gewohnt mit automatischer Umschaltung (zunächst ohne Hinweisbalken für die beginnende, dann aber korrekt "Channel not available!" und gesperrtes Zurückspringen zum zuletzt gesehenen Transponder während laufender Aufnahme).

    In die /etc/vdr/conf.avail/xineliboutput.conf - es hilft sich anzusehen, welche Dateien in einem Paket stecken (http://packages.ubuntu.com/de/…in-xineliboutput/filelist) und die NEWS.Debian und die README.Debian des VDR-Pakets gelesen zu haben...

    Danke, :] "Ubuntu Software" zeigt ja aktuell nicht mal mehr die technischen Paketnamen an, so daß es sich schwer sucht, wenn man nur alle paar Jahre installiert und auch die Feinheiten von apt(-cache) nicht präsent hat.
    Muß dann auch (oder statt -p nur) --local=none auf --local=sxfe gesetzt werden?

    Könnte es sein, dass die Timer durcheinanderkommen, weil eines Deiner o.g. Plugins wie bei mir wohl xineliboutput bei vdr-sxfe: "setting primary device to 2": Aufnahmen beginnen während LiveTV nicht mehr (wogegen der Parameter half, das Streamserver-Plugin auf primäres DVB-Device zu zwingen) die Anzahl und/oder Reihenfolge der DVB-Devices verändert (so dass sich das primäre wie in /var/log/syslog zu sehen verschiebt, bis man einen Weg findet, es auf eine bestimmte Nummer festzuklopfen) ?


    Früher kündigte ein grüner OSD-Balken die beginnende Aufnahme an und VDR schaltete dann auf den benötigten Transponder (für DVB-C/T strenggenommen Bouquet) um, aber ich erinnere mich, daß man auch bei Mischbetrieb von FF- und Budget-Karten für gleichbleibende Zuordnung schon manuell eingreifen musste.


    Auflistende Einträge wie "Found 1/2 dvb device(s)" und gemeldete Gründe für die Nichtaufnahme konnte ich im Syslog aktuell ebenfalls nicht mehr finden, wohingegen streamdev- Server blocked Kanäle während Aufnahme solche noch beschreibt.


    ich hab mir die Quellen von inputlirc besorgt, und dann inputlircd übersetzt. Die zwei Zeilen hab ich im Code in der Funktion processevent() eingefügt, und in den Syslog getraced. Die eine Zeile oben, wo die ganzen Events reinkommen und noch alle Events zu sehen sind (auch die, die später gar nicht an VDR weitergeleitet werden (Misc und Syn)), die zweite Zeile unten, kurz bevor der Event an lircd weitergeleitet wird ...


    Damit kann ich genau nachverfolgen welche Events reinkommen (aka was die Fernbedienung liefert, und vom IR-Sensor auch erkannt wird), und welcher Teil davon an lircd weitergegeben wird ...


    Mit etwas Spielen an den Zeiten, hab ich dann Werte herausgefunden, mit denen Repeatkommandos an den lircd weitergegeben werden ...
    Ich hänge unten mal den Code ran, mit dem ich das getestet habe

    Danke, :] welches -r war es denn für inputlirc, und ggf. davor schon welche -D und -P für ir-keytable ?
    Kannst Du evtl. eine "Bauanleitung" aus Diff und Deiner Bash-History geben - oder lässt sich ein allgemeingültiger Bugfix ableiten, um zumindest inputlirc verlässlicher zu machen?
    Die Lage bei LIRC ist ja schon schlimm genug... :rolleyes: www.vdr-portal.de/board18-vdr-…-unter-ubuntu-16-04-2-lts

    Zitat

    hier die Event´s die ich jetzt bekomme, in einer selbst generierten Version von inputlirc ...


    - Inputlircd info 1 ist oben im Inputlircd, wo die ganzen Event´s ankommen (Type 1=KEY, Type 4=MISC, Type 0=SYN)
    - Inputlircd info 2 ist unten im inputlircd, wo der Event Richtung über /var/run/lirc/lircd an VDR weitergegeben wird (1: Tastencode in Hex, 2: Repeat-Zähler, 3: Text String "Key_Code_" mit Tastencode dezimal angehängt; 4: Empfängerdevice)


    Man sieht schön, wie der Repeat-Zähler hochgezählt wird.

    Kannst Du uns verraten, wie und womit Du das aufgesetzt hast?

    Versuchen wir es also mal mit sudo apt install lirc, auf das devinput-Device, danach Reboot.


    /etc/lirc/hardware.conf


    ...und /etc/lirc/lircd.conf

    Code
    1. include /usr/share/lirc/remotes/devinput/lircd.conf.devinput



    Damit das Eventsystem und dadurch VDR die Tastendrücke sehen kann, ist schrägerweise erst mal sudo service lirc stop erforderlich.


    Dann aber regnet es (im Gegensatz zum vorigen Post) EV_MSCs für unbekannte und EV_KEYs für bereits definierte Tasten in sudo evtest bzw. sudo ir-keytable -t.


    Bei Verwendung des VDR X-Frontend werden die Tasten wieder mal doppelt erkannt, da automagisch als vdr-sxfe --lirc in die Menüs eingetragen (Jahre alter https://bugs.launchpad.net/ubu…ineliboutput/+bug/1001818 alle Releases wieder).


    Um zum Test dem aktuellen Ubuntu-VDR abzugewöhnen, (statt, oder schlimmer noch neben vdr-sxfe) selbst --lirc zu verwenden, ist diese Zeile wohl in /etc/vdr/conf.d/00-vdr.conf auszukommentieren:
    /etc/default/vdr ist leer und OPTIONS="--lirc=/dev/null" gemäß LIRC deaktivieren scheint darin nicht mehr zu funktionieren.
    Bei mir führt das allerdings auch nur dazu, dass die Tastendrücke statt doppelt beim VDR gar nicht mehr ankommen, trotz vdr-sxfe --lirc.


    Leider konnte ich bislang auch mit diversen Delays weder auf Ebene von ir-keytables noch von inputlircd die automatische Wiederholung gehaltener Tasten in VDR zum Laufen bringen:
    [gelöst] Probleme mit Debian Stretch und lircinput seit Debian 4.8.11 beschreibt ein ähnliches Problem, aber für die RC6-Fernbedienung.
    (Erst) nach(!) sudo service lirc stop erkennt irw gedrückt gehaltene Tasten, nur wie VDR ohne Wiederholung.
    Nach weiterem sudo service inputlirc stop wird /dev/input/event9 auch für sudo ir-keytable -t und sudo evtest zugänglich:
    Beide zeigen (anders als VDR&irw) funktionierende Wiederholung gedrückt gehaltener Tasten.

    Naja Zeile 16 und 17 aus Post 36 sagen doch aber, dass inputlircd noch auf /dev/input/event9 zugreift?


    Ok, du hast inputlircd zwar gekillt, dann aber den Rechner neu gestartet. Kann es sein, dass das inputlircd bei dir beim booten automatisch mit gestartet wird und sich dann die events wieder krallt?

    Ich habe beide Varianten (ohne und mit apt-Paket lirc) in IR an mceusb unter Ubuntu 16.04.2 LTS so detailliert wie nur möglich aufgedröselt, aber konnte noch nicht herausfinden, wo es klemmt.


    Eigentlich sollte ich ohne apt-Paket lirc auskommen, falls es zum nur darin enthaltenen irsend auch mit dem neueren Kernelansatz irgendein Pendant gibt.

    Da vom apt-Paket lirc abgeraten wird, erfolgt zunächst nur sudo apt install vdr vdr-plugin-femon vdr-plugin-xineliboutput inputlirc.


    /lib/udev/rules.d/60-ir-keytable.rules (in früheren Versionen noch Priorität 40) enthält

    Code
    1. ACTION=="add", SUBSYSTEM=="rc", RUN+="/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s $name"


    Universal8in1 folgenden Inhalts (unverändert wie am IR-Port der DVBsky angelernt, für auf Code 052 definierte AUX-Tasten) kommt weiterhin nach /lib/udev/rc_keymaps - obwohl in /etc/rc_maps.cfg immer noch falsch /etc/rc_keymaps steht.


    /etc/rc_maps.cfg wird folgende tabulatorgetrennte Zeile angefügt:

    Code
    1. mceusb * Universal8in1


    /var/lib/vdr/remote.conf (worauf ein bis dahin ungültiger Symlink aus /etc/vdr zeigt) erhält den Inhalt:




    Damit müsste doch alles an Ort und Stelle sein?! :rolleyes:


    Die Tasten sollen an VDR übergeben werden durch inputlircd -g -m 0 /dev/input/by-path/pci-0000:00:1d.0-usb-0:1.5:1.0-event (systemabhängig).


    sudo service inputlirc stop, um folgendes testen zu können, wie von http://www.lirc.org/html/configuration-guide.html verordnet:


    Direkt am Kernel werde ohne apt-Paket lirc werden also gar keine Tasten erkannt (und natürlich fehlt auch irsend).


    Dabei sollten selbst für unbekannte Fernbedienungen hier Scancodes erscheinen.


    Was aber funktioniert, ist folgendes:


    Das Problem muß also nach dem oberen Pfeil ---->---- von http://www.lirc.org/html/confi…l-configuration-decisions zwischen Kernel und Linux Input Layer liegen.



    Als letzte Zeile der /lib/udev/rules.d/60-ir-keytable.rules ist also erforderlich:
    ACTION=="add", SUBSYSTEM=="rc", RUN+="/usr/bin/ir-keytable -c -p sony -w /lib/udev/rc_keymaps/Universal8in1"
    Evtl. ergänzt um derzeit wohl nur manuell und mit einem Hack zu ermittelnde -D und -P, damit die Wiederholung gedrückt gehaltener Tasten auch für den VDR hinter inputlirc funktioniert.

    Naja Zeile 16 und 17 aus Post 36 sagen doch aber, dass inputlircd noch auf /dev/input/event9 zugreift?


    Ok, du hast inputlircd zwar gekillt, dann aber den Rechner neu gestartet. Kann es sein, dass das inputlircd bei dir beim booten automatisch mit gestartet wird und sich dann die events wieder krallt?

    Das hatte ich wohl etwas widersprüchlich gepostet:
    Klar autostartet inputlirc, dessen Prozess(e) habe ich aber zum Test jeweils gekillt,
    außerdem sogar sudo apt remove lirc angewendet und rebooted.
    D.h. nichts außer dem Kernel (evdev) selbst dürfte sich das mceusb krallen.
    Warum aber sehe ich dann gar keine Events?


    xorg sollte nicht stören, hatte aber sicherheitshalber auch dieses mal mit dem Ignore-Eintrag ferngehalten.


    In /etc/rc_maps.cfg habe ich auskommentiert:
    #* rc-rc6-mce rc6_mce
    Trotzdem sehe ich es überall noch (unten mit lirc, aber ohne ebenfalls):



    Dein Problem ist nicht der xserver, sondern inputlircd. Wenn du mit ir-keytable oder evtest spielen willst, musst du vorher inputlircd beenden.

    Fürs mceusb habe ich ja inputlircd gekillt und lirc sogar deinstalliert: Danach (nach Reboot) kommen keine events mehr an.
    Wird lirc mit dem System hochgefahren und dann beendet, erkennen ir-keytable und evtest die Tasten.
    Nur dann habe ich auch irsend.
    Muß ich, um ohne lirc auszukommen, das Modul rc_rc6_mce irgendwie loswerden, da die Fernbedienung ja keine RC6, sondern in /lib/udev/rc_keymaps/Universal8in1 definiert ist? :rolleyes:
    Habe diesen nicht T982-spezifischen Teil mal in http://www.vdr-portal.de/board…-unter-ubuntu-16-04-2-lts verlagert.