Posts by jrie
-
-
Ich habe die Firmware auch auf einem RP2350 erfolgreich getestet.
Die Reihenfolge der Rechenpower der unterstützten Mikrocontroller ist RP2040 < STM32F103 < … < STM32F401< RP2350.
Der RP2040 ist also der Schwächste, der RP2350 der Stärkste.
Raspberry Pi verspricht den RP2350 mindestens bis 2045 zu produzieren.
In China gibt es RP2040 Boards ab 1,50 €, RP2350 Boards ab 2,50 €. Wenn man neu kauft, ist der RP2350 ratsam, wenn man bereits einen RP2040 hat, kann man dabei bleiben. -
Ich habe die RGB-LED überarbeitet. So sieht es jetzt aus:
Empfänger RGB-LED stromlos aus USB eingehängt weiß (oder custom) USB suspend orange IR Empfang flackert blau Wakeup speichern blinkt schnell rot Wakeup blinkt schnell rot Reboot blinkt schnell rot IR senden kurz gelb VDR läuft rot VDR nimmt auf blinkt rot entsprechend Anzahl Aufnahmen Konfigurationsbefehl kurz grün Siehe auch https://github.com/j1rie/IRMP_STM…gnals-from-leds
Man kann sie auch immer noch komplett ausschalten. Aber da sie jetzt im Suspend auf schwach orange geht, ist das vielleicht gar nicht mehr nötig.
-
Macht es einen Unterschied, was für einen Sync Modus du einstellst? (softhddevice.SoftStartSync in der setup.conf?)
-
-
Es gibt neue Firmware. Wenn die RGB LED bei Inaktivität aus ist, sollte sie jetzt auch bei Aktivität aus bleiben.
Du könntest probieren, ob das stm32kbdIRconfig_cmd Binary von MLD-6.5 auch auf der MLD-5.5 läuft. Wenn nicht, frag clausmuus, ob er dir das für die MLD-5.5 kompiliert. Das wäre die einfachste Lösung.
Ich bin neugierig: Hättest du mal ein Foto von deinem Empfänger?
-
Die RGB-LED leuchtet sporadisch, wohl je nach Programmstatus, in allen möglichen Farben mit großer Helligkeit. Da die RP2040-One permanent mit Strom versorgt wird, leuchtet die RGB-LED auch sporadisch auf, wenn der VDR ausgeschaltet ist. Dieses Verhalten stört ungemein, besonders wenn die Umgebung dunkel ist.
Das werde ich durch ein Firmware Update ändern, so dass die LED komplett aus bleibt.
Dann könnte auch in der MLD-5.5 die RGB-LED ausgeschaltet werden, da hier der Befehl „stm32kbdIRconfig_cmd /dev/...“ nicht zur Verfügung steht.
Das wäre kompliziert und werde ich momentan nicht machen. Denn dann müsste ich das mir im Eeprom merken, und dazu müsste ich zu viel ändern.
Notlösung in Software: MLD-6.5 starten (Live ISO vom Stick), LED ausstellen, MLD-5.5 starten. Oder rückportieren.
Ich erinnere mich, daß in der MLD-6.4-Version vom März 24 die RGB-LED immer ausgeschaltet war.
Da war die RGB-LED noch gar nicht in die Firmware eingebaut.
-
-
-
https://www.vdr-portal.de/forum/thread/128724-dddvb-in-kernel-integrieren-für-tt-s2-1600/
Keine Ahnung, ob das noch so geht, aber ging mal.
-
clausmuus hat den Empfänger gelobt:
QuoteDer Empfänger ist das beste was seit dem Homebrew entwickelt wurde und funktioniert mit nahezu jeder Fernbedienung ohne zusätzliche Treiber.
https://www.minidvblinux.de/forum/index.ph…3.html#msg85353
Wenn man eine schönere GUI will (RE: IRMP auf STM32 - ein USB-HID-Keyboard IR Empfänger/Sender/Einschalter mit Wakeup-Timer), kann man das neueste mld-qemu.iso in einer virtuellen Maschine starten und es ausprobieren.
-
-
Ich habe das Plugin xine in mein git gestellt.
Kann kein h265, aber sonst immer noch gut.
-
-
it is safe to assume audio clock and video clock have always valid value?
Not in case of audio only or video only.
The only possibility I see for deduplication is:
int calculate_video_audio_diff(void) {
if (audio_clock != (int64_t) AV_NOPTS_VALUE && video_clock != (int64_t) AV_NOPTS_VALUE) {
return video_clock - audio_clock - VideoAudioDelay;
} else {
return AV_NOPTS_VALUE;
}
}but I am not sure, if that makes sense.
-
2 times the same code.
In trickspeed and in stillpicture we are in a recording and all data are already available.
Does that imply it is safe to assume audio clock and video clock have always valid value?
If so, we could easily simplify the code by putting trickspeed and stillpicture code into that part of xxxSyncDecoder(). -
2 times the same code.
Yes, I saw it, too. But had not enough time.
Or make PR
Done.
-
Gute Frage.
Habe ich vorsichtshalber von https://github.com/j1rie/vdr-plug…2/audio.c#L2526 übernommen.
Jetzt kommt langsam die Erinnerung. Ist gegen einen pts wraparound.
-
My attempt to fix play after slow-forward: https://github.com/j1rie/vdr-plug…398fc06d924973b
Seems to work, but hardly tested.
If some people test it and it's OK, I will make a pull request.
-
The slow-play-fix branch does not work yet. I assume it is work in progress.
My idea how it should be done is here: RE: Rückgabewert von cDevice::Poll wird ignoriert