Evtl. eine blöde Idee, aber könnte es am fehlenden EPG liegen?
IPTV hat im Gegensatz zu fast allen DVB-Empfangswegen, kein EPG.
RunningStatusUndefined könnte ohne EPG irgendwie Sinn machen.
Posts by SHF
-
-
Oh je, wörtlich sollten die das mit dem China-Kracher doch nicht nehmen
.Nach deinem Bild vom SO-DIMM zu urteilen, könnte man vermuten zuerst hätte der dicke keramische Vielschicht-Kondensator dort einen Kurzschluss durch Bruch erlitten,
auf dem Ram Modul zu exorbitanter Stromaufnahme geführt und so die +5V (Pin1 und Pin 3) am Slot verschmort und den Spannungsregler auf dem Ram gekillt..Sieht mir auch stark nach dem Spannungsregler auf dem RAM als Ursache aus.
Dass Vielschicht-Kondensatoren einen Kurzschluss bekommen, ist anscheinend gar nicht so selten. (Das tritt bei einigen Playstation-Modellen wohl öfters auf. https://www.youtube.com/watch?v=vKSbJUEtU-o ab~8:00)Wie es aussieht haben sich die Chinesen dazu wohl die Sicherung gespart (sind nicht ganz billig) und dann sind die vollen Ampere der 12V-Schiene da durch die kleinen Drähte geflossen.
Die Sache mit den 12V Steckern wird wohl auch nichts mit dem Problem zu tun haben.
Eher nicht, das sollte nichts machen, ist mir auch schon passiert.
Anderenfalls liegt da IMHO ein Konstruktionsfehler im Board vor.Wobei die 12V vom RAM (DDR5 läuft direkt mit 12V) wohl durch diesen Stecker kamen.
Möglicherweise hat das NT überlebt, aber das müsste getestet werden.
Da das NT nicht abgeschaltet hat und die Drähte recht dünn sind, müsste es das NT eigentlich gut überstanden haben.
Das Board lässt sich evtl. auch retten, wenn man den Ram-Slot tauscht.
Wenn man alles sauber macht (Kohle ist leitfähig!) und das Board dann ohne RAM soweit startet, dass es Fehlercodes piepst, könnt man Glück haben. -
Code
Found valid MBR and GPT. Which do you want to use? 1 - MBR 2 - GPT 3 - Create blank GPT Your answer: 1Da original mit GPT formatiert war, mach MBR auch keinen Sinn.
Wenn ich das recht erinnere unterstützt MBR auch keine Partitionen über 2 GiB.Die Position der Partitionen aber liegt glücklicherweise gleich.
Der Unterschied ist hier:
SATA:
Logical sector size: 512 bytes
USB:
Logical sector size: 4096 bytes
Beispiel: Beginn der 2. Partition:
956825856 *8 = 7654606848Wieso die Logical sector size unterschiedlich ist, verstehe ich momentan auch nicht. Eigentlich sollte die Partitionierung von der Schnittstelle unabhängig sein.
Evtl. liegt es aber an der defekten GPT, darin müsste die Logical sector size eigentlich definiert sein.
Man kann die Logical sector size bei gdisc und co AFAIK auch vorgeben, ob das der richtige Weg ist, bin ich aber nicht sicher.
Man könnte auch an der SATA-Schnittstelle einfach mit testdisk eine neu GPT schreiben und schauen, was passiert.
Evtl. vorher mit gdisc eine leere GPT erstellen (2), um den alten Schrott los zu werden.Da wird man wohl etwas experimentieren müssen.
Sobald fsck die Partitionen akzeptiert sollte man es aber eigentlich geschafft haben.
Wichtig ist nur, solange nicht auf die Partitionen schreiben. -
"MS Data" steht da bei allen anderen HDs auch. Sollte da ext4 stehen?
Bei MBR fallen die ganzen ext* Typen unter "0x83". (Siehe Tabelle "MBR (hex)")
Bei GPT gibt es da mehrere GUIDs, eine "normale" Partition ohne Extras (automount, root, ...) sollte GUID 0FC63DAF-8483-4772-8E79-3D69D8477DE4 haben. (Kann leider nicht so einfach nachschauen, die Platten mit GPT sind ständig in Benutzung.)Ich hatte als Anzeige jedenfalls sowas wie "Linux", "Linux native", "Linux ext2", ... erwartet.
Wobei ich nicht sicher bin, ob ich Testdisk jemals mit einer GPT-Platte verwendet habe. Zum Spaß macht man sowas ja nicht
.Wenn es bei den anderen HDDs auch so ist, wird es wohl o.k. sein.
Solange die Dateisysteme von Linux korrekt erkannt werden, würde ich mir keinen Kopf machen.
Wichtig sind eigentlich primär die Positionen von Anfang und Ende der Partitionen. (Solange man die Partition nicht formatiert, ist sogar das Ende eigentlich egal. Das früher auch gerne als Trick angewendet, wenn das BIOS die neue große Platte nicht vollständig erkannt hat.)
Sobald das Dateisystem gemountet ist, werden eh die Geometrie-Daten von da verwendet. Bei der Partitionstabelle muss man eigentlich nur aufpassen, dass da nichts kollidiert.Sollte es mit der Erkennung Probleme geben muss man die GUID halt mit gdisk noch ändern.
Und die Dateien sind da, nach Quicksearch werden sie mit Taste p angezeigt, auf beiden Partitionen. Auch viele in rot, was gelöscht bedeutet. Wenn ich mich nicht täusche, sind darunter leider auch welche, die nicht von mir gelöscht wurden. Wie viele das betrifft, kann ich erst mal nicht sagen.
Das können auch ältere Versionen der Datei sein, die aktuelle Datei selber kann trotzdem noch vorhanden sein.
Die Anzeige von Testdisk ist auch ziemlich unübersichtlich, ich würde mich damit nur befassen, wenn wirklich was am Dateisystem schief gegangen ist.Erstmal die GPT reparieren und normal (aber read-only!) mounten und schauen, ob was fehlt.
Vorher am besten noch e2fsck -fvn ("-n" read only Mode) drüber laufen lassen und schauen, ob Fehler gefunden werden. Wenn der Test keine Fehler findet, sollte normalerweise auch nichts fehlen.Wollte nochmal anmerken, dass dies jetzt alles am USB-Anschluß passiert. An SATA kann das noch anders aussehen.
Wenn es nicht das "3,3V-Problem" ist, könnte es sein dass der SATA-Treiber die Protective-MBR ignoriert und deshalb nicht mountet.
Testdisk und gdist sollten aber eigentlich auch mit SATA gehen. -
Jetzt wirds klarer.
Ich würde sagen GPT und MBR sind beide hinüber und die Reserve GPT auch.
Warum auch immer.Bei dem empfohlenen Intel ist das Ende der 2. Partition 175 Sektoren größer als bei GPT: 996680960 - 996680785
Mit Intel meinen die AFAIK den "alten" MBR.
Da macht es anscheinend eine Unterschied, ob man die Platte mit GPT oder MBR betrachtet.
Zumindest dürfte hier das Problem liegen, das sind die 175 Sektoren über die sich auch gdisk beschwert.GPT scheint also auf den tatsächlich letzten Sektor zu zeigen, oder? Oder ist das der von testdisk erzeugte, zu berichtigende Eintrag? Muß ich den nur versuchen zu schreiben? Wenn klappt, dann gut? Wenn nicht, Kopie des derzeitigen zurück, um wieder den jetzigen Stand zu erhalten, oder wiederherzustellen?
Ich denke, man könnte es wagen mit testdisk im GPT-Modus eine neue GPT auf die Platte zu schreiben (die Alte ist eh hinüber und es gibt ein Backup).
Das Erkannte sieht von den Größen her eigentlich gut aus. Der letzte Sektor passt jetzt auch mit der dem "last usable sector" von gdisk zusammen.Der Dateisystem-Typ "MS Data" ist falsch und müsste per Hand vorher korrigiert werden. Das wundert mich ein wenig.
Man könnte auch mal die deeper search versuchen, vielleicht findet die auch die korrekten Dateisysteme.Dann mal mit gdisk testen, was das dazu sagt.
Schritt für Schritt Wiederherstellungsbeispiel
Abweichungen: GPT-Modus verwenden und Dateisysstem "Linux"
Den ganzen NTFS-Kram kann man ignorieren. -
Der Chinakracher hätte gegenüber dem Asrock jedoch aber auch DDR5-Slots für den RAM
Das war mir in der Tat entgangen.
Die angegebenen Preise bei CWWK sind DDP (= Delivered Duty Paid = Geliefert verzollt) Deutschland!
Das hatte ich gesehen, so geht der Preis noch, auch wenn es wahrlich kein Schnäppchen ist.
Wenn man sich selber darum hätte kümmern müssen, wäre das Angebot völlig IMHO uninteressant gewesen.Der Perfektionist in mir würde sagen: Fabrik-Kühlkörper abnehmen, ersatzweise hierfür einen passenden Kupferblock anfertigen lassen, der nach unten zu den Mainboard-Löchern passt und oben zum "Oberteil" und den Heat-Pipes des Streamcom.
Für eine 15W CPU?
Ich hatte gehofft, dass der Streamcom-Kühler direkt passt, der hat auf den Bildern Langlöcher.
Wenn die 51mm auf der Zeichnung stimmen, könnte es aber eng werden. Ich habe irgendwas mit 75mm bei Intel in Erinnerung. -
Was meinst du damit, bzw. was vermisst du?
Distributionsmäßig meine ich. Meist gibt es pro Box/Board nur Eine die das wirklich unterstützt.
Beim x86 hat man da viel mehr Auswahl. -
Was ist denn der Unterschied der jeweils ersten Ausgabe bei Intel und GPT und der Zweiten?
Die zweite Ausgabe bei Intel und GPT nämlich eigentlich gut aus.
Die erste bei beiden nicht.
Irgendwie kann ich mir dam momentan keinen Rein drauf machen.
-
Bei dem Preis für den Chinakracher würde ich Abstand davon nehmen. Das ist ja deutlich teurer als das Asrock und dann hat man noch den Aufwand mit dem Import.
Auch diese ARM-Boxen begeistern mich nicht so, da man in der Software-Auswahl doch ziemlich eingeschränkt ist. (Wobei sich da inzwischen schon einiges tut, auch bezüglich mainline Unterstützung im kernel)
Persönlich finde ich immer noch ein x86-System am stressfreiesten, da kann man auch einfach die Distro der Wahl installieren.Da das Asrock N100M als Markenboard mit N100 jedoch einen propriäteren Kühlkörper drauf hat, den man erst mühsam "umbauen" müsste, damit man das Board mit der passiven Gehäuse-Kühlung des Streacom verwenden könntehabe ich mich nach Alternativen umgesehen.
Der Kühlkörper ist nur von unten verschraubt. Ich habe schon Bilder gesehen, wo Leute den entfernt hatten. Übrig bleiben dann 4 Löcher im Quadrat.
Das Einzige, was eventuell problematisch werden könnte, ist der Lochabstand. Der sieht zwar brauchbar aus, das sagt aber leider nicht viel. Maße dazu habe ich bislang keine gefunden.Bei Linux ist bei HDMI 2.0 Schluss.
Das trifft nur auf AMD zu.
Bei Intel wird das AFAIK per Hardware erledigt (Displayport->HDMI Wandler) und NVIDIA ist nicht opensource. -
Mir hätte jetzt so ne erprobte Vorgehensweise geholfen, bei der man nicht sicherheitshalber die Datensicherung machen muß.
Das ist leider prinzipiell schon unmöglich.
Es kann immer was schief gehen, dann hilft nur ein Backup.Außerdem zerschießt hier wohl niemand regelmäßig seine Platte und jedes mal ist auch individuell.
Die Partitionierung erfolgte damals mit gdisk.
Dann sollte die GPT maßgebend sein.
An USB wird bei gdisk die ungültige GPT angemeckert, und der Vorschlag gemacht, den korrekten MBR zum Erstellen einer GPT zu verwenden (destructive), und bemeckert die Überlänge.
In dem Fall handelt es sich nur um einen Protective- oder Hybrid-MBR, der dazu dienen soll, dass die Platte von einem Legacy-System nicht als leer erkannt und versehentlich formatiert wird.
Die Informationen aus dieser MBR sind mit Vorsicht zu genießen. Ein einfaches zurückschreiben in die GPT wird nicht empfohlen.Warning! Secondary partition table overlaps the last partition by 175 blocks!
Für mich sieht es so aus, als ob die Backup-GPT in dem MBR der zweitem Partition zugeschlagen wurde.
Solange man die zweitem Partition nicht formatiert ist das egal, man kann ja nicht über das Dateisystem hinaus schreiben.Das Dateisystem der zweitem Partition sollte also immer vor der Backup-GPT enden, auch im MBR Modus müssten also am Ende der zweitem Partition entsprechend 175 blocks a 256Byte (oder 4K???) frei sein.
Das sollte sich mit GParted (MBR-Mode) eigentlich anzeigen lassen (sofern das im aktuellen Zustand irgendwas anzeigt).Mit Testdisk sollte man aber an die korrekte Größe der Dateisysteme und deren erste Sektoren kommen.
Eigentlich sind nur diese Daten wichtig, daher notieren Zwecks Abgleich mit der regenerierten GPT.Wobei die Partition laut MBR sogar über die Platte hinaus geht und trotzdem freie Sektoren existieren:
Disk /dev/sdd: 1953506646 sectors
last usable sector is 1953506640
Total free space is 506 sectors (2.0 MiB)Number Start (sector) End (sector) Size Code Name
1 256 956825599 3.6 TiB 8300 Linux filesystem
2 956825856 1953506815 3.7 TiB 8300 Linux filesystemDas ist so eigentlich unmöglich.
Ich vermute mal, dass die Umsetzung MBR in GPT gründlich daneben gegangen ist.
Anderenfalls hätte die HDD ihre Geometrie geändert und das wäre gar nicht gut.Mal probiert, Backup des GPT ergibt ein File von 17920 Byte, 70*256Byte. ???
Die Größe spielt wohl nicht wirklich eine Rolle, da die Partitionen normalerweise an MiB-Grenzen ausgerichtet werden.
Bei der aus der MBR regenerierten die Ausrichtung scheint zumindest das zu stimmen:
Logical sector size: 4096 bytes
Partitions will be aligned on 256-sector boundaries
256 * 4KiB = 1MiBDa jetzt ein externes Backup der GPT existiert, könnte man mal versuchen die GPT aus der Backup-GPT der Platte wiederherzustellen. Die sollte normalerweise noch intakt sein.
Expertenmenü R, Taste B und C.
Im Erfolgsfall sollte die Fehlermeldung von gdisk dann verschwunden sein. Auch sollten die fehlenden GUID wieder hergestellt sein.Wenn die wiederhergestellte GPT zudem mit den Partitionsdaten von Testdisk (Startsektor und ausreichend Platz bis zur nächstem Partition/Ende) übereinstimmt, kann man die eigentlich übernehmen.
Wenn dann e2fsck -fvn (read only) ohne Beanstandung durchläuft und (-ro) Lesetests erfolgreich sind, könnte man es wagen die Platte wieder -rw zu mounten.
gdisk sieht 2 Partitionen
Nein, gdisk sieht nur eine defekte GPT und geht daher in Konvertiermodus.
Wenn Du irgendwie auf die Platte zugreifen kannst, dann aufgrund des Protective- oder Hybrid-MBR.
Mit Schreibzugriff in dem Modus wäre ich aber extrem vorsichtig. -
stoppt also die Wiedergabe von VDR.
Das XineLibOutput-Plugin stoppt die Wiedergabe auch, wenn den Player verbindet/entfernt. Das scheint wohl nötig zu sein, wenn man das primäre Device wechseln will.
Das Plugin wird beim Verbinden des Players primär und gibt den Status auf, wenn man den Player schließt.
Gedacht ist das um von zB. der FF-Karte auf XineLibOutput umzuschalten und zurück.Wie die das intern gelöst haben, weiß ich aber nicht.
-
Ich wüsste nicht, dass ich den Parameter je benutzt hätte.
Allenfalls dann ganz am Anfang.
Wenn meine vage Erinnerung stimmt hat das mit der SVDRP-Übertragung Anfangs auch nicht so recht funktioniert.
Kann aber sein, dass ich das mit VDRadmin durcheinander bringe. -
Found invalid GPT and valid MBR
Da wird wohl wirklich ein Fehler in der primären GPT sein.
Der erwähnte MBR wird ein Protective- bzw. Hybrid-MBR sein. Den Daten würde ich nicht trauen.Problem hier ist aber, dass die Position nicht bekannt ist. Das ginge AFAIK aber auch irgendwie, da müsste ich aber auch suchen.
Zu kompliziert gedacht, die Backup-GPT liegt am Ende der Platte.
Wenn da nicht hardwaremäßig was mit der Geometrie schief gegangen ist, sollte die sich also finden lassen.Sicherheitshalber dann noch mal die Backup-GPT mit dem was Testdisk sagt abgleichen.
Ohne reparierte GPT sollte man die Platte jedenfalls nur read-only mounten.
Im Zweifelsfall lieber die Daten kopieren und neu partitionieren. -
Bei der Gelegenheit hätte ich auch gerne gewusst, ob noch jemand statt des internen svdrp-Calls die Möglichkeit eines externen Skripts nutzt (da kann man dann die Fehlerrückgabe komplett vergessen).
War das nicht noch ein Relikt ganz aus der Anfangszeit?
Das wurde doch schon vor Jahrzehnten umgestellt. Ich wusste gar nicht, dass überhaupt noch geht. -
Daten sichern
Auf jeden Fall, bevor man was rum fummelt!
Man kann auch mit dd ein Abbild der ganzen Platte machen und dann daran rum experimentieren.
Was mich etwas wundert, ist dass die GPT sich nicht wiederherstellen ließ.
Normalerweise ist die nämlich eine Sicherung vorhanden: Wikipedia: GUID_Partition_TableNach der Sicherung würde ich einmal badblocks mit dem non-destructive-read-write-test über die ganze Platte (/dev/sdx) jagen.
Dann sieht man, ob es irgendwo Lesefehler gibt und das frischt die Magnetisierung auf (dauert aber leider Tage).Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: not presentIrgendwie ist das komisch. Sicher, dass da eine GPT drauf war?
Wenn ja, würde mal einen Fehler in der primären GPT vermuten.Man kann mit gdisk die aktulle GPT in eine Datei sichern. Das sollte man als erstes mal machen.
Dann gibt es die Möglichkeit die primäre GPT aus der Sicherung wiederherzustellen: https://wiki.ubuntuusers.de/gdisk/#Expertenmenue-R
Problem hier ist aber, dass die Position nicht bekannt ist. Das ginge AFAIK aber auch irgendwie, da müsste ich aber auch suchen. -
Ein weiterer Grund, warum er raus muss
Vom mir aus gerne.
Du glaubst auch nicht, was diese Zeile mich bei der Fehlersuche an Nerven gekostet hat
.Ich kann aber nicht beurteilen, ob es nicht doch irgendwer benutzt. Mit einem RcRepeatDelay von ~120-150ms könnte es zumindest brauchbare Resultate liefern.
Daher mein Vorschlag aus #91, der sollte bei Default-Werten zumindest keinen Schaden anrichten.
Ich bin aber, wie gesagt, nicht sicher, ob man das machen soll.Das timeout muss auch geändert werden, denn sonst würde in #44 nach den ersten 40 ms der timeout auf 60 ms gesetzt, dann der Repeat nach 108 ms fälschlich als Neuer erkannt, und dann die ersten weiteren wegen Delay fälschlich ausgefiltert.
Stimmt, das war auch eine der Überlegungen, warum ich das umgestellt habe. Das habe ich aber vergessen zu erwähnen.
Das mit dem Faktor ist generell ungünstig, da der Jitter konstant ist. Man sollte besser eine feste Zeit addieren.
Um den Fall abzufangen wären da aber mindestens 50ms nötig gewesen.
Da wäre man bei RC-5 etwa bei meinem Vorschlag. (Mit einem Faktor wäre das schon nicht mehr sinnvoll.)Wenn man eine Timer verwendet müsste man den Wert also nach oben und unten Begrenzen, Bereich etwa: 115...180ms. Den Aufriss spart man sich halt mit einem festen Timeout von 165ms.
Außerdem ist noch die Frage #36 offen. Dass es Releases NUR nach Repeats gibt, ist ziemlich ungewöhnlich.
Zur entsprechenden Stelle im VDR-Code habe ich mich bislang nicht vor gearbeitet.
Nach meinen Tests sind Releases aber wirklich NUR nach Repeats nötig.
Außerdem machen es die anderen Eingabe-Methoden auch so. -
Ein anderes Netzteil könnte man noch mal versuchen.
Das Einschalten ist mit der stärkste Belastungszustand fürs Netzteil.
Einschaltprobleme sind bei sterbenden Netzteilen oft mit die ersten Anzeichen.
Es könnte auch ein falsches, zu schwaches Netzteil die Ursache sein.Die Hohlstecker neigen auch gelegentlich zu Kontaktproblemen.
-
Neben MLD hatte ich mich ja auch schon an yavdr Ansible versucht. Es sind ja beides eigentlich reine vdr-Distros die ähnlich wie früher der Videorekorder nur dem einen Einsatzzweck dienen.
Yavdr ist eigentlich auch nur ein normales Ubuntu plus die VDR-Pakete aus seahawks PPA plus das Ansible Skript/Playbook für die Grundkonfiguration.
Niemand hindert Dich noch zusätzliche Pakete von Ubuntu zu installieren.
Andersherum ist es auch möglich das VDR-Pakete aus seahawks PPA einfach so unter Ubuntu zu installieren, ohne Playbook.
Allerdings muss man sich dann überlegen, wie man das mit dem Übergang zwischen den Anwendungen gestalten will.
Wie rum man da am geschicktesten vorgeht, bin ich aber auch nicht sicher, da ich so ein Setup nicht habe.Das erwähnte PPA ist momentan wohl das best gepflegte und umfangreichste zu dem Thema. Daher macht es, denke ich, Sinn darauf zu setzen. Besonders, da mit Mint schon gewisse Erfahrungen im Ubuntu/Debian Bereich bestehen.
Softdevice-ATTACH aufschaltetst und abschaltest.
Irgendwo wurde das doch schon für das Umschalten zwischen VDR und Kodi verwendet.
Ich weiß nicht ob eine Fernbedienung queer über den Desktop verschiedene Programme starten kann...
Ja, spätestens mit einem lirc-tools müsste das gehen: lircmd, irexec, irxevent..
Mit lirc kann man sogar eine Maus emulieren.Die meisten Mediaplayer (Mplayer xine, ...) kann man auch mit lirc bedienen.
Für den wird man dann doch besser zu Keyboard greifen. -
Als TV-Karte kommt eine Digital Devices Cine CT V6.1 (Empfang von DVB-C von einem lokalen Anbieter) zum Einsatz. Den Treiber für die TV-Karte habe ich nach Anleitung von DD selbst kompiliert und eingebunden.
Wenn die PCI-ID in dieser Liste auftaucht, braucht es den externen Treiber nicht.
https://git.kernel.org/pub/scm/linux/…ridge-hw.c#n327Ich habe schon geschaut, eine schöne Software out of the box wie den DVBViewer scheint es unter Linux nicht zu kaufen zu geben.
Unter Linux läuft das eher anders, da wird das Problem gerne ich handliche Teile zerlegt.
VDR fürs Fernsehen(DVB)
KODI oder ein anderer Player für die Medianwiedergabe.
Eine Distro wie yaVDR kümmert sich dann um die Integration von dem Ganzen in ein Grundsystem und so Dinge Wakeup für die Timer, was normalerweise nicht Standard ist.
Was Du suchst ist also eine dieser HTPC-Distros.
Welche ist dann Geschmacksfrage und kommt drauf an, was man will.Ich würde nach Möglichkeit aber bei einem verwandten Grund-Linux auf allen Systemen bleiben, sonst wird das zu unübersichtlich, besonders für Anfänger. Da sind dann zB. die Befehle für die Paketverwaltung usw. nahezu identisch. Bei Dir also irgendwas aus dem Debian/Ubuntu/Mint... Bereich.
Oder halt sowas wie MLD, das geht aber schon fast in Richtung Image, wie man es für Receiver kennt.
Aktuell habe ich Ubuntu 24.04 auf dem HTPC und schon mit yaVDR 0.7 getestet, aber da scheint das aktuelle Ubuntu nicht ohne Weiteres zum yaVDR zu passen.
Den Installer gibt es so nicht mehr, da muss man inzwischen mit einer normalen Grundinstallation anfangen.
Details muss aber jemand anders beisteuernDie Pakete gibt es aber mindestens für 22.04, ob die für 24.04 schon für Anfänger zu empfehlen sind kann auch ich nicht sagen.
YAVDR für Ubuntu 22.04 LTS
22.04 LTS hat aber auch Support.Im Live-System kann ich dann aber wahrscheinlich Live-TV oder Sendungen aufnehmen nicht gleich out of the box testen oder, da das System meine TV-Karte ja noch gar nicht kennt?
Wenn die Karte in der o.g. Liste auftaucht, ist der Treiber im Kernel und die sollte out of the Box gehen.
-
Dann doch lieber zurück zu KISS:
Meine bisheriger Patch ist ja eigentlich nur ein refactoring, der die Funktion vereinfachen und übersichtlicher machen soll.
Eine funktionale Änderung ist nicht (erstmal) angestrebt.Zeile 145 und 146 sind ein Workaround für nicht-toggelnde Protokolle, der aber toggelnde Protokolle stört, und die müssen raus.
So wie es für mich aussieht, würde es mit den Default-Werten auch bei nicht-toggelnden Protokollen zu komischen Effekten kommen.
Evtl. könnte man es aber so machen:
Diff
Display More--- lirc.c.shf.v2 2025-12-05 23:41:44.732223113 +0100 +++ lirc.c 2025-12-09 23:58:59.751888824 +0100 @@ -139,6 +139,8 @@ continue; } if (count == 0) { // new key pressed + if (strcmp(KeyName, LastKeyName) == 0 && LastTime.Elapsed() < (uint)Setup.RcRepeatDelta + 10) + continue; // Workaround for remotes with key bounce / chatter. Set RcRepeatDelta 3-5ms below the actual repeatrate of the remote. if (repeat) Put(LastKeyName, false, true); // generated release for previous repeated key strn0cpy(LastKeyName, KeyName, sizeof(LastKeyName));Das sollte mit dem default Wert von RcRepeatDelta sicher, da unerreichbar, sein.
Selbst einem höheren Wert ist die Chance, dass man zufällig dieses 10ms Fenster trifft eher gering.Zum Aktivieren müsste man RcRepeatDelta ca. 3-5ms unter sie Wiederholrate der FB einstellen.
Das ließe sich ganz gut ermittel, in dem man RcRepeatDelta solange erhöht, bis sich die Wiederholgeschwindigkeit schlagartig halbiert. Dann geht man einfach 3-5ms zurück.Das wäre dann so die Minimallösung um das Prellen wenigstens einigermaßen in den Griff bekommen zu können.
Ob das bei prellenden Fernbedienungen wirklich hilft, müsste aber jemand mit einer Solchen mal probieren. (Ich habe meine derzeit leider nicht am Start, erinnere mich aber, dass mich das Prellen schon ziemlich genervt hat.)
