Posts by vdrjoe

    Hi Hansp
    schön, dass es nun beinahe vollständig funktioniert.
    Die vom vompclient verwendeten Bezeichnungen (KEY_xyz) kannst Du im laufenden vompclient ja unter Einstellung->remote?? (sitze gerade nicht vor dem TV) überprüfen; und angeblich auch verändern (das habe ich noch nicht versucht).
    Dabei habe ich mich an die jeweils ersten Einträge je Key gehalten, wobei das "Key_" in der Lic.conf vermutlich zu ergänzen ist.
    Also so : "Gelbe Farbtaste ", in Lirc ="KEY_Y", ist im Vompclient einfach nur "Y".
    Bin mir dabei aber wieder nicht ganz sicher.
    cu


    btw. in Deiner lirc.conf , (nicht lircd.conf ! ) scheint ein Buchstabendreher drin zu sein:
    Zeile 46 heisst mit großer sicherheit "KEY_VIDEO_NEXT"

    Kann noch diese Links anbieten:
    Ein Hinweis aus dem MLD-Forum:
    http://www.minidvblinux.de/forum/index.php?topic=5323.0
    Da ist besonders dieser Satz wichtig:

    Quote

    Zum einen musst Du das uinput Kernel Modul laden. Das ist im libcec-daemon Addon enthalten. Möglicherweise darf aber nicht das libcec-daemon Tool laufen, da das auch uinput benutzen würde.


    das uinput-modul wird bei mir geladen:



    Das binary Addon derMLD kannst Du so (vermutlich) nicht gebrauchen.
    Hier ein Hinweis aus dem loggytronic-Forum, wie die libcec passend für den rpi auf desnselben kommen kann:
    www.loggytronic.com/vomp-pi.php
    Dabei insbesondere:

    Code
    1. wget "http://www.loggytronic.com/dl/libcec1_1.8.1-1_armhf.deb" dpkg -i libcec1_1.8.1-1_armhf.deb


    Eventuell ist der letzte Schritt (libcec installieren) aber überflüssig, falls das uinput-Modul von vornherein zum raspbian-image gehört; das MLD-image beschränkt sich auf das nötigste, Erweiterungen kommen dort per addon.
    Ich war so vorgegangen, um zunächst die gleiche Funktionalität des MLD-vompclient-image auf Basis von raspbian nachzubilden, also zunächst mit Steuerung per CEC.
    Dann habe ich mich mit lirc beschäftigt.


    Weiterhin viel Erfolg.
    Ich könnte Dir eventuell auch mein Image zur Verfügung stellen, ist aber 4GB groß.
    cu

    läuft bei Dir inputlirc?
    Habe in den von Dir genannten Anleitungen (welche ich damals u.a. auch genutzt hatte) keinen Hinweis darauf gefunden,


    Hier http://wiki.ubuntuusers.de/Lirc wird inputlircd erwähnt.
    Bei mir läuft inputlirdc auch:

    Code
    1. pi@raspberrypi ~ $ ps ax | grep lirc
    2. 2112 ? Ss 0:08 /usr/sbin/lircd --driver=default --device=/dev/lirc0 --uinput
    3. 2135 ? Ss 0:03 /usr/sbin/inputlircd /dev/input/event0
    4. 23289 pts/0 S+ 0:00 grep --color=auto lirc
    5. pi@raspberrypi ~ $


    also einfach per

    Code
    1. apt-get install inputlirc

    nach installieren.


    Das ist der Inhalt meiner /etc/default/inputlirc:

    Code
    1. # Options to be passed to inputlirc.
    2. EVENTS="/dev/input/event*"
    3. OPTIONS=


    Glaube aber, dass das der default Zustand ist. hier werden alle events (das "*") von inputlirc genutzt. Das kann eventuell Probleme bei der gleichzeitigen Nutzung Deiner USB-MCE hervorrufen.
    Siehe Hinweise unter meinem Link oben.
    Aber dein Ziel ist ja die Hauppauge IR-FB.


    Ich drücke Dir die Daumen!
    cu

    Okay, Du nutzt raspbian als Linux Distri auf dem rpi?
    mir fällt noch ein, dass ich die CEC-Bliliothek / Tools (was auch immer, habe ich leider nicht sauber dokumentiert :( ) von der Vompseite(loggytronic) installiert habe.
    Eventuell ist da ja etwas drin, was Dir bei meinem Setup noch fehlen würde.
    Ich schaue mir das Morgen noch einmal an.
    cu

    Hallo zusammen,
    ich überlege mir meinen VDR-Server auf einer neuen Hardware neu aufzusetzen.


    Hintergrund sind gelegentliche Aussetzer im derzeitigen Setup (s. Sig.) Das tunen auf einen (beliebigen) Kanal funktioniert gelegentlich einfach nicht, das Bild bleibt schwarz bzw die Aufnahme hat 0-Byte Größe. Unabhängig vom Wetter, aber schon abhängig von der Anzahl der verwendeten Tuner, also der laufenden Aufnahmen und dem Live-TV. Im syslog finde ich keine Hinweise auf das Problem.
    Manchmal hängt der Rechner beinahe völlig und reagiert nur sehr träge (Zugriff per ssh). Ein reboot beseitigt diesen Umstand dann sofort.
    Mein Bauchgefühl sagt mir, es könnte an irgendwelchen "race-conditions" beim Interrupt abarbeiten zusammenhängen.
    Das derzeitige Board soll auch Probleme mit manchen RAID-Controllern haben. Der gleichzeitige Betrieb mehrerer DD-Cine2 (bei mir drei) soll auch nicht "ohne" sein.
    Wobei diese Aussagen (meine Zusammenfassung andere Beiträge hier im Forum und anderer Quellen) irgendwie sehr im Nebel bleiben.
    Meine Hoffnung wäre nun, ein neues Board mit "funktionierender" (Hardware-) Interruptstrategie könnte diese Probleme vertreiben.
    Diese Hoffung ist natürlich auch sehr nebulös.
    Ich dachte da an ein Intel DH8RL7 oder DH87MC Mainboard, in der vagen Hoffung, Intel board , -Chipsatz, BIOS (Intel??) und CPU spielen am besten miteinander.
    Und in Anlehnung an den 10Watt Pc der c't an niedrigeren Verbrauch als meine jetzige Lösung (etwa 60-70Watt).
    Mir ist klar, dass die zusätzliche Peripherie wie HDD und eben die TV-Karten den Verbrauch maßgeblich mitbestimmen.

    Nun stellt sich die Frage nach der "richtigen" CPU. Eigentlich stellt keiner der auf dem Server aktuell laufenden Dienste eine Herausforderung an eine aktuelle CPU.
    Meine alte SD-TV-Server-Variante mit PIII-Board und VIA C3 hatte nur fürs Transkodieren nicht genug Puste.
    Allerdings lief dieses System absolut stabil, da will ich wieder hin, nur in HD und nach Möglichkeit genauso stromsparend.


    Macht es Sinn, für nur sehr gelegentlich notwendige Arbeiten direkt am Server eine Haswell-CPU mit integrierter Grafik zu nutzen?
    oder ist eine Ivy-Bridge MB/CPU Kombination mit einer zusätzlichen (Onboard-) Grafikkarte für meine Ziele gleichwertig bzw. besser geeignet?
    lässt sich der Verbrauch durch softwaremäßiges Abschalten der GPU (Haswell) weiter verringern?
    die Alternative, eine Textausgabe (nur console) im Bedarfsfall (also wenn die Kiste gerade "spinnt") per USB zuzuschalten (Displaylink) hat den meiner Meinung nach den Nachteil, daß eventuell das System soweit mit sich selbst beschäftigt ist, dass die notwendigen Initialisierungen eventuell nicht funktionieren.
    Und ganz grundsätzlich: Würde sich der Einsatz einer quad-core CPU mit zusätzlichem Hyperthreading überhaupt lohnen?,
    Nutzen der Linux-Kernel bzw. die DD-Treiber überhaupt mehrere Treads beim Interrupt / IO-Handling? oder macht "das" dann immer nur ein Kern?
    Dann würde wohl auch ein Dual-Core ohne Hyperthreading völlig ausreichen?


    Für jegliche Hinweise und Anmerkungen bin ich sehr dankbar.
    cu

    hallo hansp
    ich hatte damals auch so meine Schwierigkeiten mit demselben Vorhaben:
    Die original HAuppauge MVP FB zum Zusammenspiel mit dem vompclient zu bringen.
    Ich denke, es macht Sinn sich auf genau diesen Fall zu beschränken.
    (natürlich nur dann, wenn genau das Dein Ansinnen ist!)
    Meine Motivation war dieselbe: alle kenne sich mit der FB aus.
    Es gibt in diesem Bereich offenbar einfach sehr viele Möglichkeiten um zum Ziel zu kommen.
    Bei Nutzung meiner lircd.conf benötige ich z.B. keine evmap. Es ginge nach meinem Verständnis auch anders, allerdings mit dem weiteren Zwischenschritt über eine evmap.


    Ziel ist es, genau die Keys zu generieren, welche die Zielapplikation als default erwartet. Finde ich jedenfalls.
    Vompclient wird per default über CEC bedient, also sind die Keys das Ziel, welche auch dort verwendet werden.
    Es gibt z.B. für die Nummertasten mehrere Sätze von Definitioen, der vompclient (meiner, direkt aus den damals aktuellen Sourcen) mag aber (ohne die vompclient interne Keytab zu ändern) nur die folgenden
    z.B.aus meiner hauppauge.conf:

    Code
    1. KEY_1 0x1781


    und nicht den Keycode aus Deiner lircd.conf

    Code
    1. KEY_NUMERIC_1 0x17C1


    Der meiner Meinung nach bedeutende Unterschied ist die Tastenzuordnung (KEY_1 vs. KEY_NUMERIC_1)


    Mit KEY_NUMERIC_1 kann der vompclient ootb nix anfangen, auch wenn dieser Code bis zur Application durchgedrungen ist.
    Als Workaround könnte nun eine evkeymap ins Spiel kommen, was die Sache angesichts der anderen Lösung aber nur komplizierter macht.
    Ich brauche keine zusätzlichen Optionen zu setzen, ausser den in meinem ersten Post genannten.
    Der Unterschied im IR-Code (zweite Spalte) ergibt sich nach meiner Vermutung aus den unterschiedlichen Definitionen im Header der hauppauge bzw. lirc.conf
    z.B. die Bitlängen von "0" und "1", da spielt dann vermutlich auch der verwendete IR-Empfänger noch ein Wörtchen mit (36kHz vs 38kHz)
    Meine Version:

    Code
    1. bits 13
    2. flags RC5|CONST_LENGTH
    3. eps 30
    4. aeps 100
    5. one 927 840
    6. zero 927 840
    7. plead 950
    8. gap 112644
    9. min_repeat 1
    10. toggle_bit_mask 0x800


    Deine Version:


    Bitte korrigiert mich. falls das Unsinn ist!


    Ich hatte bei meiner Recherche nur lircd.confs mit deutlich unterschiedlichen Inhalten zu meiner "finalen conf" für die Hauppauge gefunden.
    ABER: mit "meiner" funktioniert der vompclient ohne weitere Maßnahmen mit der (neuen) MVP Fb.


    Was bei mir bisher nicht funktioniert ist das Springen in der Senderauswahl mit KEY_FASTFORWARD bzw. KEY_REWIND.
    Das könnte aber auch am vompclient liegen, da diese Keys beim Spulen in der Aufnahme durchaus funktionieren.


    Ich vermute also, "im Prinzip" funktionert schon das Meiste in Deinem Setup, Du nutzt nur die "falschen" KEY-Bezeichnungen.
    Viel Erfolg
    Jörg

    Ich weiß nicht, ob Du noch Hilfe brauchst.
    Leider weiß ich nicht mehr alle Schritte, welche bei mir zum Erfolg führten, aber ich versuche 'mal meine Konfigurationsdateien zu listen:


    meine /etc/lirc/hardware.conf:



    die /etc/lirc/lircd.conf:

    Code
    1. include "/etc/lirc/hauppauge.conf"


    die hauppauge.conf im selben Ordner:



    der inhalt von /etc/default/inputlirc:


    Code
    1. # Options to be passed to inputlirc.
    2. EVENTS="/dev/input/event*"
    3. OPTIONS=


    Ich hoffe, ich konnte helfen


    vdrjoe

    Nur so als Zwischenfrage: warum benötigst Du eine FB am vompserver? Am vompclient würde ich das ja eher verstehen.
    Welche Distri verwendest Du auf der Himbere?


    Ich habe den raspberry pi als HD-Vompclient laufen. Da meine Logitech bereits wegen der "alten" MVPs die neue Hauppauge MVP kannte, war es der loische Weg, den vompclient ebenfalls auf diese FB anzulernen.
    Da mein Sony-TV unter MLD (vompclient-image) nicht dauerhaft korrekt per HDMI-CEC mit dem vompclient zusammenspielen wollte, habe ich (offenbar ähnlich wie Du)
    dem rpi einen IR-Empfänger spendiert und hatte untzer MLD das Problem, dass der Kernel der MLD das GPIO-Infrarot-Modul nicht unetstützt.
    Es war dann einfacher, den vompclient unter raspian selbst zu übersetzen. Aberr soweit bist Du ja offenbar auch schon.


    Ich habe auch einige Zeit gebraucht, um alles zum Laufen zu bringen. Läüft denn lirc?


    Wenn Dein setup ähnlich sein sollte, kann ich gern die Einstellungen inklusive funktionierender lirc.conf für die weiterverarbeitung per eventlirc vom rpi auslesen.

    Wenn Du Dich mit der etwas spartanischen VOMP-Oberfläche anfreunden kannst, wäre die Kombi VDR-Server mit vompserver-plugin plus Raspberry-Pi-Vompclients (z.B. per MLD-Distri) eine praxistaugliche Lösung, welche billiger als HD-taugliche Clients-PCs ist. Auch entfällt die aufwändigere Installation mit Streamdev und remote-timer etc und das "drehen" an den VDPAU-Parametern (meine ehemalige ZBOX hatte IMMER Microruckler, auf dem rPI mit vomp gibt es die nicht).
    Meine Familie und ich sind damit sehr zufrieden.

    führe dann 'mal meinen Monolog fort:


    es scheint, "fbcon" fehlt, das ist auf meinem System nicht vorhanden und ist per apt-cache search auch nicht zu finden (scheint ein Kernelmodul zu sein??)
    Schaue ich mir die Posts mit dem "umgekehrten" Anforderungsprofil an (d.h.grafische Oberfläche vorhanden, das Displaylink soll als Zusatz-Anzeige und nicht als Konsole dienen)
    sind die auch für meinen Zweck notwendigen Tools dort offenbar ootb vorhanden.


    Ein Weg könnte es sein X-11 nachzuinstallieren, aber nur um den "letzten Schritt" zu tun?
    Ich brauche keine GUI auf meinem Server (okay, im Moment ev. schon)


    Ich habe ja bereits eine login-shell, nur hängt sich die Anzeige nach erfolgreichem login weg.


    Für Tips bin ich weiterhin dankbar.

    Hallo
    bei dem Wetter habe ich mein altes "Projekt" "direkter Consolen zugang ohne VGA-Karte" hervorgeholt:
    Ziel ist also:
    der USB-Displaylink-Adapter soll die VGA Karte ersetzen (PCI-Ports sparen)
    Ich habe kein X auf dem Server, möchte nur bei Bedarf mehrere virtuelle Consolen nutzen.
    Noch ist die alte VGA-Karte im System.
    Ich habe

    Code
    1. cat /etc/issue
    2. Ubuntu 12.04.2 LTS \n \l

    in der Server-Variante.
    udlfb wird geladen

    Code
    1. root@server:/etc/init# lsmod | grep udlfb
    2. udlfb 23492 1
    3. fb_sys_fops 12667 1 udlfb
    4. sysimgblt 12806 2 udl,udlfb
    5. sysfillrect 12901 2 udl,udlfb
    6. syscopyarea 12596 2 udl,udlfb


    ich erhalte auch einen Konsolen-Login, doch danach ( übliche Anzeige mit Systemlast etc.) friert die Anzeige ein (mit Bildstörung) und das System lässt sich nur noch über ein Netzwerk-Terminal bedienen.
    Es gibt nur ein Framebufferdevice

    Code
    1. ls -l /dev/fb*
    2. crw-rw---- 1 root video 29, 0 Sep 11 14:37 /dev/fb0


    Code
    1. cat /sys/class/vtconsole/vtcon0/name
    2. (S) VGA+
    3. cat /sys/class/vtconsole/vtcon1/name
    4. (M) frame buffer device


    Werden eventuell die falschen Fonts oder dergleichen benutzt, da das System ursprüglich ja wohl kein Framebufferdevice für die VGA-Karte angelegt hat?
    Wo kann ich weiter suchen?
    Bin für jeden Hinweis dankbar.

    Hallo,


    ich kenne die Forenregeln, glaube aber dennoch eher hier eine Antwort zu erhalten.
    Da es ja alternative Lösungen zum Betrieb einer legal erworbenen Abokarte unter Linux gibt,
    meine Frage, ob mit einer beiden in Frage kommenden "bösen" Plugin-Lösungen dann der Content per Vomp-server an einem vomp-clienten geschaut werden kann?


    2. Frage zu diesem Thema:
    läuft eines der Plugins unter VDR 2.0x?


    Danke und Gruß

    so, habe es 'mal über Windows (SD-Karte im PC-Cradreader) probiert:
    die dort im "root"-Verszeichnis sichtbare config.txt hattte nicht meine per ssh ( putty) und vi ergänzten lizenz-keyes.
    Mit Notepad++ schnell die Einträge unter Windoes ergänzt und ab in den Pi.
    Ergebnis:

    Code
    1. MLD> vcgencmd codec_enabled WVC1
    2. WVC1=enabled
    3. MLD> vcgencmd codec_enabled WVC1
    4. WVC1=enabled


    Ob ich nun auch SD auf dem vompclient gucken kann muss ich noch testen.
    cu
    <edit> ja, SD geht nun auch!! :D </edit>

    Habe gerade die Lizenzkeys fürt MPEG2 und WVC1 erhalten und per putty und vi unter MLD in die /config.txt eingetragen.
    Doch weder "reboot" noch Hard-Reset per Netzteil ziehen führen nachfolgend zum Erfolg.
    vcgencmd codec_enabled MPG2
    oder
    vcgencmd codec_enabled WVC1
    sagen immer "disabled"
    was mache ich falsch?
    ist die /config.txt im root von MLD das richtige config file?
    Die Lizenzkeys habe ich wie gesagt per copy&paste per putty übertragen, die serialnumber stimmt auch.


    Im posditiven Fall sollten dann doch auch die SD-Kanäle unter rpi-vomp zu sehen sein, oder muss dazu etwas am server-plugin verändert/eingestellt werden?
    Bin wie immer für jeden Hinweis dankbar

    pepino :

    Quote

    Da Sony kein Firmware-Update mehr liefert ist dieser Fehler natürlich ein wenig doof.


    Gab es denn überhaupt einmal von Sony ein Update für den KDL40W4500/4750 ?
    Als ich vor zwei Jahren 'mal im Sony center nachgefragt hatte, haben die etwas sparsam geschaut.
    Bei einem damals schon 3 Jahre alten Gerät ein Update?


    Kaufen Sie doch ein neues haben sie allerdings nicht gesagt.
    Nett war noch das zufällig mitgehörte Verkaufsgespräch bzgl. Tablett <-> TV Interaktion:#
    "Ach, sie haben noch ein iPAD?" (Gibt offenbar noch mehr Hinterwäldler ;)

    @ MartenR

    Quote

    Tastatur sollte gehen, Fernbedienung auch wenn diese vom Kernel als input/event device unterstützt werden (ungetestet).


    also meine USB-Tastatur scheint zwar zu funktionieren (NUM-Lock lässt sich toggeln) aber weder über die Pfeiltasten nochr über Ziffern-Anwahl erhalte ich eine Reaktion.
    aber ARD HD (Pokal) läuftr schion seit > 1h ohne Ruckeln oder sonstige Probleme, selbst die Kanalwechselzeiten sind besser als beim meiner Zbox über Streamdev!
    Bin immer noch begeistert!!

    1-2x täglich würde den hart erarbeiteten WAF ganz erheblich senken, dann werde ich mich mal um nach einer IR-Lösung umsehen.
    Funktioniert die Steuerung per CEC denn mit Deinen anderen Geräten problemlos an dem Sony-TV? Dann gäbe es ja noch Hoffung.
    Ich habe CEC bisher nie genutzt (bzw. gar nicht gekannt) und 'ne Harmony für alle Geräte genutzt.
    Nochmals Danke für den zielführenden Hinweis.

    Danke das war's!


    Wie oft passiert das so bei Dir (ich hatte das Problem ja bereits nach 1 h!)
    Das Sony keine Firmware-Updates bietet ist auch echt schwach.
    Gut, die Kiste ist mittlerweile knapp 5 JAhre alt, aber hat auch etwa das fünffache des nueun Samsung meines Schwiegervaters gekostet, das Ding hätt' ich eigentlich auch gern.