Das log besteht zum allergrösstem Teil aus:
SATIP-ERROR: failed to send section data (99 bytes) [device=1]
tp 110773 (18/05) read incomplete section - len = 3, r = 4096
Da wäre ich bei wirbel
Das log besteht zum allergrösstem Teil aus:
SATIP-ERROR: failed to send section data (99 bytes) [device=1]
tp 110773 (18/05) read incomplete section - len = 3, r = 4096
Da wäre ich bei wirbel
Ich vermute, wenn es nur Digital Ton gibt wird er dann trotzdem verwendet?
Eben nicht.
Soweit ich mich erinnere war Dolby bei mir oft viel leiser. Deswegen höre ich lieber mp2, und Dolby nur, wenn es kein mp2 gibt (was auch der Grund ist, warum das bei mir überhaupt an ist).
Passiert das auch ohne graphtftng bzw. wenn du so wenig wie möglich Plugins lädst?
Das Projekt gibt es seit nunmehr 10 Jahren!
* In dieser Zeit habe ich die Firmware für viele STM32 Boards entwickelt.
* Am Anfang haben olebowle und M-Reimer geholfen.
* Es gab verschiedene Erweiterungsplatinen, von ranseyer und von mir.
* Fertige Boards mit Kabelsets wurden erst von ranseyer, dann von mir und jetzt von Emma53 verkauft (hier und da).
* Entwicklung der Keyboard Variante, die erst ein proof of concept war und noch Fehler enthielt, aber inzwischen genauso gut läuft.
* Portierung auf RP2040 (Raspberry Pi Pico sowie Zero und One). Vorteil: kinderleicht zu flashen.
* Betreuung der User hier im Forum.
* Stetige Verbesserung und Einbau von Wünschen.
Neu: Für alle Sync Modi wird jetzt Stille gespielt, wo vorher Audio verdoppelt wurde.
Vorteil: keine Störgeräusche, kein Abbruch durch underruns.
Nachteil: keiner.
Deswegen ist 'Stille einfügen' kein eigener Modus mehr, sondern für schnellen Sync nimmt man nun 'early sync + fast switch'.
Denn 'early sync + fast switch' war dadurch identisch mit 'early sync + insert silence', deswegen wurde letzteres wieder entfernt.
Ich habe einen neuen Sync-Modus für softhddevice entwickelt.
Der funktioniert so:
Wenn Audio zu weit vorne ist, wird Audio angehalten und Stille gespielt, bis Video aufgeholt hat.
Wenn Video zu weit vorne ist, wird Video angehalten und ein Standbild gezeigt, bis Audio aufgeholt hat.
Das Neue dabei ist Stille zu spielen.
Vorteil: sehr schneller Sync, kein Abbruch durch underruns.
Nachteil: abhängig vom Sender gibt es manchmal merkbare kurze Stille im Audio kurz nach dem Umschalten.
Auf meinen meistgesehenen Sendern gibt es die kurze Stille nach dem Umschalten fast nie, und der Vorteil des schnellen Umschaltens überwiegt.
// davor setzen
jedoch erkennt Lirc meine vorhandene Dreambox-Fernbedienung nur im Raw-Modus und somit habe ich keine RC5, RC6 oder NEC Codes
Laut diesem Link benutzt die Dreambox-Fernbedienung aber NEC.
Edit: aber siehe hier, ist kein Standard NEC.
Da ist wohl eine andere FB angesagt.
Ich bin jetzt endlich dazu gekommen die Macro Programmierung in's MLD Setup mit aufzunehmen.
Hättest du mal ein paar Screenshots?
Es funktioniert wie gewünscht. Danke dafür!
Schön
Beim RP2040 leuchtet dauerhaft eine Weiße LED. Lässt sich das (optional) abstellen?
stm32kbdIRconfig: set - neopixel - 1 - off
Das hält allerdings nur solange er am Strom bleibt.
Aus 0x12c = 300 wird dann effektiv 342 wegen RC5,
aus 0x64 = 100 wird effektiv 114 wegen RC5,
die Werte vom VDR sind kleiner und er funkt nicht mehr dazwischen.
Da ja die Keys mit 114 ms Abstand rein kommen, ist es merkwürdig, dass der Wechsel von Wiederholintervall 100 auf 0 einen Unterschied macht. Da gibt es vielleicht eine Verzögerung durch das Betriebssystem?
Generell sollte man nur an einer Stelle filtern. Also die Werte im Empfänger einstellen und im VDR auf 0,0 ODER im Empfänger sehr klein und im VDR einstellen. Dabei ist es vorteilhaft die 114 ms Abstand zu beachten. Also Werte die nahe an 114, 228, 342 sind sollte man vermeiden und eher Werte wählen, die in der Mitte davon liegen.
Aber Versuch macht kluch
ZitatAlles anzeigenEvent: time 1718819680.549498, -------------- SYN_REPORT ------------
Event: time 1718819680.640474, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70052
Event: time 1718819680.640474, type 1 (EV_KEY), code 103 (KEY_UP), value 1
Event: time 1718819680.640474, -------------- SYN_REPORT ------------
Event: time 1718819680.655592, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70052
Event: time 1718819680.655592, type 1 (EV_KEY), code 103 (KEY_UP), value 0
Event: time 1718819680.655592, -------------- SYN_REPORT ------------
Event: time 1718819680.745502, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70052
Event: time 1718819680.745502, type 1 (EV_KEY), code 103 (KEY_UP), value 1
Event: time 1718819680.745502, -------------- SYN_REPORT ------------
Event: time 1718819680.760488, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70052
Event: time 1718819680.760488, type 1 (EV_KEY), code 103 (KEY_UP), value 0
Event: time 1718819680.760488, -------------- SYN_REPORT ------------
640 - 655: der timeout ist 15
640 - 745: 115 RC5 repeat interval, auch OK
aber die Anfangsverzögerung gibts nicht.
Entweder im VDR die Wiederholverzögerung hochsetzen ODER im Empfänger repeat_delay hochsetzen.
evtest gibt auch nur 0 und 1 aus, keine 2 für repeat - ist das ok?
Rätselhaft. Der vdr bekommt die Eingaben über lirc, aber irw, der lirc anzeigt, ist schneller als der vdr.
Blöde Frage: Warst du mit irw am selben socket den der vdr benutzt? Hast du irgendein Plugin/Patch, das da noch filtert?
Bringt
Wiederholverzögerung: 0
Wiederholintervall: 0
was?