CIR bzw. nuvoton-cir, Nachlaufen von Befehlen

herrlado · 8. Januar 2013

Das habe ich nun so eingestellt. Mein Problem ist nun, dass wenn ich die Taste gedruck halte und dann los lasse, werden noch ein Paar Befehle gesendet. D.h. wenn ich schnell durch die Eintraege navigiere und los lasse wird es noch ein Paar Eintraege weiter gesprungen. Wie kann man das umgehen?

Gruss,
Lado

Keine_Ahnung · 8. Januar 2013

Zitat von herrlado

D.h. wenn ich schnell durch die Eintraege navigiere und los lasse wird es noch ein Paar Eintraege weiter gesprungen. Wie kann man das umgehen?

Repeatrate runterstellen Der VDR kommt vermutlich mit der Abarbeitung der Tastendrücke nicht hinterher.

Die Tastendrücke kommen ja auf der einen Seite in die Warteschlange und werden der Reihe nach am anderen Ende rausgenommen und abgearbeitet.

cu

herrlado · 8. Januar 2013

Ich glaube VDR kommt in der Regel gut hinterher, nehme ich an, denn das Problem kann ich mit irw auch nachvollziehen.

Ich habe mit ir-keytable und -D -P rumgespielt aber -P wird hoeher dafuer ist die Wiederholrate dadurch niedriger.
Irgendwie finde ich keine goldere Mitte mit -P 400 richtig lahm geworden aber wenn ich los lasse wird immer noch ein Mal gesendet

Wie ist eure Einstellungen diesbezueglich?

Gruss,
Lado

ATD · 8. Januar 2013

Zitat von herrlado

Ich habe mit ir-keytable und -D -P rumgespielt aber -P wird hoeher dafuer ist die Wiederholrate dadurch niedriger.

Kannst Du das näher erklären?

Zitat von herrlado

Wie ist eure Einstellungen diesbezueglich?

Da haben wir beide momentan Pech. Bei mir ist das auch so. Das ist aber nicht die Harmony. Ich kann das an dem IR-Empfänger der Tastatur ersehen (Signal-LED), dass die Harmony sofort aufhört, wenn ich die Taste loslasse, der Balken läuft aber zwei-drei Positionen weiter. Ich sehe auch, dass bei einem einfachen Tastendruck nur ein einziger Befehl gesendet wird.

Das Problem ist, dass CIR direkt auf eventlircd geleitet wird. Prinzipiell hat eventlircd einen Repeatfilter, welches momentan nicht funktioniert.

Lies mal das ab hier durch. Du kannst es gerne Probieren, vielleicht ist es bei Dir doch nicht so.

Albert

herrlado · 8. Januar 2013

Ja, bei einem einzelnen Hit wird ja nicht wiederholt. Je höher der -P Wert desto höher der Abstand zwischen den Signalen. Ist wohl aber ehe eine Krücke und für mich inakzeptabel. Werde später den Vorschlag aus dem anderen Thread ausprobieren.

Übrigens TV funktioniert ganz gut, kommt also gut klar mit der gedrückten Tasten.

herrlado · 8. Januar 2013

Ich habe ein Paar Optionen bei eventlircd ausprobiert, -R ist ehe per Default an. Andere min max und accel. Werte haben nichts gebracht.

herrlado · 10. Januar 2013

Also Original ASrock Smartremote hat das selbe Problem. Viel zu viel Nachlauf. War neulich bei einem Bekannten und war mit einem LG TV FB beeindruckt. Bei mir muss
ich immer im Vorfeld berechnen wo ich hin will und entsprechend früh die Taste loslassen.

Ich habe mit eventlircd Parametern gespielt und leider erkenne ich keinen Unterschied überhaupt
was --min-repeat-delay --max-repeat-delay und --repeat-acceleration bewirken. Ich habe mit diversen Zahlen experimentiert aber hat sich gar nichts geändert.

Ausser DaKilla hat sich niemand gemeldet. Funktioniert denn bei alles sauber?

@DaKilla, welchen Empfänger hast du denn?

Mufflon · 10. Januar 2013

Doch, ich habe das auch mit meiner Smartremote und der 300er. Habe mich aber damit abgefunden und mittlerweile einigermassen raus, wann ich loslassen muss. Aber wenn jemand eine Lösung hat, immer her damit.

Bye, Klaus

ATD · 10. Januar 2013

Zitat von herrlado

Ausser DaKilla hat sich niemand gemeldet. Funktioniert denn bei alles sauber?

Mit CIR oder HID wohl kaum.

Zitat von herrlado

@DaKilla, welchen Empfänger hast du denn?

Ich habe momentan auch den ASRock Smart Remote. Wenn ich mal Zeit habe (das wird mittelfristig passieren), werde ich Die Bastellösung gleich als Platine mit SMD ausprobieren. Die Platine fertigt mir ein Kunde nebenbei, sieht professioneller aus als händisch zusammengelötet und es ist dann in das Gehäuse drin, richtig befestigt mit Scrauben.

Ich glaube aber nicht daran, dass es was ändert. Solange ich den HID benutzt habe, war das mit dem nachlaufen auch. Wie ich es schon sagte, ich kann die abgefeuerten Signale genau an das Quittungs-LED des IR-Empfängers von der Tastatur sehen. Lasse ich die Taste los, gibt es sofort an das LED Ruhe, der Balken läuft dennoch weiter. Mit der IR-Tastatur geht es übrigens perfekt, kein Nachläufer.

Ich habe eventlircd im Verdacht, denn gerade CIR und HID landen direkt dort. Der RF von eventlircd greift bei mir nicht, im Gegenteil, wenn ich es zuschalte, dann beendet sich eventlircd zusammen mit irexec.

Du kannst mal in /etc/init/eventlircd.conf mit den Standardwerten experimentieren:

Code

exec /usr/sbin/eventlircd -f -R -d -D -a --socket=/var/run/lirc/lircd

oder das ausprobieren:

Code

exec /usr/sbin/eventlircd -f -R -d --max-repeat-delay=350000 -a --socket=/var/run/lirc/lircd

Schau aber dann ins log!

Übrigens, weil Du irgendwo schon geschrieben hast, dass der Filter grundsätzlich an wäre: das ist die Originalzeile:

Code

exec /usr/sbin/eventlircd -f --socket=/var/run/lirc/lircd #--repeat-filter

Filter also aus!

Albert

ATD · 10. Januar 2013

herrlado

Ich habe den Filter mal kurz zugeschaltet:

Code

exec /usr/sbin/eventlircd -f -R -d -D -a --socket=/var/run/lirc/lircd

Code

Jan 10 22:52:40 Patty kernel: [27333.007802] init: eventlircd main process (3801) terminated with status 64
Jan 10 22:52:40 Patty kernel: [27333.007818] init: eventlircd main process ended, respawning
Jan 10 22:52:40 Patty kernel: [27333.007949] init: irexec main process (3806) terminated with status 1
Jan 10 22:52:40 Patty kernel: [27333.007964] init: irexec main process ended, respawning
Jan 10 22:52:40 Patty kernel: [27333.011509] init: irexec main process (3808) terminated with status 1
Jan 10 22:52:40 Patty kernel: [27333.011532] init: irexec main process ended, respawning
Jan 10 22:52:40 Patty kernel: [27333.013557] init: irexec main process (3811) terminated with status 1
Jan 10 22:52:40 Patty kernel: [27333.013579] init: irexec main process ended, respawning
Jan 10 22:52:40 Patty kernel: [27333.015323] init: eventlircd main process (3807) terminated with status 64
Jan 10 22:52:40 Patty kernel: [27333.015339] init: eventlircd main process ended, respawning
Jan 10 22:52:40 Patty kernel: [27333.015468] init: irexec main process (3812) terminated with status 1
Jan 10 22:52:40 Patty kernel: [27333.015483] init: irexec main process ended, respawning
Jan 10 22:52:40 Patty kernel: [27333.018765] init: irexec main process (3814) terminated with status 1
Jan 10 22:52:40 Patty kernel: [27333.018842] init: irexec main process ended, respawning
Jan 10 22:52:40 Patty kernel: [27333.020978] init: irexec main process (3817) terminated with status 1
Jan 10 22:52:40 Patty kernel: [27333.021002] init: irexec main process ended, respawning
Jan 10 22:52:40 Patty kernel: [27333.022372] init: eventlircd main process (3813) terminated with status 64
Jan 10 22:52:40 Patty kernel: [27333.022388] init: eventlircd respawning too fast, stopped
Jan 10 22:52:40 Patty kernel: [27333.022656] init: irexec main process (3818) terminated with status 1
Jan 10 22:52:40 Patty kernel: [27333.022670] init: irexec main process ended, respawning
Jan 10 22:52:41 Patty vdr: [1184] ERROR (lirc.c,48): /var/run/lirc/lircd: Datei oder Verzeichnis nicht gefunden

Alles anzeigen

Albert

seahawk1986 · 10. Januar 2013

Wie startest du den repeat-Filter? Mit -R oder mit --repeat-filter ? Letzteres hat zumindest unter yaVDR 0.4 und der frühen alpha1 immer geklappt...

ATD · 10. Januar 2013

Zitat von seahawk1986

Wie startest du den repeat-Filter? Mit -R oder mit --repeat-filter ? Letzteres hat zumindest unter yaVDR 0.4 und der frühen alpha1 immer geklappt...

Diesmal mit -R (kürzer).

Code

exec /usr/sbin/eventlircd -f -R -d -D -a --socket=/var/run/lirc/lircd

aber natürlich habe ich die komplette Palette auch schon probiert.

Code

exec /usr/sbin/eventlircd -f --repeat-filter --min-repeat-delay=100000 --max-repeat-delay=200000 --repeat-acceleration=0.450000 --socket=/var/run/lirc/lircd

Will irgendwie nicht.

Jetzt wieder raus:

Code

Jan 10 23:01:43 Patty kernel: [27875.889896] init: irexec main process ended, respawning
Jan 10 23:01:44 Patty vdr: [1184] reconnected to lircd

Albert

seahawk1986 · 10. Januar 2013

Das sieht doch beides von der Syntax her falsch aus - mal fehlen die Zeitangaben, mal wird einem Schalter noch ein Wert zugewiesen, der nicht genutzt wird. Am besten erst mal in der Shell starten, dann findet man Syntax-Fehler schneller

Code

~$ eventlircd -h
Usage: eventlircd [options]
    -h --help              print this help message and exit
    -V --version           print the program version and exit
    -v --verbose           increase the output message verbosity (-v, -vv or -vv                                   v)
    -f --foreground        run in the foreground
    -e --evmap=<dir>       directory containing input device event map files (de                                   fault is '/etc/eventlircd.d')
    -s --socket=<socket>   lircd socket (default is '/var/run/lirc/lircd')
    -m --mode=<mode>       lircd socket mode (default is '0666')
    -R --repeat-filter     enable repeat filtering (default is 'true')
    -d --min-repeat-delay  minimum repeat delay (default is '100000')
    -D --max-repeat-delay  maximum repeat delay (default is '900000')
    -a --repeat-acceleration repeat acceleration (default is '0.450000')
    -r --release=<suffix>  generate key release events suffixed with <suffix>

Alles anzeigen

Was steht denn in der /var/log/upstart/eventlircd.log?
Das kann ich problemlos aus der Konsole starten, wenn der Upstart-Job gestoppt ist oder ohne sudo in der exec Anweisung des Upstart-Jobs platzieren:

Code

sudo /usr/sbin/eventlircd -f --socket=/var/run/lirc/lircd --repeat-filter --min-repeat-delay=100000 --max-repeat-delay=200000 --repeat-acceleration=0.450000

ATD · 10. Januar 2013

Zitat von seahawk1986

Das sieht doch beides von der Syntax her falsch aus - mal fehlen die Zeitangaben, mal wird einem Schalter noch ein Wert zugewiesen, der nicht genutzt werden kann.

Na gut, das mit dem true habe ich aus meine Dokumentation (Experiment), das habe ich weggemacht. Warum ist das Syntax falsch? Muss zwingend alles in der Reihenfolge angegeben werden, wie eventlircd -h das von oben nach unten listet?

Ich bin davon ausgegangen, dass eventuell alle Parameter angegeben werden müssen, nicht dass das Zuschalten nur den Max-Wert einsetzt, deswegen -R -d -D -a.

Das müsste aber stimmen:

Code

exec /usr/sbin/eventlircd -f --repeat-filter --min-repeat-delay=100000 --max-repeat-delay=350000 --repeat-acceleration=0.450000 --socket=/var/run/lirc/lircd

oder muss --socket zwingend hinter -f stehen?

Zitat von seahawk1986

Was steht denn in der /var/log/upstart/eventlircd.log?

Da muss ich noch nachschauen.

Zitat von seahawk1986

Das kann ich problemlos aus der Konsole starten, wenn der Upstart-Job gestoppt ist oder ohne sudo in der exec Anweisung des Upstart-Jobs platzieren:

Mit gestopptem Upstart-Job muss ich noch versuchen.

Alex, läuft Dein CIR nicht nach? Hast Du den RF einschalten müssen?

PS: Deine Zeile ist aber auch nicht ganz sauber:
sudo /usr/sbin/eventlircd -f --socket=/var/run/lirc/lircd --reat-filter --min-repeat-delay=100000 --max-repeat-delay=200000 --repeat-acceleration=0.450000

Albert

seahawk1986 · 10. Januar 2013

Zitat von DaKilla

Alex, läuft Dein CIR nicht nach? Hast Du den RF einschalten müssen?

Ich muss nochmal nachsehen was ich da am Testsystem eingestellt habe, IIRC gibt es aber rein über ir-keytable.

Zitat
Code
--reat-filter

Ja das kommt davon, wenn man übermüdet die falsche Zeile kopiert... aber man sieht dann sofort in der Logdatei dass etwas nicht stimmt:
/var/log/upstart/eventlircd.log

Code

/usr/sbin/eventlircd: unrecognized option '--reat-filter'
error: unknown option: ?

ATD · 10. Januar 2013

Zitat von seahawk1986

rein über ir-keytable

Kann man dort diesbezüglich auch etwas einstellen und wenn ja wie/wo?

Damit lässt er sich schon mal einschalten:

Code

exec /usr/sbin/eventlircd -f --socket=/var/run/lirc/lircd --repeat-filter --min-repeat-delay=100000 --max-repeat-delay=200000 --repeat-acceleration=0.450000

Ob das Nachlaufen noch da ist, kann ich noch nicht sagen/testen, VDR wird benutzt.

Zitat von seahawk1986

Ja das kommt davon, wenn man übermüdet die falsche Zeile kopiert

Ich schlage vor, wir schlafen darüber.

Albert

herrlado · 11. Januar 2013

Also das ist, was wir aktuell in vdr-unstable haben

Code

{"help",no_argument,NULL,'h'},
        {"version",no_argument,NULL,'V'},
        {"verbose",no_argument,NULL,'v'},
        {"foreground",no_argument,NULL,'f'},
        {"evmap",required_argument,NULL,'e'},
        {"socket",required_argument,NULL,'s'},
        {"mode",required_argument,NULL,'m'},
        {"process",required_argument,NULL,'p'},
        {"repeat-filter",no_argument,NULL,'R'},
        {"min-repeat-delay",required_argument,NULL,'d'},
        {"max-repeat-delay",required_argument,NULL,'D'},
        {"repeat-acceleration",required_argument,NULL,'a'},
        {"release",required_argument,NULL,'r'},

Alles anzeigen

und

Code

case 'v':
                if (verbose < 3)
                {
                    verbose++;
                }
                else
                {
                    syslog(LOG_WARNING, "the highest verbosity level is -vvv\n");
                }
            case 'f':
                foreground = true;
                break;
            case 'e':
                input_device_evmap_dir = optarg;
                break;
            case 's':
                lircd_socket_path = optarg;
                break;
            case 'm':
                lircd_socket_mode = (mode_t)atol(optarg);
                break;
            case 'R':
                input_repeat_filter = true;
                break;
            case 'd':
                input_min_repeat_delay = atol(optarg);
                break;
            case 'D':
                input_max_repeat_delay = atol(optarg);
                break;
            case 'a':
		input_repeat_acceleration = atof(optarg);
                break;
            case 'r':
                lircd_release_suffix = optarg;
		break;

Alles anzeigen

Hier kann man gut sehen, was für Argumente erwartet werden bzw. wie die geparsed werden. Übrigens ein Paar Parameter sind über Patches dazukommen, denn ich habe das Original ausgecheckt und da fehlen Diese.

Nur hatte ich das Gefühl, dass ich keinen Unterschied haben, egal welche Parameter und mir welchen Argumenten ich es starte.

Ich gehe so vor.

service eventlircd stop

dann starte ich es manuell, so wie es in der /etc/init/even... Datei steht + zusätzliche Parameter. Dann mache ich noch IRW und kann so testen, wie sich der Nachlauf verhält. Visuell konnte ich so nichts feststellen.

Aber generell, was soll anders mit repeat-filter sein, als mit

-P Option hier?

Code

/usr/bin/ir-keytable -D 550 -P 100 -a /etc/rc_maps.cfg

Setze ich -P höher, so wir die Wiederholung langsam. Setze ich es zu hoch. Kann ich praktisch genau aufhören wenn ich eine Taste los lasse. Dafür ist die Wiederholung halt langsam.

ATD · 11. Januar 2013

herrlado

Wenn ich das so lese was Du da schreibst, würde ich sagen, denken wir mal um die Ecke.

Wofür ist ein Repeatfilter gut? Sie verhindert Preller bei FB-Receiver-Kombinationen. Das bedeutet für mich, dass wenn eine FB doppelte Befehle sendet, dann muss das RF einen blockieren, z.B. Wechsel auf Kanal 17 (1+7) sollte nicht zum Kanal 1177 führen. In der 0.4 kann ich es mit Gewissheit sagen, dass das RF gearbeitet hat. Bei meinem damaligen HID bei zu hohen Werte ging das so weit, dass das RF aus Menü (alt+meta+KEY_ENTER = KEY_MENU) die erste zwei Tasten abgeschnitten hat, also bei Menü kam nur OK (KEY_ENTER = KEY_OK) an.

Das ist vielleicht gar nicht das Problem mit dem Nachlaufen. Preller hat die CIR keine! Wenn es zu Dauerfeuer kommt, dann tut irgendwer puffern. Die Frage ist: ist es eventlircd, VDR oder etwas anderes. Liege ich da falsch?

Albert

herrlado · 11. Januar 2013

@DaKilla
Ja, wir habe das Problem ja nur dann, wenn die Taste gedrückt gehalten wird (Dauerfeuer :D). Ich denke nicht, dass uns hier das Repeat Filter helfen würden.
Denn kannst du ja selbst ausprobieren mit (eigentlich udev macht das ausführen, kann aber jeder Zeit manuell ausgeführt werden)

/usr/bin/ir-keytable -D 550 -P 100 -a /etc/rc_maps.cfg

Kannst du -P drehen. Wenn ich z.B. -P mit 500 oder so laufen lasse, dann habe ich keinen Nachlaufen, die Wiederholungsrate ist aber extrem niedrig und unangenehm => Wie bei meinem X10.

Keine_Ahnung · 11. Januar 2013

Zitat von DaKilla

Wechsel auf Kanal 17 (1+7) sollte nicht zum Kanal 1177 führen.

Schlechtes Beispiel, das handelt der VDR wesendlich inteligenter als mit nem simplen Repeatfilter. An dieser Stelle reagiert der VDR einfach nicht auf Tastendrücke die als Wiederholte geflaggt sind. D.h. drücke ich "1" für 5 Sekunden dann wird der VDR nur die erste "1" nutzen und die Wiederholungen (Repeats) ignorieren.

Sollte man mal erwähnen, andere Programme haben sowas nicht.

cu

CIR bzw. nuvoton-cir, Nachlaufen von Befehlen

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema