VDR Portal

@traxanos: Wir nutzen das remote-plugin. Tut problemlos.

Hier der Thread. Dort auch eine remote.conf

Edit: Sorry - da kommst du nicht ran. Deshalb hier die remote.conf

Andy

wir benutzen bewusst das remote plugin nicht mehr. wir wollen wie alle anderen fernbedinungen mittels eventlircd lösen. wegen auto erkennung, kein anlern prozess etc. das problem im kerneltreiber fehlt scheinbar ein mapping der 2 tasten.

Ja stimmt - jetzt wo du es sagst. Hatte ich im Chat mal mitbekommen. Gerald hat das erklärt. Sehr elegante Lösung.

Andy

Hallo,

So, ich habe noch mal weiter getestet:
Wenn ich zusätzlich zur HD-FF eine zweite Sat-Karte (Cine-S2 oder auch zwei S2-1600) einbaue, habe ich nach dem Start auf dem ersten Tuner der HD-FF weiterhin immer Artefakte und auf den anderen drei Tunern nicht. Irgendwas stimmt m.E. mit der Initialisierung der Tuner auf der HD-FF noch nicht ganz. Wenn ich beim Start mittels Parameter -D0 -D1 den VDR nur die anderen Budget-Karten nutzen lasse, gibt es keinerlei Artefakte bei der Ausgabe über die HD-FF. Die HD-FF funktioniert also völlig problemlos als Ausgabedevice. Deshalb ist es m.E. sehr unwahrscheinlich, dass es ein Kommunikationsproblem PC<--->HD-FF ist. Es ist dabei völlig egal, ob die HD-FF in einem PCIe 1.1 oder PCIe 2.0 Slot steckt. Den Treiberparameter int_type=1 habe ich auch bereits ausprobiert, das bringt bezüglich der Artefakte beim Tuner 0 der HD-FF keinerlei Veränderung. Ich werde deshalb erstmal die zwei Tuner der HD-FF deaktiviert lassen und nur mit den Budget-Karten arbeiten, aber das ist auf keinen Fall das, was ich letztendlich erreichen möchte... Wäre wirklich Shit, die zwei Tuner inaktiv lassen zu müssen, für eine reine Decoder-Karte ist die HD-FF dann schon etwas teuer.

Vielleicht nur mal so als Denkanstoß. Bei der Cine-S2 hatten wir doch auch so ein Problem, dass die Karte immer mal den Lock verloren hat. UFO hatte dann glücklicherweise den 'fehlenden' Init-Parameter ermitteln können. Die HD-FF hat doch das selbe Frontend wie die Cine-S2. Fehlen da vielleicht noch irgendwelche Init-Schritte, die im Normalfall vielleicht sonst immer automatisch funktionieren und nur in (meinem) Sonderfall nicht?

Gruss Steve135

@Steve135: Probiere mal das Plugin im Anhang. Ist nicht von mir, aber es verarbeitet beide Tuner exakt gleich. Da steht die "dunkle Seite der Macht" besonders drauf. Wäre doch toll, wenn es dir auch hilft, dein Problem zu beseitigen.

so ich habe nun die treiber gepatched damit die tasten nun richtig gemappt werden.

http://pastebin.com/XNkEvea8

hoffe powarman das du das übernimmst.

Quoted from "traxanos"

so ich habe nun die treiber gepatched damit die tasten nun richtig gemappt werden.

http://pastebin.com/XNkEvea8

hoffe powarman das du das übernimmst.

Ich hoffe nicht in dieser Form!

Denn so kann man nur noch die mitgelieferte Fernbedienung benutzen. Alle anderen Codes erzeugen keine Events mehr.

CU
Oliver

Quoted from "UFO"

Ich hoffe nicht in dieser Form!

Denn so kann man nur noch die mitgelieferte Fernbedienung benutzen. Alle anderen Codes erzeugen keine Events mehr.

CU
Oliver

Naja, aktuell kann man nicht mal die mitgelieferte verwenden. Ist noch schlimmer. Da wird dann z.b. Tastencode 84 verwendet, denn es gar nicht gibt. Und die Belegung ist ja noch mehr murks, die sollte zumindest für die mitgelieferte stimmen. Man kann ja gerne, wenn man will die restlichen Codes auffüllen, aber aktuell ist der Treiber einfach kaputt. Das ist wie gesagt 100x schlimmer, als wenn andere Fernbedienungen nicht gehen. Witziger Weise wurde das sogar als Todo sogar vermerkt im Sourcecode.

Wir wollen halt den Supportaufwand gering halten und nicht den Leuten erklären müssen, warum nicht alle Tasten der mitgelieferten Fernbedienung gehen.

Wenn der Treiber "kaputt" ist, warum geht es dann mit dem Remote-Plugin?

Weil es die Inputkeys nicht verwendet, sondern direkt auf die Keycodes geht. Das ist aber keine Option für uns, da wir eventlircd verwenden werden, um das Fernbedienungsetup stark zu vereinfachen.

Aber falls du mir nicht glaubst, kannst du gerne mal in der input.h nach dem Key 84 schauen. Denn gibt es nicht. Im Treiber von Powarman kannst du auch gerne mal nach Todo suchen.

http://lxr.linux.no/#linux+v2.6.38/include/linux/input.h
http://powarman.dyndns.org/hgwebdir.cgi/…saa716x_ff_ir.c

Also Lösung könnte man es auch als module options konfigurierbar machen. Aber wir gehen davon aus, dass wenn man sich ein Auto kauft, dass man dann auch das mitgelieferte Lenkrand verwendet, welches ordentlich auf KEYs gemappt sein sollte.

@Copperhead:
Danke für den Link. Habe das 'alternative' Plugin mal ausprobiert, es ändert aber leider an der Problematik bei mir nichts. Es verhält sich diesbezüglich genau wie das Original-Plugin. Nach einem 'Cold-Boot' ist auch wie beim Original-Plugin der erste Tuner immer verpixelt. Sobald ich den VDR beende und zum zweiten mal starte funktioniert es. Das ist schon ein wenig blöd. Ich kann doch nicht immer bei jedem Rechner Start einmal vorher den VDR 'weg-killen' damit ich sicher sein kann, dass meine Aufnahmen auch gelingen und der Tuner keinen Pixelmüll produziert.

Vielleicht haben powarman und UFO ja doch noch eine 'Eingebung', an was das liegen könnte...

Gruss Steve

Die Logik erschließt sich mir nicht.

Der Empfänger der FF-Karte ist ein vollwertiger RC5/RC6 Empfänger, der mit jeder Fernbedienung mit diesem Code betrieben werden kann. Man kann also, statt der beiliegenden FB, auch eine Universelle hernehmen, einen Philips-Code programmieren und dann diese FB anlernen. Alternativ kann man jede gewünschte FB mit diesen Codestandards nutzen. Die bekannte "Technisat-Fernbedienung" wäre so ein Kandidat.

Wohl unnötig zu sagen, dass man wohl kaum alle möglichen gültigen RC5/RC6 Codes auf gültigen Keycodes abbilden kann. Prinzipbedingt kommen also auch "ungültige" Keycodes. Man kann diese durchaus valide machen. War damals bei dem FB-Empfänger der Activy gängige Praxis, die Keycodes dem Kernel beizubringen. Vielleicht ist das für deinen Anwendungsfall eher der richtige Weg.

Ich hoffe auf jedem Fall, dass der Treiber nicht in der Form verkrüppelt wird, dass der beiliegende Empfänger letztlich nicht mehr für jede RC5/RC6 Fernbedienung funktioniert.

Quoted from "Mreimer"

Die Logik erschließt sich mir nicht.

muss es dir ja nicht. uns als distributor interessiert es sehr wohl und es gibt auch eine logik dafür.

Quoted from "Mreimer"

Ich hoffe auf jedem Fall, dass der Treiber nicht in der Form verkrüppelt wird, dass der beiliegende Empfänger letztlich nicht mehr für jede RC5/RC6 Fernbedienung funktioniert.

das lässt sich ja regeln, wie ich schon geschrieben habe.

Quoted from "Mreimer"

Wohl unnötig zu sagen, dass man wohl kaum alle möglichen gültigen RC5/RC6 Codes auf gültigen Keycodes abbilden kann. Prinzipbedingt kommen also auch "ungültige" Keycodes. Man kann diese durchaus valide machen. War damals bei dem FB-Empfänger der Activy gängige Praxis, die Keycodes dem Kernel beizubringen. Vielleicht ist das für deinen Anwendungsfall eher der richtige Weg.

Ich hoffe auf jedem Fall, dass der Treiber nicht in der Form verkrüppelt wird, dass der beiliegende Empfänger letztlich nicht mehr für jede RC5/RC6 Fernbedienung funktioniert.

es lassen sich bestimmt alle keys sauber mappen, es hat sich nur keiner darum gekümmert. außerdem scheint die Karte RC6 noch nicht zu können. Auch ein teil des Todos scheinbar.

Wenn ich ein Gerät kaufe, erwarte ich, dass das mitgelieferte Zubehör sauber geht. Daher müssen meiner Meinung nach die KEYs schon Kernelseitig sauber gemappt sein für dieses Zubehör. Ich habe ja nie was dagegen gesagt, dass man andere Ferbedienungen ausschließen soll. Ich habe nur gesagt, der aktuelle weg ist murks. Mich aber nur zu beschweren finde ich nicht gut, daher habe ich schon mal angefangen die Keymap zuschreiben. Heißt doch immer wenn dir was nicht passt ändere es.

In wieweit es technisch machbar ist, die Keys sauber zu mappen, kann ich jetzt schlecht sagen. Ich weiß nicht, wie RC5/6 Code nach Keycode gemappt wird. Ich würde das auf jedem Fall so machen, dass ich den Code, der von der Karte kommt, möglichst direkt als Keycode weiterleite. Es handelt sich beim Remote-Empfänger *nicht* um eine Tastatur. Hier sind invalide Keycodes durchaus üblich. Man kann diese, wie schonmal geschrieben, dem Kernel bekannt machen und schon funktioniert dein "inputlirc" ganz ohne Treiber-Änderung.

Nachtrag: man setkeycodes

dieses ummappen machen wir ja zusätzlich. das problem ist nur das codes die es garnicht gibt von uns nicht umgemappt werden können. daher mache ich mir ja die mühe.

Ich zweifle ja langsam an, dass ihr mit inputlirc wirklich eine einfachere Lösung habt, als das Remote-Plugin. Ich halte mich jetzt aber aus dem Thema raus. Meine Meinung habe ich kundgetan.

Wir nutzen keine inputlirc, sehr wohl aber normale KEY-Events.

Außerdem was bringt einem das remote-plugin, wenn er ein script starten möchte oder das xbmc bedienen will. remote-plugin ist zwar net aber es kann halt nur das wofür es gebaut wurde. nur den vdr zu steuern.

@Copperhead:

Quoted from "Copperhead"

@Steve135: Probiere mal das Plugin im Anhang. Ist nicht von mir, aber es verarbeitet beide Tuner exakt gleich. Da steht die "dunkle Seite der Macht" besonders drauf. Wäre doch toll, wenn es dir auch hilft, dein Problem zu beseitigen.

Danke für den Link. Das geänderte Plugin hat bei mir das Problem mit dem AC3-Ton, wie in folgendem Link beschrieben:
S2 6400 Aussetzer DolbyDigital
scheinbar gelöst.
So wie es aussieht wurde hier der Ausgabeteil vom Rest getrennt, er taucht bei mir als "Gerät 4 (Gerät hat Dekoder, Primärgerät) im Gerätestatus auf (Gerät 1-3 sind die 3 Tuner). Auch im femon-Plugin wird der AC3-Stream jetzt sofort angezeigt und benutzt.

Insgesamt zeigt das doch, das zumindest die Tonprobleme durchaus im HD-Ausgabe-Plugin behoben werden könnten.

Gruß Karl

Quoted from "traxanos"

Naja, aktuell kann man nicht mal die mitgelieferte verwenden.

Das ist Blödsinn! Es funktioniert einwandfrei, wovon man sich leicht mit evtest überzeugen kann!

Wichtig ist nur, daß jede Taste einen *eindeutigen* Tastencode generiert. Und das tut sie!

Das Keymapping mit irgendwelchen Keymaps, wie es bisher im Kernel gemacht wird, funktioniert immer nur mit einer Fernbedienung.
Falls eine Karte z.B. nach einiger Zeit mit einer anderen Fernbedienung ausgeliefert wird, ist Feierabend.

Falls Du also eine Keytable in den Treiber patchst, dann nur so, daß die restlichen Keycodes mit eindeutigen Codes aufgefüllt werden.
Ob die in input.h definiert sind oder nicht, interessiert nicht.
(Viel Spaß mit einer Applikation, die jedes Mal geändert werden muß, wenn ein neuer Eintrag in input.h dazu kommt.
Was btw. gar nicht so selten vorkommt.)

Quoted

Ist noch schlimmer. Da wird dann z.b. Tastencode 84 verwendet, denn es gar nicht gibt. Und die Belegung ist ja noch mehr murks, die sollte zumindest für die mitgelieferte stimmen. Man kann ja gerne, wenn man will die restlichen Codes auffüllen, aber aktuell ist der Treiber einfach kaputt. Das ist wie gesagt 100x schlimmer, als wenn andere Fernbedienungen nicht gehen. Witziger Weise wurde das sogar als Todo sogar vermerkt im Sourcecode.

Na rate mal, wer das da reingeschrieben hat...
Und noch was, Du Schlaumeier: Der richtige Code ist nicht drin, weil ich die Original-FB nicht habe (Entwicklungsmuster).

Quoted

Wir wollen halt den Supportaufwand gering halten und nicht den Leuten erklären müssen, warum nicht alle Tasten der mitgelieferten Fernbedienung gehen.

Nein, Du willst es für Euch einfach machen. Und dies geschieht auf Kosten derer, die eine beliebige FB verwenden möchten.

Oliver

Quoted

Der richtige Code ist nicht drin, weil ich die Original-FB nicht habe (Entwicklungsmuster).

Brauchst Du eine? Ich brauche meine aktuell nicht und könnte sie leihweise zur Verfügung stellen. Bei Interesse bitte PM.