Beiträge von TEN

Für 2-3 VDRs von "Kunden" zu reden und eigene Pakete zu bauen, heißt natürlich schon ein größeres Rad zu drehen als mir lieb ist, v.a. wenn inkl. "eigenem" VDR.
Für mich wäre es eher zeit- und nervenschonend, zu erfahren, wer ebenfalls dieses Plugin (und vielleicht noch noad o.ä. und burn) schlicht für Standard-LTS pflegt, soweit es diese schon nicht mehr in die Default-Repositories der Distribution geschafft haben.

Hier gibt's doch sicher eine kleine Gemeinde, die nicht noch weitere Distributions-Derivate anlegen will (auch wenn es ja immer scherzhaft heißt, jeder solle eine eigene starten, ebenso wie jeder mal Papst bei den Diskordianern werden müsse ) und sich um einen zuverlässigen Plugin-Pfleger schart?

À propos, z.B. in der Heise-Diskussion zum VDR-Jubiläum wurde genau die eingeschränkte Verfügbarkeit von aktuellem VDR und Plugins in den großen Distributionen als neben proprietären Treibern größte Hürde beschrieben, durch die ihn viele nicht zufriedenstellend zum Laufen bekommen konnten.

Mod.: Was sollen die Vollzitate bei direkter Antwort, jeder kann sehen und lesen worauf geantwortet wird!

In früheren Ubuntu-Versionen war das Paket vdr-plugin-lcdproc ja noch enthalten, inzwischen gibt es von fnu, yavdr und anderen mehrere Versionen in PPAs etc.
Welche ist für ansonsten unverändertes Trusty Tahr gedacht, und lässt sich wie einbinden, ohne sich weitere dazu nicht zwingend benötigte andere Pakete einzufangen?
(Da für weit entfernte, oft nur über ssh erreichbare Produktivmaschinen, die wegen Wartbarkeit möglichst weitgehend auf "plain vanilla" LTS bleiben müssen...)

Ich konnte eine schöne Lösung finden, LIRC (bidirektional) und lcdproc per Pogoplug auch mit aktuellem Kernel über (W)LAN vom eigentlichen VDR abgekoppelt aufzustellen: http://ubuntuforums.org/showthread.php?t=2270362 - so daß in "WAF-Gefahrenzonen" alles klein, unscheinbar und lüfterlos bleiben kann und man nur noch den Stream oder ein HDMI-Signal zum TV/Beamer führen muß.

Zitat von kls

Nachdem das jetzt eigentlich recht schön funktioniert mit Google Maps würde ich da eher ungern nochmal von vorne anfangen.
Der Fairness halber würde ich mir einen entsprechenden Vorschlag aber natürlich anschauen und, sofern er mich überzeugt, ggf. auch übernehmen. Allerdings müsste er mindestens ebenso einfach zu impementieren sein wie mit Google Maps (also nur sehr wenig Code) und die gleiche Leistungsfähigkeit bieten.

Hast Du das wie in Mapmaking: Keyhole Markup Language @ [RFC] Zahl der aktiven VDRs erfassen implementiert oder sogar noch einen "anmeldefreien" Weg gefunden, KMLs weiter an Google Maps (ohne "My") zu übergeben?

Zitat von olebowle

Ich hab den Thread gerade noch einmal überflogen und mir ist immer noch nicht klar warum ihr unbedingt lirc benutzen wollt.

"Wollten" wahrscheinlich die wenigsten, aber ohne die von Dir ausgetüftelten Wege konnte wohl kaum jemand auf die Möglichkeiten kommen, es ohne das im Fokus fast der gesamten Dokumenation stehende LIRC und seine durch all die Umbauten ungültig gewordenen Definitionen zu bewerkstelligen.

Zitat

Ich bin jetzt endlich mal dazu gekommen. Bei mir ist der interessante Receiver rc1: [...]
$ sudo ir-keytable [...]
Hier mal eine kurze Zusammenfassung meiner Vorgehensweise. Zunächst muss die Fernbedienung natürlich ein Protokoll benutzen, welches vom Kernel dekodiert werden kann. Dazu zunächst erst einmal alle Protokolle aktivieren, die es gibt (Zeile 1) und dann schauen ob scancodes gemeldet werden (Zeile 2). Danach solange die Protokolle reduzieren, bis nur noch eines übrig ist und trotzdem noch scancode ankommen (Zeile 3-4). In meinem Fall hatte ich es mit einer Fernbedienung (vom TV) zu tun, die NEC spricht. [...]
keymap, die ich in /etc/rc_keymaps/my_remote angelegt [...]
möglicherweise vorhandene, alte keycodes löschen und die neuen laden. Danach das Ganze testen:

Code

sudo ir-keytable -c -w /etc/rc_keymaps/my_remote -s rc1
sudo ir-keytable -t -s rc1

Jetzt sollten nicht nur scancodes kommen, sondern auch Tastendrücke gemeldet werden. (Key up/down) [...]
Dabei verwende ich kein lirc. Um die Key-Events schließlich auf dem lirc socket zu melden nutze ich eventlircd.

Alles anzeigen

Vielen Dank, konnte nun auch endlich mal wieder direkt an die betroffene Maschine und die LIRC-Konfiguration wie folgt umwandeln:

Zitat von sudo -i

awk '{print $2 "\t" $1}' /etc/lirc/8in1_ir-keytable_-t_DVBSky.conf >/etc/rc_keymaps/Universal8in1
nano -w # überzählige Zeilen außer KEY_* rauswerfen
sudo ir-keytable -c -w /etc/rc_keymaps/Universal8in1 -s rc0
Old keytable cleared
Wrote 37 keycode(s) to driver
ir-keytable -t -s rc0 # erkennt nun KEY_* von größerer statt mitgelieferter Fernbedienung
evtest # listet die nun gültigen Codes auch auf für:
/dev/input/event5: cx23885 IR (DVBSKY T982)
service lirc stop
service inputlirc start
service vdr stop
service vdr start

Alles anzeigen

Jetzt gilt's noch den VDR unter Ubuntu 14.04 LTS so umzubiegen, daß er die Kernel-Events verwendet.
Ohne eventlircd (nicht im Standard-Repository?) schien das erst nicht zu klappen (nur CH+/- wurde erkannt, solange inputlirc aktiv ist, vgl. inputlirc mit vdr verheiraten ff), es laufen dann:

Zitat von ps aux|grep lirc

nobody 5874 0.0 0.0 12772 392 ? Ss 12:47 0:00 /usr/sbin/inputlircd -g -m 0 /dev/input/by-path/pci-0000:02:00.0-event-ir
root 6226 0.0 0.0 4440 652 ? S 12:57 0:00 /bin/sh /usr/sbin/runvdr -v /var/lib/video.00 -c /var/lib/vdr -L /usr/lib/vdr/plugins -r /usr/lib/vdr/vdr-recordingaction -s -E /var/cache/vdr/epg.data -u vdr -g /tmp --port 6419 --vfat -w 60 --lirc -P "xineliboutput --local=none --primary --remote=127.0.0.1:37890" -P streamdev-server -P femon
vdr 6240 11.6 0.8 834804 33364 ? Sl 12:57 0:00 /usr/bin/vdr -v /var/lib/video.00 -c /var/lib/vdr -L /usr/lib/vdr/plugins -r /usr/lib/vdr/vdr-recordingaction -s -E /var/cache/vdr/epg.data -u vdr -g /tmp --port 6419 --vfat -w 60 --lirc -P xineliboutput --local=none --primary --remote=127.0.0.1:37890 -P streamdev-server -P femon

irw erkannte allerdings alle KEY_*, es war also noch ein Neuanlernen nötig nach:

Zitat von sudo -i

service vdr stop
rm /var/lib/vdr/remote.conf
service vdr start && vdr-sxfe

Einen ewigen Bug gilt es weiterhin manuell abzustellen: https://bugs.launchpad.net/ubu…ineliboutput/+bug/1001818

Zitat von kls

Nachdem das Thema in diesem Thread ziemlich hohe Wellen geschlagen hat, habe ich beschlossen das nicht zu machen - auch wenn's noch so schön wäre... Ich werde gelegentlich den VDR User Counter etwas "aufhübschen" und die Möglichkeit schaffen, weitere Details einzugeben

Evtl. lässt sich ja Ähnliches auf anderem Wege so realisieren, daß viele User einen Vorteil darin sehen und sich freiwillig anmelden für dynamisches DNS und/oder Online-Schnittmarkentausch bzw. evtl. sogar auf einer (hinreichend groben) Karte erscheinen wollen?

Zitat von kls

"Nach hause telefonieren" hat bei Software wohl immer etwas Anrüchiges.

Es sind halt in den letzten Jahren zuviele Firmen (in Wohnzimmern wie auch bei Apps) mit oft großer Gier und ohne so verantwortungsbewusst und detailliert wie Du erst die Nutzerwünsche zu erfragen an die Sache herangegangen, was sicher sensibilisiert hat: FUSION: The walls have ears - all the smart gadgets are spying on you - und das ist noch einer der ausgewogeneren Artikel, vgl. folgendes vom Juraprofessor: SALON: I’m terrified of my new TV: Why I’m scared to turn this thing on — and you’d be, too

Zitat von kls

Ich werde eine entsprechende Mitteilung verbreiten, sobald ich ihn etwas modernisiert habe.

BTW, wenn aktuelle VDRs & Plugins über die nächsten 15 Jahre mehr in den großen Distros landen (vgl. Heise-Wishlists der echten Interessenten und "Nichttrolle" :]), könnten sich sicher auch aus den Downloadstatistiken von deren Paketrepositories einige Erkenntnisse gewinnen lassen?

Zitat von kls

Gibt es da vielleicht irgendwo eine Doku, wie die das genau machen? Vor allem auch, wie sie diese schöne Karte erzeugen (wobei da bei mir nur die Kreise mit den Zahlen angezeigt werden, keine eigentliche Karte).

Kann nur mit der Doku dienen, wie ich das mache:

Folgendes Format kannst Du an Google Earth oder My Maps verfüttern (seit ein paar Tagen leider nicht mehr anmeldefrei an die regulären Google Maps: https://developers.google.com/maps/support/kmlmaps - alternativ aber auch z.B. mit dem Button "Import data" auf http://umap.openstreetmap.fr/en/map/new).

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.0">
<Document>
  <name>KML ClientMap</name>
  <description>All my clients</description>


  <Placemark>
    <Point>
      <coordinates>6.79,51.22</coordinates>
    </Point>
  </Placemark>


  <Placemark>
    <Point>
      <coordinates>-73.37,42.69</coordinates>
    </Point>
  </Placemark>


</Document>
</kml>

Placemarks (mehrfach in KML-Datei wiederholbar) sind WGS84-Koordinaten; es gibt Dienste, diese (natürlich nach Zustimmung) aus Ortsangaben der Nutzer (z.B. http://ws.geonames.org) bzw. IP-Adressen (vgl. https://www.google.de/search?q=ip+to+location) o.ä. zu gewinnen.

Zitat von Copperhead

Gar nichts!

Außer dem Umstand, daß ein einschlägiger Anbieter wohl binnen kürzester Zeit versuchen könnte, diese Liste "at lawyerpoint" samt zugehöriger IP-Adressen und Zeitstempel in die Finger zu bekommen - und nicht auszuschließen ist, daß gerichtliche Hilfe ebenso "gründlich geprüft" wie weiland fürs Urmännle erfolgt.

Zitat von kls

Also wenn ich mir den Code so ansehe... macht er eigentlich genau das, was im MANUAL beschrieben ist:

Code

Note that the actual frame indicated by the an "end" mark will
not be included in the edited version of the recording. That's because every
recording (and every sequence of an edited recording) begins with an I-frame
and ends right before the next I-frame.

Danke für die Antwort; ich setze auch schon seit ca. 10 Jahren jede Endmarke jeweils manuell um 1-2 selektierbare Frames weiter "nach rechts".

Die Anregung wäre freilich, evtl. zumindest am Ende der Aufnahme z.B. die bis zum (über)nächsten I- fehlende Zahl an P/B-Frames als "Schwarzblende" einzufügen, damit der Ton ordentlich ausläuft und die von pram bemerkten Klötzchenartefakte unterbleiben.
Oder Du gibst eben sogar die Möglichkeit zum "Feinschnitt" auf Einzelframe-Ebene, da die Berechnung neuer Zwischenframes heute ja vermutlich keine unzumutbare CPU-Belastung mehr verursachen würde...

Zitat von kls

Nachdem im Diskussionsthread zu der Meldung bei Heise verschiedentlich geschrieben wurde, daß VDR ja nur von einer kleine Gruppe von "Bastlern" verwendet würde, und eigentlich ja schon "obsolete" wäre

"Heise, Deine Trolle" ist man da natürlich versucht zu seufzen - andererseits kam in dem Thread auch viel Sinnvolles herum, v.a. soweit/weshalb Interessenten der VDR-Einstieg bzw. -Betrieb nicht (schmerzfrei) gelungen ist: Vgl. kurze Zusammenfassung ab [Announce] VDR version 2.2.0 released - Celebrating 15 years of VDR! #73 ff.

Zitat von kls

schön wäre zu wissen, wie viele VDRs denn tatsächlich da draußen am laufen sind. [...] einzige zuverlässige Methode, die ich mir vorstellen kann, ein Automatismus. Ein VDR könnte z.B. bei jedem Start einen URL ansprechen (etwa http://vdr.tvdr.de/count) und sich dort als "aktiv" melden. Beim Herunterfahren könnte er sich wieder "abmelden". Das Ganze könnte völlig anonym vonstatten gehen (OK, die IP-Nummer wäre dem Server bekannt, mehr aber auch nicht).

Alles was sich z.B. Wireshark zwischen Wohnzimmer und Router schnappen kann, ist momentan ein aktiv bejagtes Politikum: http://fusion.net/story/49352/…adgets-are-spying-on-you/ "Open Season", wie einige Hersteller leidvoll erfahren mussten.

Reines Zählen wird, wie man wahrscheinlich von (al)pine erfahren kann, sicher meist abgelehnt, weil der (zumal neue) Nutzer skeptisch ist und seinen Vorteil darin nicht erkennt.

Es bietet sich aber an, zum (z.B. per Prompt bei der Installation vorgeschlagenen) Opt-In unter klarer Angabe von der Übertragung betroffener Daten zu motivieren, indem man es mit einer wiederbelebten, auch von Heise angeführten Idee verbindet:

Zitat von Seiner Zeit voraus

Eine zeitlang arbeiteten einige Nutzer daran, einen Web-Dienst zum automatisierten Tauschen der Werbeschnittmarken zu etablieren.

Das wäre wohl ein für viele ähnlich nützliches Feature wie für MP3s CDDB etc. oder die IMDB-Integration als Vorwarnung vorm Zappen zu schlechten Filmen, zumal lokale automatische Lösungen ja offenbar aktuell in Standarddistributionen schwer zum Laufen zu bringen sind, z.B. noad/markad unter Ubuntu 14.04 LTS.

Andere Alternative: Einen dynamischen DNS-Service unter griffiger Domain speziell für VDRs anbieten (gerade nach kürzlicher Einstellung des kostenlosen DynDNS) - auch das verbindet die (konkret angekündigte) Meldung zur Zählung mit einem konkreten Nutzen für den Nutzer (Fernbedienung per live oder vdradmind - die aber "in this day and age" bitte standardmäßig über SSL laufen sollten).

Zitat von MegaV0lt

Meinen herzlichen Glückwunsch zum 15. Jahrestag!
VDR ist DIE Open Source Software.

Hoffen wir, daß sie auch in DIE gängigen Distributionen Aufnahme findet (bei c't viel diskutiert, s.o.) - hörte Tobi arbeite für Debian Jessie daran?

Bislang scheiterten viele wohl schon an Kleinigkeiten oder jahrelang stehengelassenen Hürden, etwa allein bei Ubuntu (neben dem seit mehreren Releases unsäglich instabilen Suspend/Resume):
vdr defaults to auto-shutdown; Setup - Miscellaneous - Min. user inactivity (min): should be 0
vdr-sxfe --lirc from Unity launcher causes remote control keypresses to be detected twice or ignored
vdradmin-am preconfigured not to (auto)start
vdr-plugin-xineliboutput package: Default-enabled Goom Visualization grinds to a halt
Custom EDID needed on Intel & Nvidia - otherwise freezes most of the time when trying to use HDMI audio

Glücklicherweise hilft das Forum ja immer wieder, Fehler der Hardwarehersteller durch solche Innovationen abzumildern:
DKMS zum Bau proprietärer Treiber

BTW (Feature-Vorschlag zum Jubiläum?), könnte es sein, daß nach der VDR-Schnitt auch nach der Umstellung auf TS eigentlich immer noch ein paar schwarze Frames (sozusagen als lead-out) einfügen sollte, wie schon 2005 hier diskutiert?
Richtiger Endpunkt beim Schnitt berücksichtigt?

Zitat von TheChief

Na dann hoffen wir mal, dass bis dahin nicht noch mehr Gängelungen kommen: http://www.golem.de/news/pay-t…a-hd-vor-1502-112417.html

Wollte man nicht (mit aus Gemeinwohlgründen kaum vertretbarer politischer und behördlicher Rückendeckung) wiederum Verschlüsselei erzwingen, entstünden gar keine Kosten, die irgendwem aufzudrücken wären (und der Umwelt bliebe ein alljährlich abzutragender DRM-änderungsbedingt elektroschrottiger Receivermüllberg erspart).
Tja, DVB ist für andere mit tiefen Taschen eben einfach nur Politik und daher müssen auch wir sie machen: Kämpft um Eure VDRs!

Zitat von Mr_T

http://www.heise.de/newsticker/meldung/S…DR-2552972.html
...und es gibt auch ein paar nette Kommentare im Forum

Da stecken ein paar wichtige Anregungen für die nächsten 15 Jahre drin, vor allem weil man mal sieht, was wieviele warum vom VDR und seinen besten Plugins tragischer- und unnötigerweise abgehalten hat:
Fehlende aktuelle Verfügbarkeit im Standard der "großen gängigen Distros" scheint schlimmer als die Treiberkapriolen mancher Hardware-Hersteller.

Zitat von TEN

Dieses Projekt bietet sich doch eigentlich dafür an, es mit einem der nun umschaltbar erhältlichen 433&868MHz-Module wie CC1101 (Pollin.de 810257 oder aus günstigerer Quelle) wie etwa in http://forum.fhem.de/index.php?topic=24651.160 erwähnt zum "eierlegenden Wollmilchtransceiver" (IR+AM) aufzubohren:
Szenen-/Haussteuerung (Funksteckdosen, Licht, Leinwand, Rolläden etc.) könnte dann herstellerübergreifend ebenfalls LIRC übernehmen...
(In https://github.com/tandersson/…aster/rfbb_cmd/rfbb_cmd.c findet sich schon ein Vorbild für CUL.)

Zitat von jrie

Ich habe nicht vor, *dieses* Projekt mit AM „aufzubohren“.
Das wäre eher etwas für ein neues Projekt.

Habe selbst meinen LIRC mit einer IR2AM-433MHz-Funkbrücke verlängert und per Gegenstück diverse Funkfernbedienungen nach LIRC gesampled - das funktioniert seit dem letzten Jahrzehnt ganz gut.
Für eine elegantere Lösung am VDR kann ich leider nur den Vorschlag und keine Umsetzung liefern; freut mich aber, wenn es als Inspiration dient.

Dieses Projekt bietet sich doch eigentlich dafür an, es mit einem der nun umschaltbar erhältlichen 433&868MHz-Module wie CC1101 (Pollin.de 810257 oder aus günstigerer Quelle) wie etwa in http://forum.fhem.de/index.php?topic=24651.160 erwähnt zum "eierlegenden Wollmilchtransceiver" (IR+AM) aufzubohren:
Szenen-/Haussteuerung (Funksteckdosen, Licht, Leinwand, Rolläden etc.) könnte dann herstellerübergreifend ebenfalls LIRC übernehmen...
(In https://github.com/tandersson/…aster/rfbb_cmd/rfbb_cmd.c findet sich schon ein Vorbild für CUL.)

Zitat von zengaja

Danke für den Link.Du hast recht mit Deiner Vermutung, dass die Keytable hart im Modul steht.
Ich habe mir zum testen mal für das Harmony-Profil KLS VDR 1.6 die Codes mit irrecord ausgeben lassen und in die rc-dvbsky.c eingetragen:

Das ganze neu gebaut und installiert und es funktioniert!
Die vollständigen codes sind allerdings recht lang (z.B. 0x04000400000B33 für Pause) und führen zu einer type cast Warnung. Ich hab daher alles mal auf vier Hex-zeichen gekürzt (0X0B33) funktioniert genau so.

Nur was tun, wenn eindeutige Scancodes für die verwendete Fernbedienung über 16 Bit breit sein müssen (evtl. ja auch für Deine KEY_OK) ?
1420551805.261804: event type EV_MSC(0x04): scancode = 0xc0078
1420551805.814514: event type EV_MSC(0x04): scancode = 0xc0079
1420551807.349586: event type EV_MSC(0x04): scancode = 0x100060
Diese serviceintensive Sonderlocke statt der Standards unter /etc gehört dem Treiber doch ausgetrieben...

Unter DVBSky (Mystique TeCaBiX) LIRC ? ff beschäftigt sich auch ein weiterer Parallelthread mit den DVBSky-Fernbedienungen (speziell für die T982):
Auch dort scheint es so, als würden die normalen (ohnehin kaum zugänglich dokumentierten) Mapping-Mechanismen noch durch Abkürzungen der out-of-tree-Treiber umgangen:
Man kann durchaus Scancodes für bessere Fernbedienungen per ir-keytable -t (und die pulse/space-Zeiten per mode2) auslesen; die Schwierigkeit scheint, sie auf Tastendefinitionen weiterzugeben (zumal die Scancodes anderer Fernbedienungen länger als die von rc-dvbsky.c verwendeten 16 Bit erscheinen).

Zitat von hannemann

Danke für den Hinweis. Dann trage ich noauto mal besser ein

Alternativ laut Enna und vdrnfofs für vdr-ng-experimental/squeeze fuse in /etc/modules (half unter Ubuntu 14.04 LTS aber noch nicht).
Bzgl. ps2ts o.ä. für vdrnfofs habe ich bei Tobi mal angefragt, vgl. http://projects.vdr-developer.org/issues/2054 oder ggf. (wenn statt des FUSE der DLNA-Server transkodieren soll) auch durch unterschiedliche Dateiendungen nach Art von http://projects.vdr-developer.org/issues/1521 zu lösen.

Damit die DVBSky-Tasten von irw erkannt werden, muß In der /etc/lirc/hardware.conf offenbar DISABLE_KERNEL_SUPPORT="false" stehen.
Dementsprechend scheint ignoriert zu werden:

Zitat

#Chosen Remote Control
REMOTE="Linux input layer (/dev/input/eventX)"
REMOTE_MODULES=""
REMOTE_DRIVER="devinput"
REMOTE_DEVICE="/dev/input/event5"
REMOTE_LIRCD_CONF="devinput/lircd.conf.devinput"
#REMOTE_LIRCD_CONF="/etc/lirc/lircd.conf"

Alles anzeigen

Woher kommt das stattdessen tatsächlich von devinput verwendete Mapping (rc_dvbsky?) und wie kann es um eine weitere Fernbedienung aufgebohrt werden?
Es wird doch hoffentlich nicht hart aus der media_build-bst-13/v4l/rc-dvbsky.c (via daraus kompiliertem Modul) drübergebügelt?

Zitat von TEN

Interesse am "klassischen" LIRC ohne die Event-Geschichten, denn außer dem VDR soll an dieser Maschine ja eh nichts IR-fernbedient werden.
Driver cx23885, table rc-dvbsky: Wird die zusätzliche Fernbedienung evtl. hierüber weggefiltert?

Konnte mir noch nicht erschließen, wie man die Definitionen einer klassischen lircd.conf wie z.B. http://lirc.sourceforge.net/remotes/universal/8in1 für LIRC am DVBSky-T982-Empfänger & VDR erkennbar macht.
Hat jemand Hinweise dazu?
http://www.lirc.org/html/configuration-guide.html erklärt ",table" nicht wirklich und http://forum.kodi.tv/showthread.php?tid=101151 erscheint auch wenig passend.
http://atterer.org/mythtv-xmbc-remote-control-without-lirc zeigt zumindest die möglichen KEY_*-Namen.

Ich erhalte mit beiden Fernbedienungen (DVBSky und 8in1) pulse/space-Ausgaben von sudo mode2 -d /dev/lirc0, und zwar (anders als im traditionellen LIRC) selbst nachdem sudo service start sowohl für lirc als auch für inputlirc durchgeführt wurde.
irw und ir-keytable -t zeigen aber nichts, obwohl eine /usr/share/lirc/remotes/devinput/lircd.conf.devinput besteht.

So sieht es unmittelbar nach einem Reboot aus:

Zitat von ps aux|grep lirc

root 793 0.0 0.0 33108 960 ? Ss 14:01 0:00 /usr/sbin/lircd --output=/run/lirc/lircd1 --driver=devinput --listen --pidfile=/run/lirc/lircd1.pid
root 795 0.0 0.0 35336 1104 ? Ss 14:01 0:00 /usr/sbin/lircd --output=/run/lirc/lircd --driver=devinput --device=/dev/input/event5 --connect=localhost 8765
nobody 1275 0.0 0.0 12776 380 ? Ss 14:01 0:00 /usr/sbin/inputlircd -g -m 0 /dev/input/by-path/pci-0000:02:00.0-event-ir
root 3526 0.0 0.0 4444 656 ? S 14:01 0:00 /bin/sh /usr/sbin/runvdr -v /var/lib/video.00 -c /var/lib/vdr -L /usr/lib/vdr/plugins -r /usr/lib/vdr/vdr-recordingaction -s -E /var/cache/vdr/epg.data -u vdr -g /tmp --port 6419 --vfat -w 60 --lirc -P "xineliboutput --local=none --primary --remote=127.0.0.1:37890" -P streamdev-server -P femon
vdr 3582 1.2 0.7 303412 28456 ? Sl 14:01 0:00 /usr/bin/vdr -v /var/lib/video.00 -c /var/lib/vdr -L /usr/lib/vdr/plugins -r /usr/lib/vdr/vdr-recordingaction -s -E /var/cache/vdr/epg.data -u vdr -g /tmp --port 6419 --vfat -w 60 --lirc -P xineliboutput --local=none --primary --remote=127.0.0.1:37890 -P streamdev-server -P femon
user 4870 0.0 0.0 17432 936 pts/12 S+ 14:02 0:00 grep --color=auto lirc

Nach sudo service stop gegen inputlirc und lirc erhalte ich zumindest für die DVBSky-Fernbedienung irw-Ausgaben nach manuellem sudo /usr/sbin/lircd --output=/run/lirc/lircd --driver=devinput --device=/dev/input/by-path/pci-0000:02:00.0-event-ir bzw. /dev/input/event5
(Nur) danach erkennt zumindest Scancodes (wenn auch keine Tasten, im Gegensatz zur DVBSky) für die 2. Fernbedienung (8in1):

Zitat von ir-keytable -t

1420551805.261804: event type EV_MSC(0x04): scancode = 0xc0078
1420551805.261804: event type EV_SYN(0x00).
1420551805.814514: event type EV_MSC(0x04): scancode = 0xc0079
1420551805.814514: event type EV_SYN(0x00).
1420551807.349586: event type EV_MSC(0x04): scancode = 0x100060
1420551807.349586: event type EV_SYN(0x00).

Auch nach http://wiki.ubuntuusers.de/Lirc ist mir aber nicht klar, wie und wohin die Tastendefinitionen für die weitere Fernbedienung aus der "alten" /etc/lirc/lircd.conf übergeleitet werden müssen, damit sie ebenfalls durch devinput (zumindest nach manuellem Start von LIRC wie oben) erkannt werden.

Zitat von hannemann

Hast du den Reboot bereits getestet? Ist die Option noauto notwendig?

Jedenfalls unter Ubuntu 14.04 LTS, dessen Reboot sonst beim Versuch des Einhängens auf Tastendruck wartend stehenbleibt.

Zitat

Ich hab noch bubbleupnpserver installiert. Der kann die Aufnahmen dann fürs Handy oder Chromecast live transkodieren, falls der Server genug Reserven hat.

Viel Reserven hat ein HP N54L eben gerade nicht, und die Kombination VDRnfoFS + DLNA sollte ja gerade dazu dienen, .vdr-Dateien nicht transkodieren zu müssen (was aber vielleicht weniger CPU-intensiv sein sollte als zwischen Codecs).
Allerdings sind das wohl PES statt TS, notfalls auch alle vorab bulk konvertierbar wie diskutiert ab Script .vdr --> .ts bzw. http://www.linuxtv.org/pipermail/vdr/2010-August/023445.html ff.
http://forum.serviio.org/viewtopic.php?f=7&t=1202 zeigt leider keine Lösung, um das ressourcenschonend on-the-fly nur bei der jeweils benötigten Wiedergabe zu erledigen - gibt's eine DAU-kompatibel zuverlässige, gerne auch in VDRnfoFS + MediaTomb (wie [HowTo] Mediatomb LiveTV und Aufnahmen mit vdr (mit video/divx statt mpeg als Hack für TS - führt bei Samsung aber nur dazu, daß die Aufnahme ganz aus der DLNA-Liste "Video" verschwindet), http://ehc.ac/p/mediatomb/discussion/440751/thread/34a80a44/ und http://www.linuxtv.org/pipermail/vdr/2010-August/023447.html nahelegt: "I know I could transcode pes->ts with mediatomb or ps3mediaserver") oder dem vdr-plugin-upnp (falls noch gepflegt) ?
BTW, sollte Schneiden auf VDR >=1.7 nicht auch zu TS führen (und die 2GB-Beschränkung auch ohne VDRnfoFS umschiffen lassen) ?