Wie der Titel schon sagt, führt eine ungünstige Behandlung von Tasten-Wiederholungen, momentan zu einem deutlichen "Nachlaufen", wenn man eine Taste der Fernbedienung länger gedrückt hält.
Aktuell werden in put() sämtliche Eingaben in einen FIFO geschrieben, auch Tasten-Wiederholungen.
Diese werden dann von VDR abgearbeitet, solange kein release (lösen der Taste) an den VDR gemeldet wird. (oder bis zum Timeout von 1s)
Im Falle einer Tasten-Wiederholung ist dieses Vorgehen ziemlich ungünstig, da der FIFO in Sekunden voll läuft. Der VDR führt dann ständig Wiederholungen der Taste aus, bis ein release eintrifft, auch wenn die Taste schon lange nicht mehr gedrückt wird.
Da IR-Fernbedienungen nur Tastencodes senden und keine Release-Information, muss diese durch einen Timeout ermittelt werden.
Als Workaround um das "Nachlaufen" zu minimieren wird dieser Timeout möglichst knapp gewählt.
Das macht der LIRC-Code im VDR und alle Plugins so.
Diese Vorgehen hat aber den großen Nachteil, dass man "verlorene" Tastencodes nicht kompensieren kann. (So eine IR-Übertragung kann immer mal gestört werden.)
Im Falle einer Störung führt das dazu, dass die Tasten-Wiederholung als neuer Tastendruck erkannt wird, da das Release bereits erfolgt ist.
Das führt dann wiederum auch zu einem "Nachlaufen" der Taste. (Das, je nach Art der Störung richtig lang sein kann. )
Meine Lösung für das Problem:
Sicherstellen, dass maximal 1 Tasten-Wiederholung im FIFO landet.
Dadurch ist es auch nicht mehr nötig bei einem release den kompletten FIFO zurück zu setzen. Es reicht die eine Wiederholung zu entfernen.
Mit dem angehängten Patch kann man kann man den release machen, wann man will (nach 1s mach der VDR aber von sich aus einen) und es tritt kein Nachlaufen auf.
Wobei es bei mir gefühlt immer 1-2 Felder nachläuft, sobald ein repeat besteht.
Das muss aber andere Ursachen haben und ist völlig unabhängig vom gewählten Release-Timeout.
Um von der Änderung hier zu profitieren muss der Release-Timeout auf mindestens das Doppelte der Wiederholrate der FB (plus etwas Puffer) eingestellt werden. Besser das Dreifache.
Eine Inkompatibilität mit dem alten Vorgehen ist aber nicht zu erwarten und wurde von mir auch nicht festgestellt.
Die Kompensation von "verlorenen" Tastencodes funktioniert mit LIRC einwandfrei.
Der lirc.d muss dazu aber den Fehler kompensieren können. Das ist am hoch laufenden Zähler bei irw zu erkennen. (Geht der Zähler zwischendurch auf 0, konnte der Fehler nicht kompensiert werden und es wurde in neuer Tastendruck erkannt.)
Wie gut das funktioniert hängt auch von der verwendeten FB (bzw. deren Protokoll) ab und wie sie bei LIRC angelernt wurde.
Getestet wurde hier mit einer RC-5 Fernbedienung und dieser überarbeiteten Version der lirc.c: Vorschlag zu lirc.c: #97
(In der Version vom VDR ist eine entsprechende Anpassung des Release-Timeout gar nicht möglich!)
Dazu kam dann noch folgende kleine Änderung um den Release-Timeout zu erhöhen:
--- lirc.c.shf.v3 2026-04-18 00:56:28.149871081 +0200
+++ lirc.c 2026-04-25 00:13:55.825293557 +0200
@@ -23,7 +23,7 @@
#endif
#define RECONNECTDELAY 3000 // ms
-#define LIRC_REPEAT_TIMEOUT 165 // ms (longest known repeat + 15ms for jitter)
+#define LIRC_REPEAT_TIMEOUT 500 // ms sufficient to compensate 3 to 4 lost transmissions
class cLircUsrRemote : public cLircRemote {
private:Das Keyboard wurde von mir auch getestet und funktioniert weiterhin wie üblich.
Bislang aber nur ohne weiter Verbesserungen.