TT 6400 und XBMC mit einer FB

  • Vorausgeschickt (siehe auch Thread "FF oder VDPAU"): für mich gilt in erster Linie mal: ein VDR ist ein VDR ist ein VDR. Das hier ist ein VDR-Forum, man sollte meinen das sieht hier die Mehrheit so. Jedenfalls bin ich mit meinen mittlerweile zwei 6400-basierten FF recht glücklich, was man von den zwei Jahren mit HD-VDRs auf vdpau Basis (einer selbstgebastelt, einer mit yavdr) bei mir nicht behaupten konnte. Jedenfalls was problemlosen stabilen Betrieb betrifft. Wer dauernd basteln _will_ (der Weg ist das Ziel) mag das anders sehen.


    Aber nichtsdestotrotz würde auch ich gerne wieder XBMC dazu installieren. Das passt nicht zum FF-basierten VDR? Naja. Man muss den Eingang umschalten. Ich bin ja ein Verfechter der "jede kleine Hürde ist zu viel"-Theorie, weil der Mensch von Natur aus faul ist, und deshalb Kleinigkeiten beim Komfort letztlich den Unterschied ausmachen können, wie (und ob) man etwas nutzt oder nicht. Aber den HDMI am TV umschalten - das ist wirklich machbar.


    Bleibt das Problem mit der Fernbedienung. Ich habe jetzt noch gar keinen XBMC installiert (keine Zeit), aber mal ein bisschen was "probiert".
    Ziel ist, dass man beides, also VDR und XMBC, mit der gleichen FB bedienen kann.


    Ein cat /dev/input/ir (per udev Link auf das richtige eventX) bei laufendem VDR zeigt: der VDR fängt offenbar alle events weg.


    Also folgendes Experiment:

    Code
    mkfifo /tmp/ir
    mkfifo /tmp/ir2
    cat /dev/input/ir | tee /tmp/ir /tmp/ir2 >/dev/null &


    Damit wird der ir input auf zwei "named pipes" in /tmp, ir und ir2, dupliziert.


    Den VDR (remote plugin) konfiguriert man nun auf /tmp/ir statt /dev/input/ir und startet ihn neu.


    Man installiert LIRC, konfiguriert es auf "Linux input event layer" (oder so ähnlich) und in hardware.conf als device wiederum statt /dev/input/ir nun /tmp/ir2.
    Und man startet irw.


    Ergebnis: der VDR lässt sich einwandfrei bedienen, gleichzeitig landet jeder FB-Tastendruck in der irw-Ausgabe.


    Statt irw sollte man eigentlich ohne Probleme auch den XBMC auf das lirc device setzen können.


    Natürlich muss man nun noch beim VDR, wenn man über die commands XBMC startet, die Reaktion auf FB events abschalten (und nach dem Beenden des XBMC wieder anschalten) - also im Startskript vor und nach dem XBMC-Aufruf. Dafür gibt es SVDRP Kommandos (REMO off/on, svdrpsend.pl). So hatte ich das auch schon bei meinem vdpau-VDR gemacht, hat einwandfrei funktioniert: der VDR läuft parallel weiter, aber reagiert einfach nicht auf die FB, solange XBMC läuft.


    Potentielle Probleme: die named pipes (ich kenne mich nicht wirklich gut damit aus) sind eine recht spezielle Sache: sobald nicht von beiden pipes die events auch abgenommen werden, bricht der Verteiler-Befehl (s. oben cat | tee..) ab. Man muss also, solange XBMC _nicht_ läuft, etwa per "cat ... > /dev/null" die events vom lirc-device abnehmen (habs probiert: das statt irw, und die FB im VDR tut auch). Ausserdem wäre es natürlich umgekehrt ein Problem, wenn VDR im Modus REMO off die events nicht von /tmp/ir abnimmt (hab ich nicht getestet, hoffe er ignoriert sie einfach nur, sonst müsste man wiederum einen cat>null beim XBMC-Start machen).


    Der Beweis muss also erst noch erbracht werden, dass das tatsächlich stabil so funktioniert. Aber vielleicht mag schon mal jemand mitdenken oder hat sogar vor mir Zeit, das in der Praxis real auszuprobieren. Viel Erfolg!


    Und vielleicht gibt es ja auch noch einen viel einfacheren, eleganteren oder problemloseren Weg (keine Abnahmepflicht?) als mit den named pipes, die events zu duplizieren. Unix-Kenner vor!

  • Hi,


    ist dafür nicht das external player plugin gedacht? Soweit ich weiss kann man auch die FB weiterleiten.


    Bezüglich VDPAU kann man nur sagen, dass es einem die HD Ausgabe im Gegensatz zur FF immerhin drei Jahre ermöglicht hat. Da ich jetzt abgesprungen bin zur Core-I Religion :) kann mir die Diskussion ziemlich egal sein. Man hat aber sehr viel über xorg und das Zusammenspiel mti Xine gelernt. Jetzt läufts so wie ichs immer haben wollte und macht wirklich Spass. Ohne VDPAU hätte ich das nötige Wissen über xorg.conf, xine und co. nicht gehabt.


    Gruß
    Atech

    HTPC:
    Softtware: Archlinux mit VDR aus Archvdr repo (1.7.31 mit softhddevice) und xbmc 12.2 Frodo stable
    Hardware: Coolermaster 260 mit Core I3 540, 4 GB Kingst. Ram, GA.H55M-D2H, PCIe 16X RiserCard, NVIDIA 430GT, TT3600USB, TT3650-CI USB, Samsung SSD 640, WD Blue 1TB (WD10TP), IR Einschalter, imon Display, mce FB und 12 Kanal Atmolight (4 Led Streifen) über DFatmo und Boblight

  • Irgendwie versteht ich den Thread nicht so ganz. Bei mir laufen VDR und XBMC mit Lirc auch ohne das ganze
    Gedöhns (bis auf REMO on/off). Ich verwende allerdings einen iMon Empfänger. Was genau ist jetzt der Zweck
    dieser Verbiegungen?

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB

  • Joa, mit lirc sollte es auch ohne gehen. Aber man muss dem VDR ja die Lirc Tastenbefehle abdrehen wenn xbmc laüft. Jedenfalls sollte bei Verwendung des externalplayer plugins auch das ganz normal ir plugin verwendet werden können um xbmc zu Steuern.


    Gruß
    Atech

    HTPC:
    Softtware: Archlinux mit VDR aus Archvdr repo (1.7.31 mit softhddevice) und xbmc 12.2 Frodo stable
    Hardware: Coolermaster 260 mit Core I3 540, 4 GB Kingst. Ram, GA.H55M-D2H, PCIe 16X RiserCard, NVIDIA 430GT, TT3600USB, TT3650-CI USB, Samsung SSD 640, WD Blue 1TB (WD10TP), IR Einschalter, imon Display, mce FB und 12 Kanal Atmolight (4 Led Streifen) über DFatmo und Boblight

  • ist dafür nicht das external player plugin gedacht? Soweit ich weiss kann man auch die FB weiterleiten.

    Kannte ich nicht. Auf den ersten Blick sagt mir die WIKI page dazu jetzt aber auch nicht viel.. aber ist immer schön, von potentiellen Alternativen zu hören.
    Generell hatte ich jetzt nicht vor, den XBMC als VDR-Frontend zu nutzen (davon versteht ich gar nichts), ich wollte ihn erst mal einfach nur parallel an den Start bringen, einfach für das übliche: Videos, Fotos, Musik..

    Irgendwie versteht ich den Thread nicht so ganz. Bei mir laufen VDR und XBMC mit Lirc auch ohne das ganze
    Gedöhns (bis auf REMO on/off). Ich verwende allerdings einen iMon Empfänger. Was genau ist jetzt der Zweck
    dieser Verbiegungen?

    Naja, stimmt schon: vermutlich könnte man auch gleich nur LIRC auf das /dev/input/ir der 6400 setzen, und beim VDR auch LIRC nutzen. Allerdings finde ich grundsätzlich das remote-plugin viel schöner/einfacher und wollte erst mal so wenig wie möglich an der gut laufenden VDR-Installation drehen.


    Und wie ist das bei LIRC, wenn man zwei Anwendungen gleichzeitig laufen lässt: bekommen die beide die events (ist ja erst mal auch nur ein normales device file, sollte also kein Unterschied zum /dev/input/eventX sein), oder nimmt wirklich VDR nach REMO off die events nicht mehr an, so dass sie dann (und nur dann) beim "Zweitverwerter" landen?


    Jedenfalls wurde in anderen Threads explizit die FB-Problematik als Hindernis genannt, warum mit einer 6400 kein HTPC mit XBMC neben dem VDR praktikabel sei (ich glaube von jemandem aus dem yavdr Team). Mein Ansatz lässt vermuten, dass das schon machbar ist. Wenn es eigentlich noch viel einfacher geht, umso besser (der Thread-Titel ist ja entsprechend allgemein formuliert). Allerdings bitte dann auch erst mal selbst austesten, ob es wirklich klappt. Ich werde meine Idee jedenfalls sicher noch ein bisschen weiterverfolgen, interessiert mich auf jeden Fall ob es letztendlich funktioniert. Kann nur noch ein bisschen dauern (zu wenig Zeit).

  • Jedenfalls wurde in anderen Threads explizit die FB-Problematik als Hindernis genannt, warum mit einer 6400 kein HTPC mit XBMC neben dem VDR praktikabel sei (ich glaube von jemandem aus dem yavdr Team).


    Die FB ist ja kein Problem, da gibts soviele Möglichkeiten das zu handhaben. Das Problem ist das VDR und XBMC ihr Video über verschiedene HDMI Ausgänge ausgeben.


    cu


    PS: Leider nutzen xbmc und vdr einen ziemlich seltsamen Weg um mit lirc zu komunizieren (fragen das lirc Device direkt ab). Das erschwert es etwas. Aber lösen kann man es.

  • Die entscheidende Frage ist: Welche Fernbedienung und welcher Empfänger ?


    Ich betreibe seit Jahren so ein System (siehe Signatur) nur halt mit der alten FF (Nexus 2.1) und XBMC mit VDPAU parallel. Das Composite-Video der FF bereitet der AV.Reciever auf - damit spare ich mir das unstablie Software-Bildergeschubbse von Xine/Xinelibout/vnsi/streamdev usw.


    Umschalten des AV-Recievers schaltet auch die Fernbedienungscodes um. Beide Codesätze sind in LIRC angelernt und bedienen jeweils das System welches soeben sichtbar ist. Ganz einfach. Ohne AV-Reciever ist es natürlich schwieriger - aber mit lernfähiger FB sicher auch möglich.


    Joe

  • Das externalplayer plugin kann die FB an andere Programme weiterreichen. Eine gute Anlaufstelle ist die Seite von wbreu. Soweit ich weis hat er dort die Verwendung des Plugins beschrieben. Ansonsten muss man eben sicherstellen, dass das Lircdevice entweder an den VDR oder an XBMC "verknüpft" ist. Da man das Lircdevice beim starten des VDRs festlegt wüsste ich jetzt leider keine Möglichkeit es ihm einfach zu entziehen.


    Gruß
    Atech

    HTPC:
    Softtware: Archlinux mit VDR aus Archvdr repo (1.7.31 mit softhddevice) und xbmc 12.2 Frodo stable
    Hardware: Coolermaster 260 mit Core I3 540, 4 GB Kingst. Ram, GA.H55M-D2H, PCIe 16X RiserCard, NVIDIA 430GT, TT3600USB, TT3650-CI USB, Samsung SSD 640, WD Blue 1TB (WD10TP), IR Einschalter, imon Display, mce FB und 12 Kanal Atmolight (4 Led Streifen) über DFatmo und Boblight

  • Die FB ist ja kein Problem, da gibts soviele Möglichkeiten das zu handhaben.


    Wie gesagt, da hatte ich explizit andere Aussagen gelesen. Die mögen ja falsch gewesen sein.


    Zitat

    Das Problem ist das VDR und XBMC ihr Video über verschiedene HDMI Ausgänge ausgeben.


    Das ist sicherlich ein Schönheitsfehler, aber eben wirklich kein KO-Kriterium, warum man sagen könnte, die 6400 eigne sich grundsätzlich nicht für einen HTPC.


    Zitat

    PS: Leider nutzen xbmc und vdr einen ziemlich seltsamen Weg um mit lirc zu komunizieren (fragen das lirc Device direkt ab). Das erschwert es etwas. Aber lösen kann man es.


    Na dann wäre hier die richtige Stelle, eine exemplarische, konkrete, definitiv funktionierende (getestete) Lösung mal aufzuzeigen. Oder mehrere, nicht alles passt für jeden.
    Bin gespannt.


    Aber bis auf weiteres plane ich eben auch meine "Verbiegungen" noch etwas weiterzuverfolgen. Muss ja keiner tun, der glaubt es anders besser hinzubekommen (oder der sich gar nicht für XBMC interessiert).


    DocViper


    Auch interessant, was man doch alles hinbasteln kann. Aber ich dachte jetzt schon eher an eine Lösung mit den vorhandenen Mitteln: eine 6400 mit dem eingebauten IR-Receiver, eine dazu passende FB und sonst nix was die HW betrifft. Das soll jetzt schon ein 6400-Thread sein, kein vdpau-Thread :)
    (Ja, auch ich habe davon zwei Jahre lang profitiert, keine Frage, war dankbar dass es das gibt, besser als nichts. Nur mit der 6400 hat es sich für mich erledigt. Meine persönliche Ansicht. Wobei, wenn es dann mal wirklich ans Installieren von XBMC geht, kann man es vermutlich auch wieder gut brauchen, wenn der auch HD-Videos zeigen können soll. Also bei nvidia-HW. Bei dem SandyBridge-Rechner wäre es dann wohl dieses vaapi.)



    Zitat

    Ansonsten muss man eben sicherstellen, dass das Lircdevice entweder an den VDR oder an XBMC "verknüpft" ist. Da man das Lircdevice beim starten des VDRs festlegt wüsste ich jetzt leider keine Möglichkeit es ihm einfach zu entziehen.


    Genau das hatte ich befürchtet. Demnach bräuchte man eben auch dann, wenn man auch beim VDR mit LIRC arbeitet, immer noch eine "Verteilerlösung" wie oben skizziert, wenn man den VDR weiterlaufen lassen will.


    Aber genug der Theoretisiererei, vielleicht komme ich heute Abend nochmal zu ein paar konkreten Tests.

  • hi jungs,


    vor nem ähnlichen problem stehen wir bei der mld auch grade. wir wollen unseren usern auch ermöglichen vdr hochfahren auf tt6400 wenn man xbmc per osd startet wird der vdr von der remote befreit und xbmc mit remote gestartet und back ANALOG.


    nun habe ich hier so gelesen und überlegt ob man das nicht inputlirc machen lassen kann. das verwaltet doch exentx's und gibt sie als /dev/lircd frei -> somit sollte der vdr und xbmc darüber bedient werden können.


    greetz MarMic

    SZVDR HD: Intel e5300@1,2ghz - Gigabyte GA-EP41-UD3L - 2GB ddr2 800 - Gainward G210 512mb - Silverstone LC16MR - Tevii s480 - Astra 19,2 - MLDHD-5.4 testing


    WZVDR HD: Intel g1610@1,6ghz - Intel DH61BE - Scythe Big Shuriken 2 - 4GB ddr3 1333 - Asus GT610 1024mb - Chieftec Hi-Fi HM-02 - Tevii s480 - Astra 19,2 - MLDHD-5.4 testing

  • Das ist doch mal ein interessanter Thread... ich habe unter LinVDR auch einige Mediacenterfunktionalitäten per VDR genutzt, aber seit der der Vorbestellung der 6400 hatte ich mir dann lieber konkrete Gedanken gemacht wie ich XBMC parallel zu VDR nutzen könnte. Meine Ursprüngliche Idee war es VDR und XBMC unterschiedliche Fernbedinungscodes anzulernen und dann beides über LIRC zu steuern. Da mein LIRC empfänger am neuen System aber nicht arbeiten möchte wie er soll bin ich auf Plan B ausgewichen. Der sieht nun so aus:


    - VDR über Remote-Plugin mit dem Empfänger der 6400
    - XBMC über den MCE Empfänger des Gehäuses
    - beides in der (bereits vorhandenen) Logitech Harmony angelernt
    - beim Wechseln der Aktion VDR <-> XBMC wird der HDMI Eingang am Fernseher umgestellt


    Der WAF ist dadurch nicht beeinträchtigt, da es für F keine Rolle spielt auf welchem Eingang was angezeigt wird. Das Umschalten erfolgt schnell und direkt und im neuen Bild ist XBMC dank Autostart sofort verfügbar.

    Now There's A lesson To Learn,
    Respect's not Given,
    It's Earned.
    --
    System : Gehäuse: techsoloTC-380 // HW: Atom 330 @ ASUS AT3IONT-I Deluxe, 4GB RAM, 2TB Samsung F4 EcoGreen HD204UI, TT6400 // SW: MLD 5.4 stable // Octopus NET S2 Max // Client: NVidia ShieldTV // LNB: DurSAT UK124

  • Das ist doch mal ein interessanter Thread...

    Freut mich, wenn es der ein oder andere interessant findet, und nicht nur der andere oder eine am Sinn zweifelt ;)


    Diskutiert worüber ihr wollt, solange es grob dazupasst.


    Mir selbst geht es aber eben darum, mit nur dem IR-Receiver der 6400 auszukommen. Und daher muss man dessen events ggf. vervielfachen, wenn es keinen anderen Weg gibt mit zwei "Verbrauchern" gleichzeitig daran zu horchen.


    Eine Harmony zum automatischen Eingangs-Wechsel ist natürlich nett und entkräftet auch noch dieses Argument - wenn man bereit ist eine zu kaufen und sich mit der "Programmierung" auseinanderzusetzen.


    nun habe ich hier so gelesen und überlegt ob man das nicht inputlirc machen lassen kann. das verwaltet doch exentx's und gibt sie als /dev/lircd frei -> somit sollte der vdr und xbmc darüber bedient werden können.

    Also ich weiss jetzt nicht was das spezielle an inputlirc ist (es gibt auch noch ein eventlirc), aber man kann ja nun (wie oben beschrieben) auch mit dem normalen lirc als "Receiver" ein /dev/input/eventX definieren. Der Punkt ist, ob man auf das entsprechende lircd device dann mehr als einen consumer gleichzeitig setzen kann, die beide alle events erhalten. Daran bestehen ja deutliche Zweifel, und daher bräuchte man die im Eingangs-Post vorgeschlagene Duplizierungs-Lösung (oder eine ähnliche / bessere).


    Die andere "Spur", der ich noch nicht weiter nachgegangen bin, wäre wohl eben das "externalplayer" Plugin.

  • Das external Player Plugin hat den Vorteil das es das live TV des VDR suspendet. Ferner kann es dabei auch gleich die FB deaktivieren. Also alles was man braucht.


    Alternativ kann es die FB im slave Mode setzen, dabei erhält der VDR nur seine Tastendrücke (z.B. Menü) und die restlichen bekommt das Pluign und sendet es zum stdin des gestarteten Programms. Allerdings brauchts da nen VDR Patch wenn man die INFO Taste durchreichen will. Ferner ist es fraglich ob XBMC mit den Tasten die über stdin reinkommen klarkommt (ich habe mir für freevo nen Wrapper Script geschrieben was das handelt).


    Ferner muss man da am external Player Plugin noch etwas basteln, da gabs mal nen Thread der nen Problem mit den Filehandels ansprach und ich denke das Plugin macht in der Form den VDR Watchdog kaputt *).


    cu


    *) Vermutung, nicht getestet. Jedenfalls verbiegt es SIGALRM

  • Natürlch funktioniert das mit lircd und 2 Abnehmern. Habe ich auch seit erscheinen der 6400 im Einsatz.
    Bei mir läuft der vdr immer und horcht auf das lirc Device, mit irexec wird auf Tastendruck Xbmc gestartet und die fb mit Svdrp deaktiviert. Ein weiterer Tastendruck beendet Xbmc und aktiviert die fb. Und mit meiner harmony wird der tv auch umgeschaltet. Lässt sich sicher mit der fb der 6400 auch erledigen. Aber vergiss das Remote Plugin und dev duplizierung oder was auch immer du gemeint hast.
    Alles was benötigt wird sind zwei scripte die mit irexec gestartet werden und der Rest läuft über lircd.


    MfG thomas

    VDR:
    Hardware: Thermaltake DH102, Zotac ION ITX-F-E, 2Gig Ram, TechnoTrend
    dual DVB-S2 6400, TechnoTrend Connect CT-3650,


    Software: EasyVDR 1.0

  • Natürlch funktioniert das mit lircd und 2 Abnehmern. Habe ich auch seit erscheinen der 6400 im Einsatz.


    OK, stimmt!
    Habe jetzt auch umgestellt: das remote plugin ist ja trotzdem im Spiel, man übergibt nur nicht das device per "-i /dev/input/ir" sondern per "-l /dev/lircd" und muss neu anlernen.
    Nun kann ich parallel zum VDR irw laufen lassen - oder in Zukunft dann eben XBMC (und währendessen per SVDRP die FB im VDR deaktivieren, wie ich es ja auch schon im ersten Post beschrieben habe). irexec werde ich wohl nicht verwenden, sondern einen Eintrag in commands, denn eine eigene Taste dafür kann ich nicht "abstellen", so viele hat meine FB jetzt nicht.


    Wunderbar, die dev-input-Duplizierung ist also wirklich überflüssig. (Aber hätte auch funktioniert :) )
    Anders als die /dev/input/eventX ist das /dev/lircd kein character device, sondern ein Socket. Darin liegt wohl begründet, dass mehrere Consumer gleichzeitig versorgt werden können.


    Damit dürfte die optimale Lösung für den Task laut Thread-Titel gefunden sein (mit nur dem eingebauten IR-Receiver).

  • Hi hivdr,


    sag mal, wozu brauchst Du denn noch das remote Plugin, wenn Du /dev/lircd als Eingang benutzt. Dann könnte das lirc device doch direkt dem VDR mitgegeben werden. Wo liegt da der Unterschied/Vorteil?


    Claus

    MLD 5.5 mit vdr 2.6 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM - WD Green 12TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.5 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.5 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT

  • sag mal, wozu brauchst Du denn noch das remote Plugin, wenn Du /dev/lircd als Eingang benutzt. Dann könnte das lirc device doch direkt dem VDR mitgegeben werden. Wo liegt da der Unterschied/Vorteil?


    Ganz einfach: ich wüsste nicht wie. Das kann auch sehr gut sein, dass ich es einfach nicht weiss, aber auch im LIRC-Artikel im VDR-Wiki finde ich beim Überfliegen keine explizite Anweisung, wie der VDR zu konfigurieren ist, aber dafür kommt die remote.conf vor.
    Also, wer weiss ob und wie der VDR auch ohne remote-Plugin mit LIRC zu steuern ist, kann es ja mal kurz erläutern.


    Aber was mich angeht, ist das so mit remote-Plugin eine sehr gut funktionierende Lösung.

  • Sofern LIRC läuft, kannst Du den VDR mit der Option:


    --lirc[=PATH] use a LIRC remote control device, attached to PATH
    (default: /dev/lircd)


    starten. Vorher kannst Du ja mal die remote.conf leeren, dann sollten die Dialoge zum anlernen
    erscheinen.


    XBMC und Lirc kannst Du dann mittels der Lircmap.xml verheiraten, musst aber beim Start von XBMC ein svdrpsend REMO Off an den
    VDR senden, damit die Fernbediung nur auf XBMC reagiert.

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB

  • Sofern LIRC läuft, kannst Du den VDR mit der Option:


    --lirc[=PATH] use a LIRC remote control device, attached to PATH
    (default: /dev/lircd)


    starten. Vorher kannst Du ja mal die remote.conf leeren, dann sollten die Dialoge zum anlernen
    erscheinen.


    Mit anderen Worten: die Datei remote.conf wird nicht nur vom remote-Plugin verwendet (wie das ja doch sehr naheliegend wäre), sondern ggf. auch vom VDR direkt ohne Plugin. Gut zu wissen. Aber das remote-Plugin stört auch nicht.


    XBMC und Lirc kannst Du dann mittels der Lircmap.xml verheiraten, musst aber beim Start von XBMC ein svdrpsend REMO Off an den
    VDR senden, damit die Fernbediung nur auf XBMC reagiert.

    Siehe auch allererster Post, trotzdem Danke!

  • Mit anderen Worten: die Datei remote.conf wird nicht nur vom remote-Plugin verwendet (wie das ja doch sehr naheliegend wäre), sondern ggf. auch vom VDR direkt ohne Plugin.


    Naheliegend ist das eigentlich überhaupt nicht, wenn man weiß, dass der VDR die remote.conf schon lange bevor der Existenz des remote-Plugins verwendet hat.

    Aber das remote-Plugin stört auch nicht


    Ansichtssache, wenn man bei der Fernbedienungs-Problematik einen etwas moderneren Ansatz verfolgt (eventlircd) dann stört das remote-Plugin schon.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!