Posts by wirbel

Eine 'SK hynix SC311' 256GB ist nicht NVMe, das wird wohl nur SATA sein. Möglicherweise ist der SATA controller nicht im Kernel aktiv oder defekt.

1962 meint wohl 'kein Betriebssystem gefunden'

Selbst wenn man eine alte Distri hat, kann man ja den gcc mal selbst neu bauen.

Die Bedienung unverändert zu lassen, wäre hier keine schlechte Idee.

Mit satip hat das nichts zu tun.

Ich mag nicht mehr weiter diskutieren und unsubscribe jetzt hier.

Der code ist gerade auskommentiert, damit ich weiß wo ich nach viel verwendeter Zeit bei der Fehlersuche endlich stehen geblieben bin und später weiter machen kann.
Die Stelle in einem großen blob von fremden Quellcode von einem klasse Programmierer, der in der Vergangenheit mal an VDR interessiert war und leider ausgestiegen ist..

Das Problem ist nicht, dass ich irgend etwas 'kaputt' gemacht habe, es ist eben ein Stück code, der VDR völlig unbenutzbar macht, wenn er auf einem verschlüsselten Kanal getriggert wird, egal welche Quelle. Und der alt ist und schwierig zu fixen ist, und in dieser Situation alle Aufnahmen ruiniert. Das syslog läuft dann voll mit > 10 Messages/sec.

Und natürlich will jeder mehr als zehn Meldungen im syslog per sec + kaputte Aufnahmen haben für ein mini feature.

Quote from hugoboss00

Das Feature der Device Umschaltung funktioniert nicht mehr. Du hast den Code als "broken" kommentiert, obwohl er bestens funktioniert.

Sachliche frage: Wirst du das zeitnah fixen bzw reverten?

Ich bin niemandem Zeitpläne schuldig. Und erst recht nicht dir, als jemand der selbst nicht coden mag.
Und noch was. Mein git ist mein letzter Stand, an dem ich irgendwann weitermachen möchte.

Auf https://github.com/vdr-projects/vdr gibt es einen Mirror von @M-Reimer, der maximal ein-zwei Tage hinterher sein wird und auf den einige von uns Nutzern ab&&zu draufschauen, wie aktuell der ist.

Magst du den als zweite Download Quelle vermerkern?

Nein, das war nur unhöflich.

git clone git://git.tvdr.de/vdr.git -> funktioniert

tarball downloaden -> funktioniert

Keine spürbare Einschränkung.

Du klingst gar nicht nach einem 'sorry', eher unhöflich. Nur so als Anmerkung.

Dann, wenn ich mal Zeit habe.

Der PR sieht btw. gut aus.

udev rule sollte eigentlich gehen, udev organisiert ja alle diese links in /dev. Vielleicht mal spielen damit..

udev-hwdb update &&
udevadm info -a -p /sys/class/dvb/dvb0.frontend0

Da kommt dann eine Liste von Attributen raus, die man nutzen könnte, z.B. so etwas

udevadm info -a -p /sys/class/dvb/dvb0.frontend0

  looking at device '/devices/pci0000:00/0000:00:1b.3/0000:04:00.0/dvb/dvb0.frontend0':
    KERNEL=="dvb0.frontend0"
    SUBSYSTEM=="dvb"
    DRIVER==""
    ATTR{power/control}=="auto"

  looking at parent device '/devices/pci0000:00/0000:00:1b.3/0000:04:00.0':
    KERNELS=="0000:04:00.0"
    SUBSYSTEMS=="pci"
    DRIVERS=="ddbridge"
    (..)
    ATTRS{subsystem_device}=="0x0032"
    ATTRS{subsystem_vendor}=="0xdd01"
    ATTRS{vendor}=="0xdd01"

  looking at parent device '/devices/pci0000:00/0000:00:1b.3':
    KERNELS=="0000:00:1b.3"
    SUBSYSTEMS=="pci"
    DRIVERS=="pcieport"
    (..)

  looking at parent device '/devices/pci0000:00':
    KERNELS=="pci0000:00"
    SUBSYSTEMS==""
    (..)

Die Logik folgt der Baumstruktur des PCIe Bus
/devices/pci0000:00 -> Dein PCIe root node in der CPU
/devices/pci0000:00/0000:00:1b.3 -> Am ersten PCIe Bus auf Node 00 hängt ein Gerät 0000:00:1b.3 welches eine PCIe / PCIe bridge ist, sieht man am Treiber
/devices/pci0000:00/0000:00:1b.3/0000:04:00.0 -> Aha, Treiber ist ddbridge, das ist eine DVB Karte
/devices/pci0000:00/0000:00:1b.3/0000:04:00.0/dvb/dvb0.frontend0 -> Ein Subsystem der DVB Karte

Tja, und dann versucht man eine passende rule für udev zu erstellen, z.B. so in der Art (habs nicht probiert, weil ich es nicht brauche..)

cat > /etc/udev/rules.d/99_dvb_devs.rules << "EOF"

# my own fancy rule for dvb tuners
KERNEL=="dvb[0-9].frontend0", KERNELS=="0000:04:00.0", ATTRS{device}=="0x0006", ATTRS{vendor}=="0xdd01", NAME="dvb0/frontend0"
KERNEL=="dvb[0-9].frontend0", KERNELS=="0000:04:01.0", ATTRS{device}=="0x0006", ATTRS{vendor}=="0xdd01", NAME="dvb1/frontend0"

EOF

Die genaue Syntax und Möglichkeiten findest du hier:
https://reactivated.net/writing_udev_rules.html#syntax

Du könntest eine udev rule erstellen.

Für mich sah es so aus, als ob die Halteklammer am Ende, weit entfernt von der Plastik, ebenso eine Schmorstelle hat und als ob die Masse der DDR5 Platine an der vorderen Kante zwischen Einrast-Stelle und Connector sichtbar durch Temperatur verfärbt ist.

In dem Falle hätte die Halteklammer einen harten Kurzschluss verursacht und der Hersteller des Speichers hätte beim Layout gepfuscht.

Wie auch immer, ich hoffe du nimmst es sportlich und evtl. gibt es für das Vorgänger Board ja ne Lösung.

Wurde die Platte damals ohne Reserve Sektoren partitioniert?

PS: klebt auf dem Bild 20251226_124605.jpg an der metallischen Halteklammer des SO DIMM direkt neben dem Brandschaden ein angeschweißtes SMD-Bauteil?

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..

Die Frage wer und was zuerst starb sollte erkennbar sein. Der RAM hat das Board gekillt.
Die weggebrannten Pins schließen falschen Einbau wohl eher aus, zumindest richtige herum drin war er. Und wenn er nicht 100% weit genug gesteckt wäre, dann wäre nicht der Chip auf dem RAM weg gebrutzelt.

Die Frage nach dem warum mag interessant sein, aber korrekt ausgesucht war wohl alles.
Die Sache mit den 12V Steckern wird wohl auch nichts mit dem Problem zu tun haben.
Möglicherweise hat das NT überlebt, aber das müsste getestet werden.

Elektrostatische Aufladung oder mechanischer Stress (Biegung) der RAM Platine könnten Ursache gewesen sein.

Quote from Dr. Seltsam

Bei allen getesteten satip-Versionen (rofafor, Wirbel, Firefly) habe ich das Problem, dass beim Versuch, mittels des femon-Plugins (links/rechts-Tasten) auf einem verschlüsselten Kanal das satip-device zu wechseln, vdr mit über 100% CPU-Auslastung unbedienbar wird. Kannst Du mal bitte testen, ob das im Zusammenspiel mit einer Octopus auch auftritt?

@ my version: links/rechts device Wechsel bei verschlüsselt - kein Bild, aber bedienbar und keine hohe CPU last. Kanal Wechsel auf dem gleichem device zum nächsten verschlüsselten Ch geht