Beiträge von S:oren

Zitat von S:oren

Ich haette auch noch andere Problemchen und Aenderungsvorschlaege fuer den Treiber, sind solche patches hier erwuenscht oder soll ich die lieber woanders hin (oder ueberhaupt nicht) schicken?

Leider gab es keine Antwort auf die Frage. Auch sonst scheint sich momentan leider niemand um den Treiber fuer die S2-6400 zu kuemmern, was besonders aergerlich ist, weil er nicht im kernel drin ist. Da ich aber hier gebeten wurde, einen weiteren patch zu posten, mache ich das mal: saa716x-workqueue.hg.diff
Der patch konvertiert das fifo_worker-Tasklet in einen workqueue-Thread, was dann zu deutlich stabilerem Verhalten auf einer langsamen cpu (Marvell Kirkwood) fuehrt. Weitere Erklaerungen gibt es auch in dem verlinkten Thread.

Gruss,
S:oren

Edit: Dieser Patch hat moeglicherweise Probleme auf Multicore-CPUs. Also bitte mit Vorsicht benutzen und im Zweifel auf ein Update warten...
Edit2: neue Version des Patches hier

Zitat von kls

Die Abfrage, ob überhaupt zu löschende Aufnahmen in der LIste sind dient eigentlich dazu, den Thread nicht unnötig anzuwerfen. Da die Liste typischerweise ja nur wenige Einträge enthält (die meiste Zeit wohl eher ganz leer ist) sollte das doch eigentlich nicht stören. Ansonsten läuft der Thread einmal pro Minute und müllt das Logfile zu.
Bist du wirklich sicher, daß diese Änderung auf deinem System etwas bringt?

Ich war damals der Meinung, dass es was gebracht hat. Wie das mit gelegentlichen Rucklern so ist, bin ich mir aber nicht sicher.
Ein Kurztest ohne diesen Patchteil hat gerade keine Verschlechterung gebracht. Waere also evt. sinnvoll, den Teil erstmal rauszulassen und dann nochmal Langzeittests zu machen.
Andererseits haengt die gefuehlte Geschwindigkeit des vdr (Fernbedienung, OSD) ja gerade vom Reaktionsverhalten des Hauptthreads ab. Sollte man da nicht alles auslagern, was moeglich ist? Zumal die Infrastruktur ja da ist und der Code nur uebersichtlicher wird. Aber nur so als Ueberlegung, den Teil habe ich zugegeben nicht intensiv einzeln getestet.

Zitat von kls

Hat es einen Grund, warum die Ausgabe der EPG-Bugfix-Statistik hier rausfliegen soll?

Upps, da war ich wohl etwas uebereifrig. War keine Absicht.

Zitat von kls

Damit wird der "epg data cleanup / dump"-Thread auf jeden Fall alle 600 Sekunden angeworfen. Da lastCleanup dann immer gleich lastDump gesetzt wird, würde lastCleanup quasi überflüssig.

Richtig. Macht es Sinn, ungecleante Daten rauszuschreiben, zumal das Cleanup (bei mir) etwa zehnmal schneller als das Schreiben ist? In einem low-prio-thread stoert das haeufigere Cleanup auch nicht, oder hat es irgendwelche Nachteile?

Zitat von kls

Außerdem wird in vdr.c am Programmende

cSchedules::Cleanup(true);

aufgerufen, und da wird davon ausgegangen, daß die epg.data-Datei geschrieben ist, nachdem der Aufruf zurückkehrt. Mit dem separaten Thread kann es aber wohl durchaus passieren, daß das Schreiben mittendrin "abgewürgt" wird, wenn das Programm endet - oder übersehe ich da was?

Das habe ich wohl uebersehen und beim Beenden des vdr immer ein paar Minuten zu alte epg-Daten gehabt. Ist mir nicht aufgefallen.

Soll ich einen neuen patch mit den besprochenen Aenderungen vorbereiten, oder hast du das eh schon bei dir passend gefixt? Ist es generell besser, patches per email zu schicken, wie von Copperhead angemerkt?

Eine Sache habe ich noch: Die Aufnahmeverzeichnisse werden bei mir nicht richtig sortiert (im time-Modus), dieser patch hilft:

--- vdr-1.7.30/recording.c.orig2	2012-09-18 21:07:52.000000000 +0200
+++ vdr-1.7.30/recording.c	2012-09-18 21:35:33.000000000 +0200
@@ -816,7 +816,7 @@ char *cRecording::StripEpisodeName(char
   if (s1 && s2) {
      s1++;
      memmove(s1, s2, t - s2 + 1);
-     *s1 = 0xFF; // sorts folders before plain recordings
+     *s1 = 'z'; // sorts folders before plain recordings
      }
   return s;
 }

Ist das von irgendwelchen locales abhaengig (bei mir Debian wheezy, de_DE.UTF-8 ) ? Kann es sein, dass 0xFF bei UTF8 nicht sinnvoll interpretiert werden kann? Vielleicht gibt es auch irgendwas besseres als 'z', aber so sieht es bei mir erstmal gut aus...

Gruss,
S:oren

Zitat von NemoN

- Wie stabil läuft das ganze?
- VDR und 6400 Treiber laufen probemlos als ARM version?
- Wie hoch ist der Stromverbrauch des laufenden Systems?
- Hast du ein Gehäuse gebaut?
- Wie anspruchsvoll sind die Umbau/Lötarbeiten? (Ich weiss wie rum ich einen Lötkolben anfassen muss, aber für SMD Löten bin ich zu grobmotorisch

Edit: mit meiner 6400 im PC bin ich leider nicht zufrieden, deswegen die Überlegung ob sowas auch für mich machbar ist...

• VDR, Guru und S2-6400 laufen sehr stabil.
• Fuer den vdr hatte ich ja einen patch gepostet, der es stabil macht. Normalerweise ist der ARM bei HD-Wiedergabe noch 50% idle, aber bei EPG-Writes oder OSD-Aktivitaet ist es von Vorteil, wenn die "unwichtigen" VDR-Threads eine niedrigere Prio haben. Leider will die S2-6400 alle Daten (OSD oder TS) in einzelnen 32-bit-Haeppchen haben, keine PCIe-Bursts, kein DMA, schon ziemlich aergerlich. Da geht die ganze CPU-Power fuer die Datentransfers drauf, wobei das alles kernel-Zeit und beim TS-Fifo - noch schlimmer - sogar Soft-IRQ-Zeit ist. Das macht es dem Prozess-Scheduler ziemlich schwer, mit sinnvollen Thread-Prios hat er es dann etwas leichter.
  Fuer den Treiber habe ich noch einen patch (eben gerade die Vermeidung der Soft-IRQ-Last durch Konvertierung des FifoWorker-Tasklets in einen Workqueue-Thread), den ich noch nicht gepostet habe, da es auf die ersten beiden geposteten patches keinerlei Reaktion gab. Am Treiber scheint momentan ueberhaupt nicht mehr weiterentwickelt zu werden. Hat ueberhaupt jemand in letzter Zeit von powarman gehoert?
• Neue Zahlen zur Stromaufnahme gibt's im ersten Post.
• Habe das modifizierte Guru mit Distanzbolzen auf den Boden meines alten miniITX-Gehaeuses geschraubt. Die originalen Guru-Anschluesse plus die Buchse fuer den 12V-Hohlstecker des neuen Steckernetzteils schauen hinten an der ATX-Blende raus.
• Am Guru ist alles SMD, davor darf man beim Umbau natuerlich keine Angst haben. Die kleinen (0402) Teile muss man ja nur entfernen (da ist die kleine Bauform eher von Vorteil). 0805 und QFP kann man ja noch mit einem normalen Loetkolben bearbeiten. Der Pitch auf den Platinenverbindern ist 0.8mm, also auch nicht sooo schlimm. Die SMD-Teile auf dem Zwischenboard will man nicht wirklich alle selbst bestuecken, hab ich beim pcbpool machen lassen.
• Wenn die S2-6400 auf dem PC fuer Dich nicht zufriedenstellend laeuft, warum sollte das mit dem guru besser sein? Oder was ist das Problem?

seahawk1986:
Das Guru ist - meiner Meinung nach - ein China-Design und auf Preis und nicht Effizienz optimiert. Auch ich habe beim Umbau nicht auf das letzte Milliampere geachtet, da ist sicher noch mehr drin. Allerdings kennt der Kirkwood kein Clock- und Voltage-Scaling, da ist die Idle-Power eben nicht super-gering. Dafuer steigt die active-Power dann auch nicht allzu sehr. Man koennte den Kirkwood natuerlich generell langsamer takten, man muss nur ein paar bootstrap-Widerstaende umloeten.

@Mreimer:
Vielen Dank!
Der Guru-Umbau ist natuerlich fuer eine beliebige PCIe-Karte geeignet. Die PCIe-Buchse (Sullins NWE18DHRN-T941) ist an der Stirnseite der Zwischenplatine (das schwarze im rechten Bild).
Die Steckerbelegung der Platinenverbinder kann man dem Schaltplan entnehmen. In dem gezeigten Testaufbau ohne Platine habe ich fuer die drei PCIe-Signalpaare (clk,in,out) jeweils ein Stueck eines alten PATA-Flachbandkabels genommen, immer eine Masseleitung links und rechts neben den beiden Signaladern, funktioniert erstaunlich gut. Fuer ein Guru-PCIe-Umbau ohne Zwischenplatine wuerde man vermutlich diese drei 4er-Strippen an der originalen Aufsteckplatine anloeten. Dann braucht man an der PCIe-Buchse minimal noch 3.3V und PCI-Reset (POWERGOOD_PERST#), siehe Schaltplan.
Weitere Fotos gibts momentan nicht, muss ich erstmal schoen aufbauen

Zitat von hepi

Warum DVB-C? Wie geht das? Ich besitze keine S2-6400, aber nach meinem Verständnis sind es Sat-Tuner. Kannst Du das erklären?

Ja. Ich habe einfach nicht ueberall Sat. So nehme ich alternativ einen USB-DVB-C-Stick. Zu irgendwas muessen die vielen USB-Buchsen ja gut sein
Fuer den patch im anderen Thread ist der transfermode gerade wichtig, weil sonst das Hostsystem fast nichts zu tun hat. Der ist nun aber auch nun wieder nicht so aussergewoehnlich, da der zweite Sat-Tuner der S2-6400 auch nur im transfermode laufen kann.
Ansonsten ist es natuerlich besonders sinnvoll, wenn man neben dem Decoder der S2-6400 auch die Tuner nutzen kann, keine Frage.

Gruss,
S:oren

Aehm, wie naeher? Hab doch schon ein halbes Buch geschrieben!?
Im Ernst, zunaechst mal vielen Dank fuer das Interesse, ansonsten duerfen die Fragen gerne - zumindest etwas - spezifischer sein. Oder steh ich gerade auf der Leitung???

Zitat von NemoN

könntest du das in einem extra Thread bitte machen? Danke

siehe hier:HD-VDR mit S2-6400 und GuruPlug ServerPlus

Ich wurde gebeten, ein paar Worte zur Modifikation eines GuruPlug ServerPlus fuer den Betrieb mit einer TT S2-6400 zu sagen. Ich bin nicht sicher, was hier von Interesse ist. Ihr koennt gerne Fragen stellen und ich ergaenze dann (bei Gelegenheit) entsprechend.

Das GuruPlug ServerPlus ist ein kleiner ARM-Server mit Marvell Kirkwood Prozessor-Soc (armv5te, 1200MHz), WLAN802.11g, 2x Gigabit-Ethernet (marvell), 2x USB 2.0, 1x eSata, microSD-Slot in einem Steckergehaeuse und wohl nicht mehr neu zu bekommen.

Das Original-Design besteht aus 2 aufeinander gesteckten Platinen + internes 5V-Netzteil, es hat 3 Probleme

• ausgepraegte Hitzewallungen bei Gigabit-Betrieb
• damit zusammenhaengend Instabilitaeten (reboots)
• gelegentlich sterbende USB-Ports bei Hotplugging

Zur Loesung dieser Probleme habe ich folgende Umbauten vorgenommen:

• Betrieb mit einem externen Steckernetzteil
• Nutzung des frei werdenden Platzes fuer 2 echte Kuehlkoerper auf Kirkwood und Gigabit-PHY statt des originalen "Waermeverteilblechs"
• Entfernung des Widerstands R11 neben dem WLAN-Chip, weil sonst die 1.2V-Spannungswandler fuer den Gigabit-Phy und im WLAN-Chip gegeneinander treiben, keine gute Idee und der Hauptgrund fuer Hitzeentwicklung und Instabilitaeten
• Austausch des Originalen USB-Hub-Chips GL850G gegen einen CY7C65632AXC. Der uebersteht auch Hotplugging und verbraucht nur die Haelfte Strom.
• Zur weiteren Optimierung der Stromaufnahme und Waermeentwicklung im USB-Hub Nutzung der 3.3V aus dem Schaltregler statt des internen Linearreglers im Hub-Chip (U4 Pins 47 und 48 hochbiegen und nicht anloeten, Drahtbruecke vom nicht bestueckten U3 Pin 8 zum positiven Pin von C41)
• Um das USB-Hotplug (mit den vorhandenen USB-Power-Switches) "kugelsicher" zu machen, habe ich noch BIT3 ueberbrueckt, und (ab jetzt auf der Prozessor-Grundplatine) C22 und C181 entfernt, C19 und C180 durch 22uF und C27 durch 2x 47uF keramisch ersetzt.

Was zum Betrieb mit einer S2-6400 noch fehlt ist ein PCIe-Port und ein SATA-Power-Stecker mit 12V.

Zum Glueck liegen die PCIe-Signale des Kirkwood auf den Verbindungssteckern der beiden Boards. Die kann man dort abgreifen und auf eine PCIe-Buchse legen (ohne WAKE# und die 12V-Versorgung des Ports, die viele PCIe-Karten - wie die S2-6400 - aber nicht nutzen):

Dann muss man noch R178 (auf der Grundplatine) entfernen, um den PCIe-Takt anzuschalten und ein halbwegs neues U-Boot flashen, das PCIe aktiviert (das aktuelle aus dem Marvell-Custodian-Tree geht). C25 und C26 sollten ueberbrueckt werden (an PCIe-Inputs gehoeren keine Koppelkondensatoren, da die ja schon an den Outputs sein muessen.)

Die 12V nehme ich aus dem angesprochenen externen Steckernetzteil, die 5V fuer Guru und USB-Geraete und etwas belastbarere 3.3V fuer PCIe erzeuge ich auf einer Zwischenplatine (zwischen den originalen beiden des Guru). Diese Platine stellt noch 2 USB-Ports, die SATA-Stromstecker, einen (internen) SATA-Port, den PCIe-Port (im rechten Foto an der Stinseite der Zwischenplatine) und einen Wakeup-Microcontroller bereit, der auch das HDMI-CEC-Signal auswertet.

Bilder:

Schaltplan der Zwischenplatine:

Das modifizierte Guru braucht etwa ein halbes Ampere am 12V-Input, mit einer S2-6400 (ohne Sat-LNB) etwa 1A mehr.

Edit: Habe die Stromaufnahme am 12V-Input nochmal nachgemessen:

• modifiziertes Guru, S2-6400 (kein Sat-LNB), Terabyteplatte (ST1000LM024 HN-M101MBB), DVB-C USB-Stick (Terratec Cinergy HTC Stick HD), laufender vdr, Wiedergabe der Tagesthemen auf ARD-HD: 1510mA
• Soft-Off (so ne Art ACPI-Wakeup fuer timergesteuerte Aufnahmen, nur der EZUSB-FX2 auf der Zwischenplatine laeuft noch): 11mA
• modifiziertes Guru (3er Sandwich) alleine (kein PCIe-Geraet, SATA-Ports disabled, Ethernet und WLAN down, USB im Reset, LEDs aus, Linux-Rootshell ueber serielle Console): 230mA

Zitat von Uwe

hast du da mehr Infos!? Deine S2-FF-HD-6400 läuft auf einem MB mit ARM CPU? Klingt sehr Interessant....

Das "Motherboard" ist ein modifiziertes Guruplug ServerPlus, nichts, was man so irgendwo kaufen kann. Bei speziellem Interesse kann ich dazu natuerlich mehr erzaehlen, waere _hier_ aber ziemlich sicher off-topic.
Die massiven burstartigen Plattenzugriffe des vdr, die ich mit diesem patch entschaefen moechte, wirken sich aber ziemlich sicher auch auf anderen schwachbruestigen Systemen - z.B. der momentan so hippen "Goldenen Himbeere" (RaspberryPi) - negativ aus.

Ich habe einen HD-VDR mit (S2-6400) auf einer langsamen arm-CPU (Marvell Kirkwood) am laufen (transfermode, DVB-C!). Hier gab es gelegentlich Ruckler und Tonaussetzer, ausserdem eine recht traege Reaktion auf die Fernbedienung. Ich konnte dieses Verhalten auf das Schreiben der EPG-Daten und das Suchen von geloeschten Aufnahmen im Vordergrundthread zurueckfuehren. Der angehaengte patch (eigentlich fuer 1.7.28, geht auch mit 1.7.30) behebt diese Probleme und laeuft bei mir seit einigen Wochen stabil.
kls: Kann man das so oder aehnlich in den vdr mit aufnehmen?

Danke,
S:oren

Ich habe den saa716x_ff-Treiber mal direkt in linux-3.5.0 gebaut. Da gab es section mismatches und include-Probleme. Entsprechende patches anbei, die duerfen von mir aus gerne in das Treiber-Repository uebernommen werden.

Ich haette auch noch andere Problemchen und Aenderungsvorschlaege fuer den Treiber, sind solche patches hier erwuenscht oder soll ich die lieber woanders hin (oder ueberhaupt nicht) schicken?

Gruss,
S:oren

powarman: Auch wenn ich mich jetzt wieder dem Verdacht aussetze, zu ungeduldig zu sein: Ist noch eine Lösung zu den fehlenden Tasten-Wiederholungen bei CEC-RemoteControlPassThrough zu erwarten (siehe hier)
Kann ich bei einer Lösung irgendwie helfen?
Gruss,
S:oren

Hallo ALT255,

mangels Doku und eigenen Versuchen kann ich auch nur raten, vermute aber folgendes:

int HdffCmdHdmiSendRawCecCommand(int OsdDevice, uint8_t Destination,
uint8_t Opcode, const uint8_t * Operand,
uint8_t OperandLength)

OsdDevice: file handle des dvb_osd device (es bietet sich vermutlich an, ein cHdffCmdIf::CmdHdmiSendRawCecCommand analog zum cHdffCmdIf::CmdHdmiSendCecCommand zu implementieren, dann faellt das OsdDevice schon mal weg)
Destination: logical address des Ziels (die 5, AudioSystem)
Opcode: CEC opcode (die 0x44, UserControlPressed)
Operand: Pointer auf ein Openranden-Array (enthaelt hier nur die 0x43, Mute)
OperandLength: Laenge des Openrandenarrays, hier eine 1, denke ich.

Wie gesagt, nicht getestet, alles nur Vermutung...

Zitat von Grindo

Bei dem hauppauge wintv-nova-td muß man aber die automatische epg suche im VDR abschalten.
Sonst hat man alle 20 Sekunden Bildfehler wenn der VDR im Hintergrund auf einen anderen Transponder wechselt.

Gegen diese Stoerungen benutze ich den angehaengten Kernel-Patch, damit laufen bei mir seit Jahren 2 Nova-TD-Sticks (4 Tuner) parallel ohne jedes Problem. Der Patch ist - denke ich - fuer linux-3.0.x bis 3.2.x getestet, eine Portierung auf eine andere Kernelversion sollte kein grosses Problem sein. Da es verschiedene Versionen des Sticks gibt (mir sind 2 bisher untergekommen) bitte darauf achten, ob in den Kernel-Messages "enabling nova-td workaround for dib0700 streaming" steht, dann ist der patch aktiv.
Gruss,
S:oren

KeinTimer ist so gut wie einer unendlich lange in der Zukunft. Der vdr ist auf jeden Fall nicht automatisch durch einen Timer gestartet worden, dann bleibt der Fernseher naemlich aus. Hat nichts mit der Firmwareversion zu tun, haengt von der Version des Plugin ab (Man sollte natuerlich kein neues Plugin mit alter Firmware nutzen. Umgekehrt geht vermutlich, scheint mir aber nicht sonderlich sinnvoll). Die Diskussion driftet gerade etwas in die OT-Ecke ab, befuerchte ich. Ich koennte meinen CEC-Thread anbieten:HDMI-CEC auf TT S2-6400

Ich kenne 2 Moeglichkeiten fuer User-Aktivitaet: Einschalten des VDR mit dem naechsten Timer mehr als xxx (10?) Minuten in der Zukunft ("assuming manual start" im vdr-log), oder das Druecken von Tasten auf der Fernbedienung. Es mag mehr Moeglichkeiten geben (SVDRP, Plugins,???)

Ich denke nicht, dass dieses Einschalt-Verhalten am Fernseher liegt. Seit der Version vom 6.2.12 schaltet das dvbhddevice-Plugin den Fernseher nicht mehr beim Start des vdr, sondern bei erkannter User-Aktivitaet ein (wenn so konfiguriert), das trifft vermutlich auch, wenn der User ueber den Streaming-Client Aktivitaet entfaltet. Insbesondere, wenn man den vdr ausschaltet, wegen laufender Aufnahme das Ausschalten verschoben wird, man dann wieder irgendwas bedient, sollte der Fernseher eingeschaltet werden. Oder wenn der vdr automatisch neu gestartet wird (ist mir schon lange nicht mehr passiert).
Das Plugin erkennt eben nicht, ob der Nutzer wirklich vorm Fernseher sitzt, es schaltet den Fernseher ein, wenn der vdr vom UserInactive- in den UserActive-Status geht. Das ist vermutlich nicht gut mit einem Streaming-Client getestet.
PS: Ich nutze auch zwei verschiedene Philips-Fernseher fuer meine Tests...

Zitat von S:oren

Eine Sache ist mir aufgefallen: zumindest ueber CEC gibt es keine automatische Wiederholung von Tastendruecken (wenn man z.B. lange auf "down" drueckt zum Blaettern im epg), das war mit der alten Firmware/Plugin-Kombi anders. Damit wurden die Tasten beim langen Druecken wiederholt, fuer meinen Geschmack sogar zu schnell. Hat sich da in der Firmware was geaendert? Sollte nicht eigentlich der Treiber/input-event die Wiederholungen machen?

Mittlerweile habe ich das Problem lokalisieren koennen, es haengt nicht von der Firmware- oder Treiberversion ab, sondern vom Fernseher. Nach CEC-Spec sollten die Tastendruecke eigentlich nicht wiederholt werden ("The initiator should not send repeated <User Control Pressed> messages for the same button press."), andererseits ist ein Dauerdruecken von Tasten ueber mehr als eine halbe Sekunde nicht vorgesehen ("If a follower has received a <User Control Pressed> message and it did not receive a <User Control Released> message (or another <User Control Pressed> message with a different [UI Command] ) within 500ms, then it is recommended that the receiving device should assume that the button has been released and act accordingly." CEC-Spec 1.3a). Der normale Fall des Blaetterns durch eine Liste mit einer Scrollrate von - sagen wir mal - 5 Eintraegen pro Sekunde ist also streng nach CEC-Spec nicht moeglich. Manche Fernseher wiederholen die Tastendruecke ueber CEC nun also wie eine normale Infrarotfernbedienung, andere nicht.
Um die fehlenden Wiederholungen (ist man ja so gewoehnt) ggf. im Treiber erzeugen zu koennen, braeuchte ich von der Firmware neben den vorhandenen ButtonPressed- auch die zugehoerigen -Released-Meldungen.
powarman: Koennte die Firmware auch die Released-Messages an den Treiber durchreichen, z.B. mit gesetztem zweithoechstem Bit in den IR-Commands? Oder waere es evt. zweckmaessiger, die Wiederholungen anders, z.B. in der Firmware selbst, zu erzeugen? Oder ist sowieso eine Moeglichkeit geplant, beliebige CEC-Messages im Treiber empfangen zu koennen - nachdem das Senden ja eingebaut ist? Dann koennte man das CEC-Handling komplett im Treiber/Plugin unabhaengig vom IR-input machen, ist vermutlich auch nicht so einfach. Ich wuerde mich jedenfalls schon ueber Released-Messages oder andersartig wiederholte Tastendruecke freuen. Ich kann mich auch gerne an einem Treiberpatch versuchen, wenn die Firmwareschnittstelle geaendert wird...
Danke,
S:oren

Hier der gewuenschte CEC-Thread:HDMI-CEC auf TT S2-6400
Gruss,
S:oren

Da es den Wunsch nach einem eigenen Thread zu CEC auf der TT S2-6400 gab: hier ist er...

Erstmal eine Zusammenfassung, was HDMI-CEC auf der S2-6400 bedeutet:
CEC hat sehr viele verschiedene Teilspezifikationen, fuer die S2-6400 wurden zwei davon beworben: OneTouchPlay und RemoteControlPassThrough.

• OneTouchPlay bedeutet, dass ein HDMI-Geraet - hier der vdr - den Fernseher aus Standby einschalten (auch wieder aus ist vorgesehen) und auf den entsprechenden HDMI-Eingang umschalten kann. Das entspricht im Prinzip der entsprechenden Funktionalitaet der analogen Scart-Buchse und ist z.B. dazu gedacht, an einem ueber HDMI angeschlossenen DVD-Player auf Play zu druecken, der Rest passiert dann automatisch
• Fuer mich interessanter ist RemoteControlPassThrough. Hier steuert der Fernseher das HDMI-Geraet (den vdr), wenn der Fernseher fuer die entprechende HDMI-Buchse entsprechend eingestellt ist. Der Fernseher reagiert dann nicht mehr selbst auf die (fast alle) Tasten seiner Fernbedienung und reicht stattdessen die Tastendruecke an den vdr durch. Das ist schnell und funktioniert bereits perfekt mit dem Remote-Plugin. Bei mir reagiert der Fernseher zum Beispiel selbst auf laut/leise - sehr schoen bei AC3-Ton, reicht aber die Zifferntasten, die bunten Tasten, die Richtungstasten und mehrere andere Tasten (z.B. OK) an den vdr durch. Somit braucht der vdr keinen eigenen IR-Empfaenger mehr, der vdr erscheint als "interner Tuner des Fernsehers mit Zusatznutzen", man benutzt nur noch die Fernbedienung des Fernsehers.

Was braucht man:

• einen VDR-Rechner (vdr 1.7.x) mit einer S2-6400 und passender Firmware und Treibern
  Die Firmware gibt es hier: www.aregel.de. Ich verwende die momentan aktuelle Version 0.3.7.
  Fuer Treiber siehe hier: Treiber
• einen Fernseher mit HDMI und Unterstuetzung fuer CEC OneTouchPlay / RemoteControlPassThrough
  CEC heisst je nach Hersteller anders (EasyLink, VieraLink iLink, ...). RemoteControlPassThrough muss im Einstellungsmenue des Fernsehers aktiviert werden, siehe Bedienungsanleitung des Fernsehers.
• dvbhddevice- und remote-Plugins
  Das dvbhddevice-Plugin gibts hier: Plugin. Ich verwende die in vdr-1.7.24 enthaltene Version. Das remote-Plugin ist das selbe, was man fuer eine IR-Fernbedienung verwendet.

Konfiguration:

• Zum Ein- und Ausschalten des Fernsehers (von / in Standby) - CEC OneTouchPlay:
  In den Einstellungen des dvbhddevice-Plugins CEC aktivieren und TV ein / aus nach Belieben einstellen
• Fuer die Steuerung des VDR ueber CEC vom Fernseher mit dessen Fernbedienung - CEC RemoteControlPassThrough:
  - in den Einstellungen des dvbhddevice-Plugins CEC aktivieren
  - "CEC TV aus" deaktivieren (nicht notwendig, aber zweckmaessig)
  - am Fernseher RemoteControlPassThrough einschalten
  - Infrarotempfanger der S2-6400 abziehen oder abdecken (der aktuelle Treiber unterstuetzt eine gleichzeitige Bedienung ueber IR- und CEC-Fernbedienung nicht / schlecht)
  - remote.conf loeschen, vdr neu starten, CEC-Fernbedienung anlernen
  - "CEC TV aus" kann in den Einstellungen des dvbhddevice-Plugins wieder aktiviert werden
  - freuen

denkbare zukuenftige Erweiterungen:

• powarman hat in Firmware und Plugin die Moeglichkeit eingebaut, an den Fernseher CEC-Kommandos zu senden, z.B. Fernbedienungs-Tastendruecke in die andere Richtung als bisher beschrieben. Habe ich nicht getestet, man braeuchte wohl eine Art "Reverse-Remote-Plugin, um das sinnvoll zu nutzen. Und einen Fernseher, der ueber CEC Befehle entgegennimmt.
• beliebige CEC-Kommandos zu empfangen geht mit der aktuellen Firmware/Treiber/Plugin-Kombi wohl noch nicht. Waere z.B. sinnvoll, um CEC-Standby-Messages zu empfangen (das ist leider nicht Teil von RemoteControlPassThrough, sondern eine eigene CEC-Teilspezifikation namens SystemStandby) und daraufhin den VDR-Rechner auszuschalten. Ich behelfe mir damit, eine ansonsten unbenutzte Taste auf der CEC-(Fernseher-)Fernbedienung zum Ausschalten des vdr zu verwenden. Die Aus-Taste auf der Fernseher-Fernbedienung schaltet dann nur den Fernseher selbst ab, sinnvoll z.B. wenn noch eine Aufnahme laeuft. Ansonsten schalte ich nur den vdr aus, der schaltet dann ueber "CEC TV aus "(s.o.) den Fernseher mit ab.

Zum Einschalten des VDR-Rechners ueber die CEC-(Fernseher-)Fernbedienung verwende ich diese simple Hardwareerweiterung aus 2 Transistoren und einem Widerstand mit den richtigen Verbindungen zur HDMI-Buchse und zum PCIe-Stecker:

Diese Schaltung wertet nicht das CEC-Protokoll aus, sondern schaltet einfach bei Aktivitaet auf dem CEC-Bus (z.B. nach Einschalten des Fernsehers) den VDR-Rechner ein. Da bei mir der Fernseher nie ohne vdr benutzt wird (hat keine eigene Antennenstrippe) reicht mir das fuer meinen Anwendungsfall aus. Schoener waere sicher eine Schaltung mit Mikrocontroller, die es "richtig" macht.

CEC mit der S2-6400 ist also nicht kompliziert, mit der aktuellen Firmware/Treiber/Plugin-Kombi funktioniert es einfach. Vielen Dank an powarman und UFO - und alle anderen, die den vdr so weit gebracht haben...

Gruss,
S:oren

Zitat von powarman

Mit den letzten Änderungen am Plugin könnte das automatische Einschalten des Fernsehers per CEC besser funktionieren, d.h. es sollte nur passieren, wenn der Nutzer aktiv wird.

Ich habe meinen HD-vdr jetzt komplett auf CEC-Bedienung umgestellt, kein IR-Empfaenger mehr. Funktioniert gut, vielen Dank nochmal!
Eine Sache ist mir aufgefallen: zumindest ueber CEC gibt es keine automatische Wiederholung von Tastendruecken (wenn man z.B. lange auf "down" drueckt zum Blaettern im epg), das war mit der alten Firmware/Plugin-Kombi anders. Damit wurden die Tasten beim langen Druecken wiederholt, fuer meinen Geschmack sogar zu schnell. Hat sich da in der Firmware was geaendert? Sollte nicht eigentlich der Treiber/input-event die Wiederholungen machen? (Kernel ist unveraendert 3.1.6, mit IR-Fernbedienung habe ich leider nicht getestet)

Gruss,
S:oren

Zitat von powarman

Es gibt eine neue Firmware: www.aregel.de

Ich komme leider erst in ca. 4 Wochen zum Testen, trotzdem schon mal vielen, vielen Dank!!