hawihoney

In Deinen Ausführungen sind diverse Unschärfen/Fehler enthalten. 1. Das ist so nicht korrekt. Unraids FS Unterstützung kommt von ReiserFS über XFS zu BTRFS und nun ZFS. Die Unterstützung von ReiserFS läuft aus. Im Array werden einzelne Platten mit XFS, BTRFS und ZFS unterstützt. Die Erfahrungen sind unterschiedlich. Ich habe vor einigen Jahren alle Arrays von ReiserFS zu XFS migriert und werde auch so schnell nicht mehr wechseln da rock-solid. BTRFS kommt mir aus verschiedenen Gründen nicht ins Haus und ZFS werde ich für zukünftige Pools im Auge behalten. Also nein, Unraid ist nicht standardmäßig auf ein einzelnes FS ausgelegt. Quote aus dem Unraid Manual. Siehe hier: https://docs.unraid.net/unraid-os/getting-started/quick-install-guide/#starting-the-array-and-formatting-your-devices 2. ZFS wird spätestens seit 6.12.x standardmäßig unterstützt. Es gibt noch einige Arbeiten in der Oberfläche um die Unterstützung rund zu machen. Diese werden für das nächste Release erwartet. Aber ZFS wird auf jeden Fall bereits jetzt standardmäßig im Array (Single Disk) und in Pools unterstützt. 3. Ich verstehe diese Aussage nicht. Welche Anpassungen? Welche Kompatibilitätsprüfungen? 4. ZFS läuft out-of-the-box spätestens seit 6.12.x unter Unraid. Weitere Tools sind nur für Randgebiete erforderlich. Man muss für die Unterstützung einer GPU keine zusätzlichen Plugins installieren - kann man aber. So ist es auch bei ZFS. Man muss keine zusätzlichen Tools installieren - kann man aber.

I know. I tried sabnzbd in 2023/Q1 but came back to NZBGet. Ressource (e.g. CPU) usage of sabnzbd was way above NZBGet. And the GUI - whow, what a difference between the clear interface of NZBGet compared to sabnzbd. sabnzbd looks to me like a prototyp v0.1. Just my personal opinion. Will try. Thanks for pointing this out.

@ich777 I do have problems with German Umlauts in the NZBGet Container. Filenames containing äöü, etc. are cut off in front of these characters. Sometimes these files become deleted - don't know why. In the NZBGet forum I found old threads about UTF-8 vs. UTF-16 and the NZBGet creator hugbug wrote that NZBGet has no problems. So my idea is, perhaps the "old" (5.7) unrar in this container has a problem. I'm using NZBGet since many, many years and I don't remember that I always had any problems with these characters in the past. Is it possible to update unrar in the NZBGet container? It would be a first step to eliminate any problems with unrar. If this doesn't help I need to dig into the preprocessing scripts of NZBGet. It's a long time ago that I wrote those ... Thanks in advance. P.S: If you are interested I can PM you a NZB file to show my problem.

Interessant. Hast Du eine Ahnung wohin sich das Teil installiert? So ohne /config/ und .../appdata/? Vielen Dank.

Is there a reason why numbers show different scalings depending on it's value? IMHO it's hard to follow with old eyes: My feature request: Use the same scaling on all numbers within GUI - including Dynamix File Manager. Alternatively make it an option in Display settings. Thanks for listening.

Ich habe ein dutzend MG08ACA16TE in der 18 TB Ausführung verbaut. Die unterscheiden sich von den restlichen Platten im System in keiner Weise. Im Array sind die genauso schnell oder langsam wie alle anderen.

Wenn es sich nur um den gemappten "data" Pfad handelt, dann hätte ich nur den Nextcloud Container gestoppt, den Inhalt des "data" Pfades auf die neue Platte kopiert (vorsichtshalber), den Host-Path für das "data" Mapping in den Container Einstellungen angepasst und anschließend den Container neu gestartet. Mehr hätte ich zunächst nicht gemacht. Und wenn dann alles ein paar Tage läuft, dann die Original "data" Quelle löschen. Und Backup von Nextcloud nicht vergessen anzupassen - sofern Du ein solches machst. Und wenn man Paranoid ist, ein Backup von der zugrundeliegenden Datenbank machen (mariaDB). Genau das ist das charmante am Docker System. Das Umziehen von Containern oder Pfaden ist total einfach. Warum in den Maintenance Mode gehen? Hast Du einen Grund dazu? Ich habe jahrelang jede Nacht den Nextcloud Container gestoppt, eine Sicherung gezogen und den Container wieder neu gestartet. Den Maintenance habe ich in den ganzen Jahren nur einmal benötigt - da war ein Update hängen geblieben.

Unsere PV von 2019 alleine ist nach 6 Jahren bezahlt. Aktueller Zwischenstand mit tagesaktueller Strompreisberücksichtigung (Stand gestern): Und was die Ressourcen angeht: PV zu ca. 90-95 % recyclebar, Batteriespeicher ca. 95% der Metalle, 50% des Lithiums. In 20 Jahren wird das wohl besser sein. Das ganze entwickelt sich gerade erst. Ich bin da sehr zuversichtlich. Das Öl, das Gas hingegen, ist zu 100 % weg. 0 % recyclebar. P.S.: Sehe gerade die Rundungsdifferenz im SQL-View. Lustig ...

Das kommt darauf an Gestern 26.10. war unser Batteriespeicher exakt ein Jahr alt und ich kann für unsere Investition/Verbrauch/Nutzung/Strompreis etc. genaue Auskünfte geben. PV und Speicher sind nach einem schwachen Sonnenjahr, aber hohen Strompreisen, nach etwas um die 9 Jahren amortisiert. Dabei hat aber die PV einen höheren Anteil als der Batteriespeicher. Unser Speicher-Hersteller garantiert nach Ablauf der Garantie (10 Jahre) noch 80 % Kapazität. Soll angeblich 20 Jahre halten. Die PV von Bekannten hält seit 25 Jahren. Ich gehe davon aus, dass sich auch der Batteriespeicher mehr als rentiert. Allerdings "rechnen" wir auch eine emotionale Komponente mit ein. Wir wollen auch etwas für Klima, Umwelt, etc. tun ... Und unter diesem Aspekt "lohnt" sich das alle Male. Für den, dem die Welt der Kinder, Enkel egal ist, für den mag es sich nicht lohnen ,,, Letztens in der Nachbarschaft (3 Kinder, 2 Enkel): Das sieht doch sch...e aus auf dem Dach. Das sieht doch jeder. Nur über meine Leiche bekommen wir PV aufs Dach.

Auf jeden Fall das komplette syslog. Üblicherweise lädt man bei Problemen die komplette, anonymisierte ZIP Datei mit in den Beitrag. Wer sich mit dem jeweiligen Problem beschäftigen möchte fischt sich dann das Passende raus.

Kurze Nebenbemerkung. Für eigene/custom Mounts wurde vor Kurzem /mnt/addons/ eingeführt: https://forums.unraid.net/topic/92462-unassigned-devices-managing-disk-drives-and-remote-shares-outside-of-the-unraid-array/?do=findComment&comment=1235803

Hatte ich ja geschrieben und den OP gebeten mal auf top zu gucken. Lustig finde ich aber die Aufteilung der Last. Die 6 Performance Cores (durch IO-wait?) am Anschlag und die 8 Effizienz Cores schlafen ... https://www.intel.de/content/www/de/de/products/sku/230493/intel-core-i513600k-processor-24m-cache-up-to-5-10-ghz/specifications.html

Mich stört die CPU Auslastung. Öffne vor dem nächsten Kopieren mal die Konsole und starte top. Guck mal ob das System nicht einfach nur wartet - sprich IO-wait. Das findest Du dann oben als "wa" Wert. 30 MB/s ist tatsächlich, selbst für das Unraid Array, über 50 % zu wenig. Das muss Hardware Gründe haben. Die vielen Vorteile des Arrays kommen halt mit dem Nachteil beim Schreiben. Nimm die Performance der langsamsten Platte und teile das durch ungefähr 3,5. Hier die Erläuterung: https://docs.unraid.net/unraid-os/manual/storage-management/#array-write-modes

In Kürze, da bedarf es m.M.n. keiner Übersetzung:

Wenn Plex hw anzeigt, dann wird die iGPU genutzt. Da gibt es nichts zu diskutieren. Kannst ja mal in die Plex Logs schauen was es erkannt hat. Warum ein Plugin etwas nicht anzeigt müsste man dort fragen.

Hast Du eine iGPU oder eine dGPU oder beides? Wenn nur iGPU dann ist Deine Aussage falsch. Mit hw bedeutet dann iGPU, ohne hw bedeutet Software AKA CPU.

Bist Du evtl. hiervon betroffen (Fritzbox?)? Wenn ja, hast Du diese Änderungen vorgenommen: https://docs.unraid.net/unraid-os/release-notes/6.12.4/#fix-for-macvlan-call-traces

Das ist eindeutig. Die Datenbank ist kaputt. Hast Du Backups? Hast Du automatische Backups in den Plex Einstellungen "Geplante Aufgaben" eingerichtet? Die gelben Warnungen sind irrelevant, Plex hat immer einen Mismatch zwischen den Feldern in der Datenbank und seinen Abfragen. Das ist schon lange so.

Nur so als Hinweis: https://de.wikipedia.org/wiki/Netiquette

Interessant. Ich sehe das nie. Ist immer sofort verbunden, grün und natürlich verschlüsselt über SWAG.

Das kann ich nicht bestätigen (SWAG, LSIO Plex Container). Plex wurde eben turnusmäßig wegen Backup neu gestartet. app.plex.tv aufgerufen. Alles grün. Sowohl in der Navigationsleiste als auch unter Fernzugang. Kann das ggfs. bei Euch nach einer neuen dynamischen IP auftreten? Oder weitere Komponenten zwischen Plex > Unraid > (Hardware Switch) > Router?

Ich ziehe h264 immer vor. 8 Mbit/s ist Originalqualität? Du hast 8 Mbit/s remote Streaming eingestellt. Du guckst im Browser? Oh je, da kann ich nicht mitreden und bei IPv6 bin ich ebenfalls raus. Viel Glück. Irgendwann muss mir mal jemand erklären wie der ganzen 1920x1040 Content zustande kommt.

Was ist denn /mnt/data/? Ist das der Name eines Pools?

Eigentlich nicht: https://support.plex.tv/articles/202526943-plex-free-vs-paid/ 1.) Welche Bandbreite hat das was Du da abspielen willst? 2.) Was hast Du in den Server-Einstellungen unter Fernzugriff eingestellt? Ist der Fernzugriff grün oder "relayed" 3.) Beim Abspielen über den Reverse Proxy - mach mal Screenshot vom Dashboard (Aktivität):

hmm, ich denke nicht. - Die Datei nextcloud.log liegt üblicherweise im Container unterhalb /data/. - /data/ ist bei Dir gemappt nach /mnt/user/Nextcloud/ - das haben die meisten im Array - /config/ ist bei Dir gemappt nach /mnt/user/appdata/nextcloud/ - das haben die meisten auf einem schnellen Pool Wenn Du nun in der PHP Konfiguration die Datei nextcloud.log mit /config/nextcloud.log ansprichst, dann wird sie statt wie vorgesehen unterhalb des /data/ Ordners unterhalb des /config/ Ordners beschrieben. Und genau das meinte ich mit "[...] einen Teil von Data verschiebst Du nach Config [...]". Eine solche Mischung würde ich nie machen und auch nie empfehlen. Traditionell ist der /config/ Part der "statische Programmteil inkl. Konfiguration" und der /data/ Part der "dynamische Programmteil" - halt Konfiguration vs. Daten. Eine Log Datei ist dynamischer Inhalt. Die hat in der Konfiguration nix zu suchen. Ich weiß, die meisten Container machen diese Trennung nicht. Das sieht man ja spätestens beim /tmp/. Wenn aber ein Container diese Trennung anbietet, wie Nextcloud, dann ist das weise und sollte nicht unterwandert werden. Deshalb trennt man dann die Log Datei ganz ab. Ich gehe selbst noch einen ganz anderen Weg, den muss man aber nicht gehen. Ich habe unterhalb /tmp/ für jeden Container einen Unterordner (z.B. /tmp/nextcloud/). Das ist in jeden Container als /tmp/ gemappt. Dort würde ich die Log in einen Unterordner legen. Dann ist sie ganz aus dem Spiel. Kann gefährlich sein, war es hier aber noch nie. Nur meine 2 Cent.