Recent Posts

31
SW: mld-image-netinstall-x86-64 (250604).iso

Die Installation ist weiterhin ok.
Rufe ich im OSD  oder im WebIf das Menü "Web" bzw. "Web durchsuchen" auf und wähle als Sender das "ZDF" aus, erscheint ein schwarzer Bildschirm auf dem TV. Nach ein paar Sekunden erscheint wieder der zuletzt gewählte TV-Sender.
32
Claus, du bist der Allerbeste! Ich danke dir. Leider bin ich gerade beruflich unterwegs und komme erst am Wochenende heim. Kann es aber kaum erwarten.  ;D
33
Ich habe mich jetzt mal um Dein PowerCap Problem gekümmert. in 15 Minuten gibt es ein Kernel Update. Damit sollte die Schnittstelle verfügbar sein.
34
SW: mld-image-netinstall-x86-64 (250601).iso

Der Ton Ausgang wird in den "Einstellungen->Ton" wieder im Modus "auto" automatisch erkannt.
Ist wieder ok.
35
Vielen Dank für die Erklärung, das leuchtet natürlich ein.

Ich bin mir noch nicht sicher, ob ich mergerfs aufgeben will. Es gibt ja nun mehrere Gründe, warum man es nutzen sollte. Es hatte ja für meinen Anwendungsfall auch ein paar nette positive Eigenschaften. Ich sehe zwei Möglichkeiten, wie das noch was werden könnte. Ich spiele mal etwas mit den Mount-Optionen, scheint ja ganz gut dokumentiert zu sein. Unklar, ob dabei was rum kommt, das habt ihr ja sicherlich auch schon getan. Die zweite Möglichkeit wäre, das Biest aus dem Atom frei zu lassen. 8) Dazu brauche ich den Intel-RAPL-Treiber. Der Wyse läuft, dank Dell, derzeit nur auf 1/4 seiner (CPU-) Leistung. Die CPU kann 1920 MHz, derzeit auf 480 MHz begrenzt. Es könnte sein, dass das ausreichend ist. Thermisch sollte das nicht viel ausmachen. So wie mergerfs arbeitet, sind die höheren Taktfrequenzen immer nur sehr kurz nötig.
36
Leider produziert Mergerfs auf schwachen Systemen (oder nur bestimmten Systemen) wie z.B. dem RPI2 eine recht hohe Systemlast. Auf Intel Systemen (auch schwachen) konnte so etwas bisher nicht beobachtet werden.
Grundsätzlich is Mergerfs nicht sonderlich performant, was da dran liegt, dass es ein Userspace Filesystem ist und die dafür verwendete Schnittstelle des Kernels halt langsam ist. Warum das auf manchen Systemen zu echten Problemen führt, auf anderen (ähnlich schwachen) Systemen aber nicht, weiß ich nicht.

Beim nfs wird pauschal immer Mergerfs verwendet, weil das der einzige Weg ist den ich finden konnte, um sicher zu stellen, dass es auch bei verzögerten Mount (oder aussetzern) keine Probleme gibt. Mergerfs ist halt mega robust :)
Wenn Du sicher bist, dass Deine NAS immer verfügbar ist, und das Mounten sofort klappt, kannst Du ja mal testen, ob es hilft, wenn Du den NFS Mount (hard mount) direkt nach /data machst, und auf alle anderen Spielerein verzichtest. Ich hatte zuvor leider nicht mehr an den Mergerfs Trick gedacht, und auch nicht da dran, dass Mergerfs auf einem Intel System Performance Probleme machen kann. Ansonsten hätte ich das schon früher vorgeschlagen.
Ob es wirklich ein hard Mount sein muss, oder auch soft mount oder die Dritte variante am besten passt (hab grad vergessen wie die heißt), musst Du ausprobieren. Beim hard Mount wird der Boot Vorgang unterbrochen, biss der Mount erfolgt ist. Bei soft passiert das im Hintergrund, egal wie lange es dauert.
37
Gegenprobe OHNE mergerfs. Zwei HD Aufnahmen (ÖR, 720p) gleichzeitig und eine davon per Timeshift gucken, funktioniert fehlerfrei. Load ist kurz vor 4 und alle CPU-Kerne über 80%. Das alles bei nur 480 MHz, da die TDP von Dell (absichtlich oder fälschlicherweise?) auf nur 2 Watt festgelegt wurde. Vorher mit mergerfs und einer Aufnahme, ohne Timeshift-Wiedergabe, gab es bei einer Load von 2,5 und einer CPU-Auslastung von 50-60% über alle Kerne schon massiv Fehler. Und ich rede da von rund 1.000 Fehler pro Minute. Da geht alles kaputt.

Ohne mergerfs werden die Daten kontinuierlich auf den Stick geschrieben. Mit mergerfs in Intervallen, mit entsprechend hohen Datenraten, gefolgt von langen Pausen. Ich weiß nicht, ob das per Design so sein soll, oder ob mergerfs ein Problem hat, bzw ungünstig parametriert ist.

Ist echt schade, weil mergerfs hier echt Vorteile hatte. Kein extra Ordner "Server" und Verschieben während Wiedergabe möglich.

Btw, warum wird mergerfs grundsätzlich verwendet, wenn man NFS-Mounts einbindet? Auch wenn es der einzige Mount für /data ist? Eigentlich macht es doch nur dann Sinn, wenn man mehrere Dateisysteme auf den gleichen Mountpoint einhängen möchte. Oder übersehe ich was?
38
Allgemein [ General ] / Netzwerkchip RTL8125 wird nicht unterstützt
« Last post by sulmfish on June 01, 2025, 13:48:18 »
Ein Zitat aus der aktuellen c't:
"Beim NUC14MNK stolperte Ubuntu über den 2,5-Gbit/s-Ethernet-Chip RTL8125D Rev. B von Realtek. Das ist ein bekanntes und mit dem Kernel 6.14 von Ubuntu 25.04 gelöstes Problem."
Vielleicht hilft das ja irgendwie weiter.

Udo
39
Ja, das ist schon cool. Eigentlich funktioniert das Verschieben jetzt perfekt.

Um das Herunterfahren habe ich mich aber noch nicht gekümmert. Unklar, ob ich das überhaupt brauche. Denn ich habe bei Aufnahmen der ÖR in HD die gleichen Probleme, wie beim direkten Schreiben auf den Server. Der Stick ist USB3 und, getestet, sehr schnell. Die Aufnahmen sind nicht zu gebrauchen, völlig zerstört. Es liegt also nicht am Server. Hat mich eh gewundert. Der ist zwar nicht superschnell, schafft aber gut 35 MB/s schreibend. Offensichtlich ist der Wyse 3040 schlicht zu langsam. Und das verstehe ich nicht. Der VDR lief früher auch auf nem Celeron mit 266 MHz, der nur einen Kern hatte. Und da hat er auch die TS Daten (damals noch PES) auf die Platte (die ebenfalls langsamer war) geschaufelt. Und so viel mehr an Daten ist das doch nicht geworden?

EDIT: Und ein Raspberry PI 2 schafft es doch auch?
40
Der Trick dabei ist, dass eine geöffnete Datei nicht auf den Pfad zeigt, sondern auf die Datei ID. Solange eine Datei auf dem selben Dateisystem verschoben wird, ändert sich diese nicht, und ein Verschieben stört nicht. Mergerfs erzeugt, je nach Einstellung, eigene IDs die sich beim Verschieben der Datei im Hintergrund wohl auch nicht ändert :)