hawihoney

Die Historie würde ich getrennt auf Seite legen. Das ist hier beschrieben: https://support.plex.tv/articles/201154527-move-viewstate-ratings-from-one-install-to-another/ Die Settings, falls Du mal nachschauen willst, ebenso: Dann natürlich die Datenbank. Die liegt unter plugins/databases. Zusätzlich zu den Datenbank Dateien würde ich noch einen Dump der Datenbank auf Seite legen. Doppelt gemoppelt hält besser: https://support.plex.tv/articles/repair-a-corrupted-database/ Das alles würde ich mir getrennt von einem Voll-Backup als Plan-B auf Seite legen. Solange Du die von Plex empfohlene Ordner- und Dateistruktur für die Medien eingehalten hast ist der Prefix (/Medienserver/ vs. /mnt/user/) egal. Plex remappt das dann. Die Metadaten? Da bin ich mir hingegen nicht sicher. Da sind sehr viele Links drin. Ob das so einfach von Qnap zu Unraid kopiert werden kann weiß ich nicht. Da bei mir jeder du, df auf den Plex Metadaten Ordner abstürzt gehe ich nicht mehr daran und hoffe das Beste. Der neue Server muß natürlich bekannt gegeben werden. Plex nennt das "reclaim". Aber auch das musste ich noch nicht machen. Da muss jemand anderes reingrätschen. Die separat gesicherte Abspielstatistik und die Datenbank sind jedenfalls sehr wichtig falls Du komplett neu anfangen musst. Der kritische Teil wären manuelle Einstellungen. Das wird ohne die vorhandene Datenbank schwierig. Bei uns sind alle Bilder verschlagwortet, alle Serien als "Ended, Continuing, ..." Sammlungen markiert und Musikinterpreten und deren Konzerte und Filme Bibliotheks-übergreifend ebenfalls (gibt tolle Übersichtsseiten der Interpreten). Das hat unfassbar viel Zeit gekostet. Das will man nicht verlieren. Die Metadaten kann man wieder beschaffen. Die Abspielstatistiken und manuellen Eingriffe nicht.

"Moving ... to lost+found" ist ein Indikator für korrigierte Fehler. Guck Mal auf die Disk ob es entsprechende Ordner/Dateien gibt.

Zeig mal die Einstellungen des Device (blaues Zahnrad).

Einfach nur rsync und cp. Ich stecke eine meiner rotierenden Backup Platten an und Unassigned Devices mounted and startet Skript selbständig. Skripte kann man in Unassigned Devices Individuell für jedes Device hinterlegen. Anschließend wird automatisch unmounted. Ich gucke nach ungefähr zwei Stunden und ziehe die Platte ab. Die Platten sind in NTFS formatiert.

Eine Alternative zum verzögerten Start des Containers: Sind denn diese Remote Shares permanent vorhanden oder werden diese später gemountet? Sind diese in Unassigned Devices erfasst? Und läuft der Backup Docker immer? Ich frage, da man den Docker Start/Stop sowie den Mount/Unmount, je nach Konfiguration, auch automatisiert über ein User Skript laufen lassen könnte. Beispiel: In Unassigned Devices hinterlegte Remote Mounts kann man ab 6.10 wunderbar automatisiert starten und stoppen: Einen Docker Container zu starten/stoppen ist noch einfacher: docker start <containername> ... docker stop <containername> Das alles in ein User Script zu packen wäre ziemlich einfach: #!/bin/bash #backgroundOnly=true #clearLog=true #Starte /usr/local/sbin/rc.unassigned mount <was_auch_immer> docker start <containername> Bei Bedarf könnte man auch noch eine Pause dazwischen schieben. Und das Runterfahren: #!/bin/bash #backgroundOnly=true #clearLog=true #Stoppe docker stop <containername> /usr/local/sbin/rc.unassigned umount <was_auch_immer> Weder nutze ich das Backupprogramm noch kenne ich es. Daher weiß ich nicht ob man es bei Bedarf aktiviert oder permanent laufen lässt. Letzterer Fall würde mich allerdings abschrecken, denn damit wäre auch der dafür permanent gemountete Remote Share ein mögliches Angriffsziel von Viren, etc.

Hatte ich überlesen. 1.) 2x XFS formatierter Single-Disk Pool für Docker, VMs und Nextclouds Datenverzeichnis (die Daten die in Nextcloud stecken sind sogenannte Externe Speicher und liegen auf dem Array). Die beiden Pools halte ich mit einem Haufen User Skripte regelmäßig synchron. Es gibt Docker Container/VMs die werden nur einmal pro Woche synchronisiert, andere täglich. Vor dem Sichern werden z.B. die Docker Container in den User Skripten heruntergefahren und anschließend wieder gestartet. Nach dem Synchronisieren der beiden Pools erfolgt ein Backup des Backup-Pools ins Array. 2.) Unassigned Devices sind hier nur 3 Backup-Platten die regelmäßig und rotierend angesteckt, befüllt und wieder abgesteckt werden. Weiterhin eine SSD für NZBGet. Für NZBGet will ich nicht durchgängig einen Spinner laufen lassen. Bei angeblich 600 TB (o.ä.) Laufzeit mache ich mir über die Abnutzung auch keine Gedanken.

Die Parity Platten sind nur für das Array zuständig (Ausfallsicherheit). Um Unassigned Devices musst Du Dich, wenn notwendig, selbst kümmern. Pools können als RAID angelegt werden. Derzeit mit Bordmitteln nur mit dem BTRFS Dateisystem. Noch nicht komplett integriert wäre ZFS, das erfordert aber die Installation von Plugins und ein wenig Handarbeit. Letzteres soll wohl im nächsten Release in Unraid komplett integriert sein. Als Randnotiz: Alle o.g. RAID Systeme außer das Unraid Array erfordern, dass alle Platten immer aktiv bleiben.

Bevor ein anderer Klugscheißer kommt mach ich das lieber 😉 Das Buffering passiert auch beim lokalen Lesen quasi under-the-hood. In nahezu jeder Programmiersprache kann man beim READ einen Buffer und optional eine Lesegröße angeben. Lässt man sie weg dann wird eine Standardgröße verwendet. Und ja, beim Streaming wird oftmals so eine Art Continous Read durchgeführt bei der die Quelle (der Stream, daher der Name) gleichzeitig zum Lesen befüllt wird (z.B. gestreamtes Radio oder der Stream von der Überwachungskamera). Du bist ein sehr guter Programmierer, deshalb weiß ich das Du das weißt. Ich will nur die Angriffsfläche minimieren... Jetzt hat es sich aber ausgestreamt 😁

Ich werde wahrscheinlich älter sein (seit 5 Jahren "Privatier") habe aber den Großteil meines Erwerbslebens Client/Server Umgebungen aufgebaut, geschult und in ihnen gearbeitet. Wahrscheinlich bin ich zu lange raus und schaffe es nicht mehr aufzuklären oder zu begeistern. Vielleicht auch nur zu müde ... Streaming ist ein fester Begriff (zu finden unter Wikipedia). Der Versuch das hier gleichsetzen zu wollen mit z.B. SMB erschließt sich mir einfach nicht mehr. Wenn es für Dich passt ist ja alles ok. Wenn Dir nichts fehlt um so mehr. Ich hingegen blicke schon lange nicht mehr zurück zu meinen Zeiten mit Mediaportal, Kodi, Dapyx und Konsorten. Der Grund dafür ist aber nicht nur die in meinen Augen völlig überladene Oberfläche von z.B. Kodi - was zu einem großen Teil daran liegt, dass die Software Client und Server in einem einzigen Programm spielen muss Ich bin hier raus. Werde mal beim WDR anrufen warum die mir keinen SMB Zugang zum Radioprogramm anbieten. Die Protokolle machen doch fast das Gleiche <SCNR>

Nur der Vollständigkeit halber. Hier die Doku von Plex zu dem Thema. Es gibt noch viel mehr Varianten als wir aufgeführt haben (Umwandlung inkompatibler Container Formate on the fly, etc): https://support.plex.tv/articles/200250387-streaming-media-direct-play-and-direct-stream/ Jetzt muss aber gut sein

Wenn Du auf Dein NAS via SMB o.ä. zugreifst, dann öffnet das Programm (z.B. Kodi) eine Datei auf direktem Wege und liest aus dieser dateibasiert. Beim Streaming (z.B. Plex) öffnet der Server die Datei und stellt Dir den Inhalt via eines Streaming Protokolls zur Verfügung, Das kann HTTP, RTP, RTSP, WebRTC, etc. etc. sein. Diese können auch geroutet werden. Um bei Plex zu bleiben: Die bieten z.B. auch einen Relay-Server. Wenn Du keine direkte Verbindung zwischen Server und Klient leisten kannst, dann vermitteln die über ihren Relay (max 2 MBit/s) den Content zwischen Server und Klient. Kurz gesagt: Bei Streaming handelt es sich um eine Klient/Server Umgebung. Beim lokalen Abspielen hingegen ist kein Server im klassischen Sinne involviert. Gut der SMB-Server ist auch ein Server. Aber der stellt Dir nur die Datei zur Verfügung. Mehr macht der nicht. Bei lokaler Nutzung kümmert sich also das Programm selbst um alles (Verwaltung/Abspielen). Beim Streaming kümmert sich der Server um die Verwaltung und die Aufbereitung für den Klienten und die Klienten nur noch um die Präsentation. Du musst Dir das vorstellen wie bei einer Datenbank. Du kannst mit Deinem Programm eine Datenbank öffnen und mit Deinem Programm selbst daran rumfummeln. Oder Du installierst einen Datenbank-Server und übermittelst dem Anweisungen - der kümmert sich dann um alles. Also mir war das klar. Wurde da etwas falsch vermittelt? Die a.) Bandbreite des Anschlusses in Deinem Krankenhauszimmer, b.) der VPN Anbieter, c.) Dein Upstream und d.) die Bandbreite des Content passten dann halt zusammen. Wenn nur eines nicht passt --> Ruckeln. Die oben im Bild gezeigte Bandbreite kann weder mein Upstream (40 Mbit/s) noch (beim letzten Aufenthalt bei Orthoparc) der Anschluss des Krankenhauses. Deshalb ist in meinem Gepäck (Krankenhaus, Urlaub) immer ein Fire-TV Stick mit installiertem Plex. Und wenn ich dann in z.B. Ägypten mit 1 MBit/s bedient werde, dann gucke ich mir trotzdem den im Screenshot gezeigten Content an. Aber dafür wird dann Transcoding benötigt, darüber wollten wir ja nicht reden. *** Nachtrag*** Es wurde nicht danach gefragt, aber hier noch weitere Vorteile einer Klient/Server Umgebung: Mehr oder weniger identisches Aussehen über alle Klienten und Plattformen hinweg. Zusätzlich eine zentrale Abspiel-History über alle Klienten hinweg (Auszug aus Plex Liste):

Bitte lies noch mal den Quote auf den ich antwortete. Da ging es nicht darum was er will. Da ging es darum, dass er den Hype über das Transcoding nicht versteht. Und das habe ich versucht zu erklären. Natürlich kann man seinen Content a.) lokal abspielen oder b.) lokal auf Geräte kopieren, die Geräte mitnehmen und dann an entfernter Lokation abspielen. Dafür benötigt man kein Plex und auch kein Transcoding. Ist man aber an einer entfernten Lokation und will seine Geräte/Content nicht mitnehmen, dann kommt Streaming ins Spiel (z.B. Plex). Je nach Verbindung zum Gerät bzw. den Fähigkeiten des Gerätes an entfernter Lokation kommt dann zusätzlich Transcoding ins Spiel. Und im Übrigen hatte ich in meiner oben stehenden Antwort auch den Fall aufgeführt, dass der Content die jeweilige lokale Geräteklasse ebenfalls überfordern kann. Auch dann kommt Transcoding ins Spiel. Bei uns ist das teilweise schon so. Nämlich dann, wenn unser LG Smart-TV in die Nähe von 100 MBit/s über das Ethernet-Kabel kommt. Dann setze ich am TV in Plex den Transcoding-Wert etwas herunter und der Server liefert etwas weniger für die reduzierte Bandbreite. Bleibt nur noch die Frage über das "Warum". Warum dann nicht gleich kleinere Versionen des gleichen Content ablegen? Tja, der nächste TV kommt dann vielleicht damit klar ...

Got that. So my VMs only autostart after an Unraid upgrade. That's what I know now. My servers only boot for Unraid updates - they run 365/24. Alle Disk Additions or Replacements can be done with a stopped array without shutdown or reboot. With the "Autostart Array=no" (this is IMHO more important) the manual array start after Disk Replacements will trigger VM autostart only once and then never again until next boot. That's what I learned and that's what I have to live with ...

Es wird nicht die Datei auf die Parity geschrieben sondern es werden kalkulierte Werte aller betroffenen Disks geschrieben. Das genaue Standard-Verfahren (es gibt mehrere) ist hier beschrieben: https://wiki.unraid.net/Parity#Performance Der entscheidende Teil ist dieser. Meiner persönlichen Meinung nach gilt das nur für Single-Parity. Meiner Meinung nach müsste es bei Dual-Parity noch weitere Kalkulationen und Schreibprozesse geben, denn Parity Q berechnet sich aus Parity P. Aber was weiß ich schon

Ich würde ihn einfach als mahnendes Beispiel drin lassen. Da gab es doch so eine nette Funktion in den Forums-Einstellungen. Da kann man doch sicher ... Muss ich mal suchen. Wird Zeit.

Ändert aber nix daran, dass dieses Verhalten von Unraid einfach nur falsch wäre. Ggfs. starten Docker Container oder VMs nicht. Schlimmer noch wäre, wenn dadurch noch andere Nebenwirkungen auftreten würden, die sich dann erst später manifestieren. Das würde es für einen Einsatz im professionellen Einsatz einfach diskreditieren. Hier fehlt definitiv eine rote Flagge und/oder eine Notification. Muss man mal auf 6.10.x testen ...

OMG, das ist aber so was von falsch. Ohne irgendeinen Hinweis in der GUI (Auto)startete das System ohne den betreffenden Pool und nix weiter? Keine rote Warnung? Kein nix? Ich halte das für einen Fehler.

Ich denke Du hast den Unterschied zwischen lokalem Abspielen und Streaming nicht verstanden. Es gibt diverse Gründe für Transcoding: 1.) So gut wie kein SMART-TV kann Gigabit. 4K Content hat heute schon mehr --> Transcoding. 2.) Du bist im Urlaub/Hotel/Ferienhaus mit Deinem Fire-TV Stick und lausigem WLAN -> Transcoding. 3.) Du sitzt mit dem Tablet im Flieger, willst aber die nächsten Folgen Deiner Lieblings-Serie weiter gucken -> Offline Transcoding (damit Du auch alle mitnehmen kannst und Deine Abspielstatistik aktualisiert wird). 4.) Mehrere Freunde und Familienmitglieder gucken Deinen Content, jeder hat seine eigene Bandbreite -> Transcoding. etc. etc.

That's what I described and said: Autostart Array=off, boot, start Array manually --> Autostart VM works. Now stop Array, start Array, Autostart VM does not work --> that was my problem and the reason for this bug report. Simply confusing, not documented on VM page and I still don't see a reason for that. Autostart means Autostart. Don't change that. Just my two cents.

And you think that this logic avarage users like me will understand? There's an option "Autostart VM" that only works if another option "Autostart Array" is set. But only if it is a first start of the array after boot, not on a second or later start of the array. Please take a step back and look at this from a distance. I already gave up and closed because I don't see that anybody understands that this option "Autostart VM" will be source of confusion in the future. It will NOT autostart VMs always and it works different than other autostart options (e.g. Autostart Docker Container). I'm not here to change the logic, I was here to make it more transparent. Let's stop here. I already closed.

Changed Status to Closed

So Unraid works different in your environment than in mine. Trust me, I'm working long enough with Unraid to know what I do and what settings are in place since years (I guess). The machine was running since monday (upgrade from 6.10.2 to 6.10.3). "Autostart Array" was off as always. Today I had to replace a disk in the array. I manually stopped all running VMs, manually stopped all running Docker Containers, stopped the array, replaced the disk, started the array to rebuild the replacement disk and the VMs, marked with "Autostart", did not start. That's all. In the meantime I've set "Autostart Array" to on, so that my VMs honor the "Autostart VM" setting in the future. I'm not satisfied but I will close that bug. Seems that it is intendent behaviour.

So "Autostart VM" will only work if "Autostart Array" is enabled during a boot process. But "Autostart VM" will not work if "Autostart Array" is disabled, the machine is already booted and the Array is started afterwards. So the "Autostart" options on the "VM tab" are bound to the "Autostart Array" AND the VM - with the "Autostart Array" being the main factor. This differs from the "Autostart" option on the "Docker tab" that does not care about "Autostart Array" at all. Got it, very confusing, but got it. IMHO, this should be mentioned on the "VM page". Some hours were gone without running VMs when I finally found out that my VMs with Autostart were not started. After that I scanned thru all logs this morning because I thought the VMs had errors during start. If an option suggests an Autostart it should not be bound to a different option behind the scene. Consider what I did: I stopped the array (no shutdown, no reboot, simply stop) to replace a disk. After that I started the array again and my VMs did not start. Guess nobody would expect that in this situation.

What does Autostart on VM page do then? Perhaps I don't understand your answer: 1,) Autostart on VM page does not Autostart VMs. Why is this option available? 2.) Autostart on VM page does not Autostart VMs on Array Start, but does work .... (when?) Whatever it is: "Autostart" on two different pages (Docker, VM) has two different meanings then. IMHO this is a bad GUI descision. *** EDIT *** I'm talking about these two settings: How to reproduce: - On Settings > Disk Settings > Enable auto start --> Off - On Docker > [Container of your choice] > Autostart --> On] - On VM > [VM of your choice] > Autostart --> On - Stop a running Array (no reboot, no shutdown, simply stop array) - Start array --> Docker Containers with Autostart=On will start --> VMs with Autostart=On will NOT start