hawihoney

Vor ca. einem halben Jahr stand das mal im Changelog des Plex Media Servers (intelligenter Umgang beim Pfad-Wechsel). Ich habe aber meine alte Vorgehensweise beibehalten. Kostet nix. Bin halt Old-School. Da ich ausschließlich mit Disk-Shares arbeite, und zugleich oft bessere Versionen von Content einspiele, bedeutet das zwangsläufig eine Änderung der Disk wenn der neue Content größer ist. Ich habe diesen Vorgang also nahezu täglich.

Erst in Plex Mediathek Dateien einlesen, dann erst Papierkorb leeren. Sonst verliert man Informationen. Beim Einpflegen neuer Daten kostet es etwas mehr Aufmerksamkeit, aber beim Abspielen ist es unschlagbar.

Ich nehme an mit dem User Scripts Plugin. Da kann sudo tatsächlich weg. Verwirrt nur. Ok.

Nur so am Rande, weil es mich interessiert: Wieso sudo? Führst Du die rsync Befehle in einer Container Konsole aus oder in der Unraid Konsole? Und wenn in einer Container Konsole dann könnte hier ein mögliches Problem liegen.

In Deinem / sind 7,6 GB. In meinem 2 GB und mein Server wird wahrscheinlich ungleich fetter sein. Da musst Du suchen. Fang mit Deinen rsync Skripten an.

Ich hatte meinen Post gelöscht, da ich erst beim zweiten Blick gesehen hatte, dass Du damit einen Backup zurückspielst. Wie auch immer: Irgendetwas schreibt ins RAM. In nahezu 100% der Fälle ist das /mnt oder /tmp. Das können fehlkonfigurierte Container oder eben rsync sein. Da musst Du ansetzen. Schau genau in /mnt bzw. /tmp rein. Alles was z.B. unter /mnt nicht wie ein Disk/User/Pool/Share unter user oder disks oder remotes lautet ist falsch. Da es meist bei rsync passiert ist das wohl der Auslöser.

Die Vorgehensweise zwischen Array und Cache/Pool Devices unterscheidet sich. Für ein BTRFS RAID im Cache/Pool: -stop array, remove failing device in the pool -start array, let BTRFS work -stop array, add replacement device -start array, let btrfs work

Es gibt mehrere mit dieser Fehlermeldung - mich eingeschlossen. Bei mir reicht es ein Update der VM Konfiguration zu erzwingen bzw. sie mit einem Backup der Konfiguration im XML Modus zu füttern. Irgendwie verhaspelt sich das System manchmal und durch Ändern, ggfs. mit identischen Werten, klappt es dann. Insofern muss m.M.n. eine Änderung des RAMs nicht die Lösung zu sein. Einfach die Tatsache, dass etwas geändert wurde, könnte schon die Lösung gewesen sein.

Just a simple test: Change the Container Mapping from /mnt/user/downloads to the corresponding /mnt/diskx/downloads and look what happens. If the result is the same, you need to check within NZBGets path settings.

These are my settings for NZBGet. Perhaps this helps. Docker:

It's worth checking the Path settings within NZBGet. The main path is /config as default ...

Auf der SQLite Plex DB liegt kein Passwort.

Alles klar. Da liegen die von Nextcloud generierten previews, etc. Die meinen mit appdata einen Ordner innerhalb des data Ordners. Der data Ordner wurde beim Anlegen von Nextcloud erstellt. Dieser appdata Ordner hat nix mit Unraids appdata Ordner zu tun. Hatte schon einen Schreck bekommen

Den kenne ich nicht, habe ich noch nie gemacht. Muss mal nachlesen was der macht. Meine Devise: Don't touch a running system. Wenns läuft, würde ich die ignorieren. Das muss Nextcloud aufräumen. Das sind die Rechte dieser Datei. Ist bei mir ebenfalls. Da ich da nie dran war ignoriere ich das: root@bb4117473da0:/# ls -lisa /etc/my.cnf.d/custom.cnf 8389742 0 lrwxrwxrwx 1 root root 18 Nov 21 05:35 /etc/my.cnf.d/custom.cnf -> /config/custom.cnf

Ist aus der Ferne schwer zu sagen. In der MariaDB liegen nur die Verwaltungsdaten von Nextcloud. Die eigentlichen Daten als Dateien in Nextcloud. Du kannst den o.a. mysqldump im laufenden Betrieb von der Unraid Konsole ausführen. Wenn der klappt bist Du auf der sicheren Seite. Ich tippe eher auf Nextcloud. Das ist für mich der eigentliche Wackelkandidat von den beiden Containern. Hast Du den OCC Scan über den gesamten Nextcloud Content laufen lassen?

Unraid runterfahren, defekte Platte ersetzen (max. 8 TB), Unraid hochfahren. Die Anweisungen auf der Hauptseite aufmerksam lesen und befolgen. In der Dropdownliste die defekte Platte gegen die neue tauschen und den Rebuild starten. Während des Rebuilds kann weiter gearbeitet werden. Besser aber keine Massendaten gleichzeitig bewegen. Unbalance? Keine Ahnung wofür das in der Situation gut sein soll.

Nur ein Beispiel von vielen: Ein Amazon Fire-TV 4k Ultra Stick und ein 3-er Stecker ist unser ständiger Begleiter ins Ferienhaus - egal wo auf der Welt. In zwei Minuten am HDMI-Port des TVs angeschlossen und mit dem WLAN verbunden. Und schon steht dem Zugriff auf das gesamte Repertoire (auch TV) nichts im Wege. Ach und noch eins: Im Flieger mit Tablet und Noise-Canceling Kopfhörer: Plex ist auf dem Tablet installiert. Vorab wurde per Plex Download-Feature ausgesucht was man so alles gucken oder hören will (das wird dann bei Bedarf transkodiert). Und bei der nächsten Verbindung mit dem Netzwerk werden die "Gesehen/Gehört" Markierungen an den Server zu Hause übermittelt. Egal wo auf der Welt, egal auf welchem Klienten, ich gucke an der Stelle weiter, wo ich zuletzt unterbrochen habe.

Schon klar. Ich will nur vermeiden, dass die Leute meinen, Plex Inc. könnte die Datenbank, den Content oder was weiß ich einsehen. Natürlich können die die Vermittlung, die Nutzung von Clients (nicht den Inhalt), Metadaten, etc. aggregieren. Das bringt aber nicht wirklich was. Der neue Plex Scanner nutzt eine eigene Plex Datenbank für die Metadaten - die holen die Daten zwar von IMDB, TVDB, ... verwalten die aber jetzt selbst. Das merkt man an kleineren Unterschieden die in deren Forum schon Thema waren. Plex tritt ab diesem Jahr als online Lieferant auf. Auch diese Zugriffe können natürlich aggregiert werden. Plex erlaubt aber auch das "Speichern" von kommenden Filmen und Blurays. Deren Metadaten werden dann auch angefragt. Ach, ein klein wenig Vertrauen und gesunde Skepsis habe ich schon - hält mich aber nicht ab Es gibt einige Nickeligkeiten die mich teilweise auch richtig nerven. Das sind aber meist die diversen Klienten, nicht der Server. Roundabout sind die Möglichkeiten einfach nur geil.

Ah, jein. https://www.plex.tv/de/about/privacy-legal/ Der Proxy/Relay Part ist tatsächlich der Knackpunkt, dieser greift aber nur wenn keine direkte Erreichbarkeit von außen möglich ist. Das kann man in der GUI sofort erkennen und man erkennt es daran, dass auf 2 MBit/s gedrosselt wird. Bei direkter Erreichbarkeit werden nur Adressen ausgetauscht. Ist schon diverse Male im Audit gewesen. Hiermit teilst Du die Vermittlungsadresse mit (unter Netzwerk): Und jetzt noch ein wenig mit den Ports jonglieren. Ich halte das im Rahmen von dem, was man heute überhaupt als sicher betrachten kann, als relativ sicher. Plex kennt definitiv nicht den Inhalt Deiner Datenbank.

Wichtig ist zunächst ein gutes Backup zusätzlich zu Deinen bereits existierenden zu ziehen. Hier ein Teil eines meiner User Skripte die jede Nacht laufen. Ich habe diesen Teil der besseren Lesbarkeit halber schon ein wenig modifiziert. Du solltest das an Deine Gegebenheiten anpassen. Ich betrachte MariaDB und die darauf aufsetzenden Container - wie z.B. Nextcloud - als eine Einheit. Wie Du siehst ziehe ich zunächst einen Dump der MariaDB Nextcloud Datenbank und nach dem Stoppen der Container zusätzlich die Ordner 1:1. Achtung: Nextcloud kennt zwei Ordner - den config und den daten Ordner. Die hast Du beim Anlegen des Containers festgelegt. Den Dump kann man in MariaDB auf der Kommandozeile Bulk-Importieren. Ist wie bei SQLite, auch von diesen Datenbanken (z.B. Plex) ziehe ich die Ordner sowie zusätzlich einen Dump. Was heißt denn "funktioniert nicht wie er soll"? docker exec mariadb /usr/bin/mysqldump --user=root --password=******** nextcloud > "/mnt/disk1/Backup/MariaDB/dump/Nextcloud/dump.sql" docker stop nextcloud docker stop mariadb rsync -avPX --delete-during /mnt/pool_nvme/system/appdata/mariadb/ /mnt/disk1/Backup/MariaDB/config/ rsync -avPX --delete-during /mnt/pool_nvme/system/appdata/nextcloud/ /mnt/disk1/Backup/Nextcloud/config/ rsync -avPX --delete-during /mnt/pool_nvme/system/appdata/nextcloud.data/ /mnt/disk1/Backup/Nextcloud/data/ docker start mariadb docker start nextcloud

Du meinst die Ausgabe in einem Gesamtwert, oder? Ich bin vor Kurzem auch noch darauf reingefallen. Man schaut kurz in die GUI, sieht 99% Auslastung und wundert sich. Dabei wartet die CPU völlig entspannt auf Devices.

Davon würde mich der IO-Wait Anteil interessieren. Oben auf dem htop des Post-Read ist die echte CPU Belastung ca. 40% - alles Weitere ist warten auf die Platten. Die CPU Last müsste beim Post-Read leicht höher sein als beim eigentlichem Clear. Ist bei Windows IO-Wait ebenfalls Bestandteil der CPU Last? Meines Wissens nicht.

Die defekte Platte wird in Unraids Web-Oberfläche angezeigt.

Mach mal einen Screenshot von der Main Seite. Ich vermute Du machst etwas falsch. Nach dem Zuordnen der Platten, und dem Starten des Arrays, werden die Platten zunächst komplett gelöscht/geleert und dann erst formatiert.

Preclear arbeitet mit mehreren Stufen - Pre-Read, Nullen, Post-Read. Pre- und Pro- kann man abwählen und sind nur für das Kitzeln der SMART Werte von Interesse. Der Vergleich mit anderen Werkzeugen hinkt ein wenig. Die Frage ist wofür man cleart, für das Löschen von sensiblen Informationen oder das Vorbereiten der Platte für das Array. Geht es um das Vorbereiten der Platte für das Array, dann ist ein wenig Paranoia angebracht. Bleibt nur ein Bit beim Clearen stehen dann ist Datenverlust nicht mehr zu vermeiden. Andere Werkzeuge sind im Grunde für das Löschen von sensiblen Informationen gebaut. Da stört ein Bit, welches stehen bleibt, überhaupt nicht.