mgutt

Probiert neben AHCI auch mal RST: https://www.hardwareluxx.de/community/threads/die-sparsamsten-systeme-30w-idle.1007101/post-29015976

Ok und auf deinem Windows PC bekommst du mit ping plex.example.com deine öffentliche IP zurück? Hattest du die Plex App neu gestartet als du das Limit gesetzt hast? Bei mir ist der Bug übrigens auch im Browser präsent: Ich glaube das liegt an Cloudflare, weil dadurch kommen die Zugriffe ja von der IP von Cloudflare. Wobei es komisch ist, dass es bei Android keine Rolle spielt bzw Plex ja selbst erkennt, dass es eigentlich eine lokale Wiedergabe ist.

Die Modi werden aber gesetzt? Also mit cat geprüft?

Eigentlich ist die Standardeinstellung AJAX. Dh wenn du Nextcloud über den Browser öffnest, dann werden auch Background Jobs ausgeführt. Wenn du allerdings nur die Apps verwendest, dann passiert das nie. Daher wäre es besser einen Cronjob dafür zu erstellen. Entweder Nextcloud intern oder in den man nextcloud.example.com/cron.php von irgendwas aufrufen lässt.

Ist das Plex for Windows oder PMP? Hast du Plex öffentlich freigegeben? Weil der Bug ist nur präsent, wenn man eine Domain mit öffentlicher IP nutzt. Ich habe zum Test die IP der Domain gegen die lokale Server-IP ersetzt (per Windows hosts Datei) und kann damit den Bug umgehen.

Maybe through the docker settings. Isn't there an IPv6 custom network settings (enable advanced view)?

Und das Kommando ändert nichts daran? Weil das aktiviert ja ALPM auf den SATA Buchsen: echo med_power_with_dipm | tee /sys/class/scsi_host/host*/link_power_management_policy Das Kommando gibt den Status zurück: cat /sys/class/scsi_host/host*/link_power_management_policy Diese Modi gibt es alle, vielleicht hilft ja ein anderer?! echo max_performance | tee /sys/class/scsi_host/host*/link_power_management_policy echo medium_power | tee /sys/class/scsi_host/host*/link_power_management_policy echo med_power_with_dipm | tee /sys/class/scsi_host/host*/link_power_management_policy echo min_power | tee /sys/class/scsi_host/host*/link_power_management_policy Vor der letzten Einstellung wird allerdings gewarnt, weil die evtl zu Datenverlust führen kann: https://wiki.archlinux.org/title/Power_management#SATA_Active_Link_Power_Management

By choosing in the unraid network settings IPv4 only?!

Also wie gesagt hat Cloudflare das Problem auf dem TV gelöst, aber dafür habe ich jetzt noch einen anderen Bug in Plex gefunden: Begrenzt man beim Fernzugriff die Qualität über das Internet: Dann kann man bei der Plex for Windows App keine Qualität mehr einstellen und das Video wird auf 1080p transcodiert: Wenn ich dagegen die "Begrenzung der Stream-Bitrate übers Internet" auf "Original (Kein Limit)" stelle: Dann kann ich die Qualität einstellen (geht aber auch erst, wenn man die App neu startet): Das ist insofern unlogisch, weil Plex selbst erkannt hat, dass es sich um eine lokale Wiedergabe handelt: ohne Limit: Also in beiden Fällen ist es eine lokale Wiedergabe, aber das Fernzugriff-Limit greift trotzdem. Natürlich habe ich 192.168.0.0/16 als lokalen Adressbereich eingestellt: Der Bug ist übrigens nicht ind er Android App präsent. Da spielt er Direct Play 4K:

Ich meinte damit schon alle Pfade. Also appdata, docker, Transcoding-Ziel und die Quellen der Medien. Aber stimmt schon. 50% auf allen Kernen macht das bei mir auch nicht aus. Ich habe es gerade mit einem neuen Container getestet, da waren es von 0 auf 20% zusätzliche Last auf einem Kern, wenn man in den RAM transcodiert, dann sogar nur 7%. Wobei das jetzt aus htop ist. Das Dashboard zeigt ja meist eher das doppelte an. Also bei ihm dann vermutlich eher was in Richtung Transcoding, SDR Tonemapping oder Untertitel Burn-In. Wie gesagt. Einfach mal mit in htop schauen was für Prozesse da die Last verursachen.

I had this in the past while IPv6 was enabled and after I changed the IPv4 and/or IPv6 of a container. It worked only after if I fully stopped and restarted the docker service. So I think this has something to do with IPv6.

Plex läuft im Browser wie Grütze, wenn nicht transcodiert wird. Der Ton läuft, aber er verliert dann ständig Frames. Wobei es auch sein kann, dass der Ton total versetzt ist. Das hat irgendwas damit zu tun, dass bei einem Direct Stream das Video live an den Browser geht und der "verschluckt" dann die Frames. Beim Transcoding wird dagegen gebuffert. Habe ich auch gerade noch mal beides in Chrome getestet. Es hat schon seinen Grund warum wir immer wieder vorbeten eine CPU mit iGPU zu nehmen. Wenn du erst mal mit Untertiteln oder Tonemapping konfrontiert wirst, Videos mit höheren Bitraten hast oder simpel anderen Codecs als H264, hast du nur Ärger, wenn du keine GPU hast.

Man sieht in der Liste nicht zwangsläufig alle Ports, weil das von Einstellungen des Containers selbst abhängt. Da weiß dann unRAID nicht welche Ports nun wirklich genutzt werden. Ist aber zugegeben verwirrend für den Nutzer.

Das Dashboard zeigt nicht die reale CPU Last, sondern auch io/wait an. Führe "htop" im Terminal aus und du siehst, dass die Last a) geringer ist und b) vermutlich so hoch ist, weil du in Plex mit User Share Pfaden arbeitest, was sowieso eine hohe CPU Last die Folge hat. Aus dem Grund nutze ich Disk Pfade:

Du stoppst nicht das Array und hast auch nichts an den Shares verstellt? Sobald du etwas an den Shares veränderst, stoppt unRAID kurz den SMB Server und nichts ist ätzender in Linux als ein gemounteter SMB Server der offline geht. Ich habe es noch nicht verwendet, aber evtl hilft hier Autofs: https://wiki.archlinux.org/title/autofs#Samba Ich mache das aktuell mit Skripten, die kaputte Mounts entfernen und neu mounten. Wenn das dagegen bereits beim Verschieben / Kopieren von Daten passiert, kann ich das nicht verstehen. Weil das unterbricht ja keine SMB Verbindung. Du könntest übrigens mal probieren die Disk Shares zu aktivieren und nur mal den Cache Pool über SMB zu mounten. Hast du das Problem dann auch?

Eine HDD ist unterschiedlich schnell, je nachdem wo die Daten liegen. Daher hat man früher HDDs partitioniert und das Betriebssystem auf die erste Partition installiert. Damit war sichergestellt, dass das am Anfang, also im schnellsten Bereich der HDD liegt. Für die Defragmentierung war es dann noch sinnvoll was Platz zu lassen, damit die Daten optimal zusammengelegt werden konnten. Aber gerade im unRAID Array und 1G LAN Verbindungen ist Performance aber eh kein wirkliches Thema. Defragmentierung auch nicht. Daher kannst du die voll machen bis Ultimo. Wobei ich 50 bis 200GB als Min Free Space konfigurieren würde, einfach damit man noch etwas Luft hat, wenn Dateien aktualisiert werden. Später wurde ich das aber auch wie empfohlen dem Server überlassen. Das sind so Dinge über die man sich einfach keinen Kopf machen sollte.

Die IPv6 deiner myfritz.net Adresse verweist auf deine Fritz!Box. Damit kannst du kein Gerät hinter der Fritz!Box erreichen, sondern nur die Fritz!Box selbst. Das ist anders als bei IPv4, wo du zwar auch erstmal nur die Fritz!Box erreichst, aber entsprechend deiner Freigabe-Regeln, alles auf Port X an Port Y eines Clients weiterleiten kannst. Bei IPv6 ist dieses Weiterleiten von Ports einfach nicht vorgesehen. Jeder Client soll direkt über eine individuelle Adresse erreichbar sein (Verzicht auf NAT). Kann Minecraft überhaupt IPv6? Oder hast du die Verbindung über deine IPv4 von feste-ip.net probiert? Ist in der Fritz!Box der Port 25565 auf die IPv4 und Port 25565 vom unRAID Server freigegeben? Dein NPM lauscht aber nicht auf 25565 und "klaut" damit dem Minecraft Container seinen Port?

Was heißt das? Fehlermeldung?

Nur CEC2019 aktiviert. Steht auch da.

Ich habe das Board aber schon mit C8 in Ubruntu gemessen: https://www.hardwareluxx.de/community/threads/die-sparsamsten-systeme-30w-idle.1007101/post-28446459

Entweder Logs oder RAM voll oder Stick defekt.

Tatsächlich kann ich dir auch nicht sagen wo der Verbrauch landen würde. Was ich dir aber sagen kann, dass ich damals einiges einstellen musste um den Leerlauf auf 7W runter zu bringen: https://www.computerbase.de/forum/threads/renoir-und-b550-die-idle-kuenstler.1967755/post-24812476 Mit einer GTX 1660 Ti kam ich nicht unter 22W. Das ist mehr als die Karte normalerweise im Leerlauf braucht, also vermutlich wegen der höheren C-States. Leider gibt es kein B550 Board mit 8 SATA Buchsen bzw selbst kleine X570 Boards sind selten bzw die hat dann nur ASRock und die können irgendwie nicht stromsparend: https://www.computerbase.de/forum/threads/idle-verbrauch-asrock-x570m-b550m.1971069/

Kann er ebenfalls nicht, weil er Port 80 braucht, welcher von unRAID belegt ist. Aus dem Grund habe ich bei mir Unraid auf 5000 umgestellt. Hast du keine IP eingestellt? Weil im Screenshot sieht man ja nichts. 99% der Container erlauben keine Änderung ihrer Ports. Im Bridge Netzwerk wird die ja auch nicht geändert, sondern nur umgeleitet (NAT). Nutzt du VMs im br0 bzw wenn du keine festen br0 IPs den Containern gibst, kann das denke ich passieren. Bzw hast du wirklich IPs vergeben, die außerhalb der DHCP Range liegen?

Das hier passt irgendwie nicht zu C2 Weil der Core ist ja offensichtlich stark reduziert beim Verbrauch. Schon komisch, dass das Paket dann nicht fällt. Ja. Selbst Powertop braucht Rechenkraft. Daher ist ein höherer Intervall eher nachteilig. Mit dem Befehl bekommst du in der Regel auch verbindlichere Werte: watch -n3 "cpufreq-info | grep 'current CPU'" Sieht auch gut aus. In welcher USB Buchse steckt der Unraid Stick und welche LAN Buchse verwendest du? Beim C246N haben wir mal festgestellt, dass das auch einen Unterschied machen kann: https://forums.unraid.net/topic/109990-kein-spindown-nach-hardwareaustausch-mit-aktiviertem-powertop/page/2/?tab=comments#comment-1005004 Bitte boote mal mit einem Ubuntu Stick und vergleich da mal mit powertop. Misst du eigentlich auch den Verbrauch?

Und CEC2019? Die Platten stehen alle? Welche unRAID Version? Was gibt der ASPM Befehl zurück? Screenshots von powertop bitte