Schneller Vor-/Rücklauf mit Repeat "läuft nach"

Zitat von kls

Was meinst du mit "KLS 1.6 Profil"?

Das hier: http://vdr-wiki.de/wiki/index.…#Ger.C3.A4t_.22VDR_1.6.22 bzw. meine angepasste Variante mit den für yaVDR ausgelegten Tastennamen: https://github.com/yavdr/yavdr…d-conf/kls-1.6-lircd.conf

Zitat von kls

Hauptgrund hierfür dürfte die deutliche Verkürzung des REPEATTIMEOUT sein.

Ja, das hatte ich ja oben vermutet - mir ist klar, dass man da in ein gewisses Dilemma kommt, weil das Loslassen in dem Bedienungsfall eine wichtige Funktion hat.

Zitat von kls

REPEATFREQ sollte relativ unproblematisch sein. Damit soll eigentlich nur verhindert werden, daß wiederholte Tastendrücke zu schnell reinkommen. Wenn deine FB schneller als mit 100ms wiederholt, dann wird halt u.U. die erste Wiederholung ignoriert, was eigentlich nichts ausmachen sollte.

Beim continue wegen

else if (LastTime.Elapsed() < REPEATFREQ)
              continue; // skip same keys coming in too fast

springt er doch an den Anfang des while-Loops und er lässt eine Taste los, wenn er von lircd seit dem letzten gültigen Tastendruck innerhalb des Timeouts keine neuen Daten gelesen hat.
Szenario wäre jetzt also:
1. Tastendruck -> warte REPEATDELAY = 300 ms bis zum nächsten gültigen Tastendruck -> gültiger Tastendruck mit Aufruf von LastTime.Set(), repeat = true -> ist der nächste Tastendruck in weniger als REPEATFREQ = 100 ms wird er verworfen -> kommt der nächste Tastendruck nicht innerhalb von REPEATTIMEOUT = 150 ms nach LastTime wird die Taste losgelassen, was bei einem Abstand von 100 ms der Tastendrücke IMHO doch dauern passieren müsste - oder habe ich da einen Denkfehler drin?

D.h. bräuchte man zusätzlich zur LastTime nicht noch so etwas wie einen LastActivity Zeitpunkt, damit man genauer weiß wann die Taste zuletzt vom Nutzer gedrückt wurde und auf den dann auch bei den Loslassbedingung prüft?

Zitat von kls

Na das ist ja schon relativ nahe an meinen neuen Werten.
Kannst du es mal mit
#define REPEATDELAY 300 // ms
#define REPEATFREQ 100 // ms
#define REPEATTIMEOUT 150 // ms
probieren? Wichtig wäre dabei auch, daß du den Rest des Patches verwendest, denn beim Setzen des 'timeout' wird jetzt REPEATTIMEOUT verwendet anstatt REPEATDELAY:

Code

-              timeout = REPEATDELAY;
+              timeout = REPEATTIMEOUT;

Der Teil mit der Umstellung der 'if's macht keine funktionelle Änderung, sondern dient lediglich der Klarheit (die Kommentare waren "andersherum").

Klaus

Alles anzeigen

Ich nutze ja den LIRCSETTINGS-Patch. Da müsste ich erst wieder den VDR kompilieren. Ich würde deswegen eben 3 oder 4 Setupeinträge für die nächste Version präferieren. Sonst steht ja auch alles in der setup.conf. Aber eventuell probier ichs auch mal später.

Sowas in der Art: http://trac.assembla.com/VDR-M…ircsettings.patch?rev=207

Zitat von kls

Und ich würde eine Lösung präferieren, die möglichst überall "out of the box" funktioniert ;-).

Was hast du eigentlich gegen lirc_client? Die lircrc bietet zählerbasierende Repeatfilter (auf Wunsch pro Taste sepperat definierbar) und saubere (nicht grob geraten, lircd weiß ja genau wann ne Taste losgelassen wurde) Release Events.

Da werden also überhaupt keine Timings benötigt auf die man sich einigen müsste.

cu

Zitat von kls

Und ich würde eine Lösung präferieren, die möglichst überall "out of the box" funktioniert ;-).

Das wäre sehr nett.

Klaus

Na dafür gibt es ja Default-Einstellungen. Wenn es funktioniert, muss man die Settings ja nie anfassen. Bei hunderten verschiedenen Fernbedienungen und Empfängern, macht das schon Sinn, das ganze einstellbar zu machen.

Zitat von kls

Geht das denn genauso einfach wie in lirc.c?
Oder vielleicht sogar noch einfacher?

Also ich finde es funktioniert besser. Und wenn man will kann man hier auch einiges sehr viel besser einstellen.

Kannst ja einfach mal generell schauen wie das funktioniert....

Als Beispiel zur generellen Funktion, ab Zeile 92, in "c" wäre dann (beim VDR) der Tastenname, also rein prinzipiell ist das simpel.
http://lirc.git.sourceforge.ne…f81596258e22b;hb=HEAD#l92

in der lircrc siehts dann so aus

begin
  prog = VDR
  button = KEY_CHANNELUP
  delay = 2
  repeat = 2
  config = Channel+
end
begin
  prog = VDR
  button = KEY_CHANNELDOWN
  delay = 2
  repeat = 2
  config = Channel-
end
begin
  prog = VDR
  button = KEY_MUTE
  config = Mute
end
begin
  prog = VDR
  button = KEY_RED
  config = Red
end

Das ganz als Plugin hängt an, da habe ich gegenüber dem Release *) noch nen reconnect und support für k_repeat reingebastelt. Wobei da noch einiges an extra (was raus könnte) drin ist.
k_release fehlt noch, ich habe erst durch diesen Thread gelernt wofür das überhaupt gut ist

cu

*) http://www.vdrportal.de/board/thread.php?threadid=38772&sid=

Zitat von kls

Vielleicht kannst du vor diesem Hintergrund dein Szenario nochmal überdenken und ggf. neu schildern, denn momentan sehe ich noch kein Problem.

Ok, dann versuche ich es noch mal mit deiner Nomenklatur.

Also kurz ein Szenario mit einer Fernbedienung, bei der alle 90 ms ein Datensatz auf dem Lirc-Sockel erscheint, der vom VDR verwertet wird:

Zeitpunkt   0: erster Datensatz - FirstTime.Set(); LastTime.Set(); Put(KeyName, repeat);
Zeitpunkt  90: Datensatz wird verworfen, da FirstTime.Elapsed() < REPEATDELAY
Zeitpunkt 180: Datensatz wird verworfen, da FirstTime.Elapsed() < REPEATDELAY
Zeitpunkt 270: Datensatz wird verworfen, da FirstTime.Elapsed() < REPEATDELAY
Zeitpunkt 300: REPEATDELAY ist vorbei, ein neuer Datensatz danach führt zu einem erneuten Put im VDR
Zeitpunkt 360: dieser Datensatz führt zu repeat = true;  timeout = REPEATTIMEOUT; LastTime.Set(); Put(KeyName, repeat);
Zeitpunkt 450: Datensatz wird verworfen, da LastTime.Elapsed() < REPEATFREQ
Zeitpunkt 510: Taste wird vom VDR losgelassen, da timeout bzw. REPEATTIMEOUT abgelaufen
Zeitpunkt 540: nächster Datensatz von Lirc erzeugt einen neuen Tastendruck im VDR, da der VDR bereits losgelassen hat.

Meine Befürchtung ist daher folgende: Wenn REPEATTIMEOUT weniger als das Doppelte von REPEATFREQ beträgt und der zeitliche Abstand mit dem Lirc die Daten auf den Socket schreibt etwas kleiner als REPEATFREQ ist, wird fälschlicherweise vom VDR ein Release generiert, weil der erste Datensatz, der nach dem Setzen von repeat = true kommt, verworfen wird, der zweite aber erst nach dem Ablauf des timeout ankommen würde - ich hoffe du verstehst was ich meine (und dass ich den Ablauf in der lirc.c richtig verstanden habe).

LircRepeatDelay = 100
LircRepeatFreq = 100
LircRepeatTimeout = 100

Die Werte gefallen mir im übrigen noch besser. Damit lässt sich wesentlich schneller durchs Menü oder die Kanalliste scrollen. Aber da bemerke ich das nachlaufen auch. Ich bau jetzt nochmal den VDR ohne LIRCSETTINGS-PATCH und mit der Änderung:

-              timeout = REPEATDELAY;
+              timeout = REPEATTIMEOUT;

Mal sehen, ob es dann noch tut und nicht mehr nachläuft. Nutze noch 1.7.32, da lass ich die if's unangetastet. Die sehen noch etwas anders aus.

Hallo Klaus,

Wenn Du schon an dieser Ecke bastelst, dann waere dies doch nun der ideale Zeitpunkt diesen patch einzubinden:
http://www.linuxtv.org/mailing…003/09-2003/msg00853.html
So kurz vor dem 10-Jaehrigen haette das doch was
Mittlerweile ists zwar eine Variable mehr, aber es waere nett wenn diese einstellbar waeren

Lies mal weiter vorne...

Es sollte im Idealfall nicht nötig sein das GUI mit sowas weiter aufzublasen. Wenn man eine Taste drückt, dann will man sofortiges Feedback. Wenn man sie gedrückt hält, dann will man eine Art "Tastenwiederholung". Fertig.

Kein Mensch versteht was diese Einstellungen da sollen. Eine Fernbedienung soll einfach so funktionieren. Man muss ohnehin schon genügend konfigurieren um eine neue Fernbedienung mit dem VDR zu verheiraten (erst recht wenn man LIRC verwendet und eine Fernbedienung nutzen will, für die es keine lircd.conf "von der Stange" gibt).

Zitat von Mreimer

Lies mal weiter vorne...

Es sollte im Idealfall nicht nötig sein das GUI mit sowas weiter aufzublasen. Wenn man eine Taste drückt, dann will man sofortiges Feedback. Wenn man sie gedrückt hält, dann will man eine Art "Tastenwiederholung". Fertig.

Kein Mensch versteht was diese Einstellungen da sollen. Eine Fernbedienung soll einfach so funktionieren. Man muss ohnehin schon genügend konfigurieren um eine neue Fernbedienung mit dem VDR zu verheiraten (erst recht wenn man LIRC verwendet und eine Fernbedienung nutzen will, für die es keine lircd.conf "von der Stange" gibt).

Sorry - aber das ist mal wieder typisch.
Keine Ahnung von der Praxis, aber was in der Theorie passt muss einfach gut sein.
Und nur weil Du nicht verstehst warum es diese Einstellungen gibt, heisst es noch lange nicht, dass diese sinnlos sind, bzw es soll auch Leute geben die es verstehen
Ausserdem muss man gar nichts konfigurieren sondern man kann (Vernuenftige Defaultwerte helfen natuerlich auch).
Ich habe hier schon etliche Lirc Fernbedienungen in der Hand gehabt (mit diversen Lirc treibern) und ich kann Dir versichern, dass es genuegend Exemplare gibt, welche unterschiedliche Timings benoetigen.
Ganz davon abgesehen habe ich auch aeltere Semester als "Kunden", und die Druecken nun mal gerne lange und fest auf eine FB und dann solllte nicht bereits nach 300 ms ein Repeat erfolgen, sondern evtl. erst nach > 1 Sekunde.

Man könnte ja auch relativ einfach cLircRemote (und auch cKbdRemote (funktioniert eh nur noch für Sonderfälle *) )) als sepperate Plugins auslagern. In Zeiten von rc-core wird so was je eh immer interesannter http://projects.vdr-developer.org/projects/plg-inputdev

Klar, dann lässt sich der VDR ohne Plugins nicht mehr nutzen, aber das ist ja jetzt auch schon so da die dvb??device Plugins auch schon ausgelagert wurden.

cu

*) Die Anzaht der SD FF Nutzer ist vermutlich stark rückgängig, die Anzahl der HD FF Nutzer ist fix (und im Vergleich vermutlich eher gering) und die Framebuffernutzer dürften auch nur ne kleine Minderheit sein. Die meisten können cKbdRemote also eh nicht nutzen.

Zitat von helau

Sorry - aber das ist ein typischer "Reimer" (Geronimo wuerde ich den auch noch zutrauen).

Was erlaubst du dir? Meine Familie geht dich absolut gar nichts an.

Mreimer hat nur in eigenen Worten wiedergegeben, was Klaus schon gesagt hatte.

Zitat

Was erlauben HelAu ?

Sorry nimms nicht persoenlich aber das musste einfach mal raus
Ihr habt mir in den letzten Monaten derart den Spass an VDR Weiterentwicklungen versaut, dass es irgendwann mal zur verbalen Explosion kommen musste ...

Zitat von kls

Am Zeitpunkt 450 wird aber auch cFile::FileReady() wieder mit timeout = REPEATTIMEOUT aufgerufen.

Ah - genau das hab ich nicht berücksichtigt - dann sollte es sowie gehen

Zitat von kls

Um von dem festen REPEATTIMEOUT wegzukommen habe ich es jetzt nochmal überarbeitet. Es wird jetzt die Zeit zwischen je zwei LIRC-Events gemessen und der Timeout für das Erkennen des Endes einer Repeat-Funktion auf etwa 110% dieser Zeit gesetzt. Zusätzlich wird sichergestellt, daß ein Ende einer Repeat-Funktion auch wirklich nur dann getriggert wird, wenn zwischenzeitlich ein Event mit count = 0 gekommen ist.

Den Patch habe ich gerade ausprobiert, er scheint auch gut zu funktionieren.

int Delta = ThisTime.Elapsed(); // the time between two subsequent LIRC events
           ThisTime.Set();

Das ist eine sehr schöne Idee, damit dürften auch die etwas "komischen" Repeatfilter-Ansätze mit abnehmendem Abstand zwischen zwei Repeats bei länger gedrückt gehaltener Taste von eventlircd besser abgefangen werden.

Zitat von helau

Keine Ahnung von der Praxis, aber was in der Theorie passt muss einfach gut sein.
Ich habe hier schon etliche Lirc Fernbedienungen in der Hand gehabt (mit diversen Lirc treibern) und ich kann Dir versichern, dass es genuegend Exemplare gibt, welche unterschiedliche Timings benoetigen.
Ganz davon abgesehen habe ich auch aeltere Semester als "Kunden", und die Druecken nun mal gerne lange und fest auf eine FB und dann solllte nicht bereits nach 300 ms ein Repeat erfolgen, sondern evtl. erst nach > 1 Sekunde.

Ich fände ich es auch schön, wenn man das im VDR einstellen könnte - mit dem neuen Patch wären das ja nur noch zwei Werte (REPEATDELAY und REPEATFREQ) - und den Mindest-Zeitraum bis zur ersten Tastenwiederholung und den Mindest-Abstand, mit dem Tastendrücke wiederholt werden sollen kann man dem Nutzer doch eigentlich gut vermitteln.

Zitat von Keine_Ahnung

In Zeiten von rc-core wird so was je eh immer interesannter http://projects.vdr-developer.org/projects/plg-inputdev

Das wird lustig, denn durch das zwangsweise Tastenmapping außerhalb des VDR hat man dann fast die Situation wie in yaVDR mit eventlircd - nur mit dem Unterschied, dass es dann richtig fordernd wird, wenn man mal seine Maus/Tastatur für etwas anderes nutzen will - z.B. für nicht durch das externalplayer-Plugin gestartete Programme...