hawihoney

Macht MKVToolNix schon. Das ist die Batch-Queue. Wie ich jetzt feststelle, willst Du das aber vom Lesen der Input-Dateien aus einem vorgegebenen Ordner, das Auswählen der Streams aus den einzelnen Dateien bis hin zum Verarbeiten aller gefundenen Dateien automatisiert durchführen. Das ginge auch mit den MakeMKV und MKVToolNix Containern sowie mit FFMPEG - aber nur auf der Kommandozeile. Das habe ich schon oft gemacht, aber dazu bedarf es der Bereitschaft sich mit der Materie zu beschäftigen und Programmierkenntnissen für kleine Skripte.

Das Ergebnis wäre ein Remux. Ich nutze dazu den MakeMKV Container für ISOs und den MKVToolNix Container für MKV/AVI/... Dateien. Bei MKVToolNix kann man die Jobs in eine Batch-Queue einsortieren, bei MakeMKV geht das nur einzeln (es gibt für MakeMKV ein Third-Party Tool zum Erstellen einer Batch-Queue, aber das nutze ich nicht). MakeMKV - man kann eine Selection-Rule hinterlegen damit alles passend vorbelegt ist. Mit diesen Rules muss man nix mehr auswählen und nur noch starten. Z.B.: Selection Rule: -sel:all,+sel:(ger|nolang|single),-sel:(havemulti|core),+sel:mvcvideo,-sel:special,=100:all,-10:favlang,+sel:subtitle&(ger) Rename rule: {NAME1}{-:CMNT1}{-:DT}{title:+DFLT}{_t:T2} MKVToolNix:

Can you please explain the search feature to me? Whatever I do - I never get a result. It does not work for shares, folders or even within a folder containing a file with the search pattern. Thanks.

Da Du eine existierende Disk platt machen und auf seine Gesundheit checken willst, die später aber nicht mehr ins Array eingebunden werden soll. Hier wäre meine Vorgehensweise: Erase Disk, kein Pre-Read, kein Post-Read, kein Verify-Signatur, kein sonstiges Verify. Einfach mit Nullen füllen lassen ohne das Schreiben der Unraid Signatur (Erase). Mit Unraid Signatur wäre es Clear Disk und dann könnte man die Disk direkt ins Array einsetzen. Letzteres willst Du aber nicht. Jedes Byte, jeder Sektor wird bei Erase beschrieben. Sollten dabei Fehler auftreten, dann wird das a.) automatisch durch Reserve-Sektoren ausgeglichen oder b.) bei schwereren Problemen zu Deiner Kenntnis gebracht. Alles weitergehende ist Geschmacksache, ich bin bei gefühlt über 200 Festplatten mit Unraid aber immer nur den einfachen Weg gegangen und das war immer völlig ausreichend.

Hm, da bin ich mir nicht sicher. Ich habe das noch nie gemacht, aber es klingt als würde Unraid einen exakt beschriebenen Zustand des Arrays erwarten - eine Data-Disk disabled, not missing, new larger disk. Erst dann wird Parity Swap erkannt:

Exakt.

Grundsätzlich: Der Unraid "Cache" ist ein Schreib-Cache und kein Lese-Cache. Der Lese-Cache ist wie bei jedem Linux das RAM welches kürzlich bewegte Daten zwischenspeichert. Unabhängig davon kannst Du Dir natürlich etwas selbst stricken und Dateien manuell vom Array auf den Cache kopieren und dann dort abspielen.

Bingo. Also war Dein manueller Eingriff das Problem und das bestätigt meinen Verdacht. Du kannst Root Ordner (User Shares) auf ZFS-Pools nicht mit rmdir (mc) löschen das sie mit create dataset und nicht mit mkdir erzeugt wurden. Du sprichst fehlende User-Freundlichkeit an. Die Verwendung von MC gehört für mich nicht zur User-Freundlichkeit. Die vorgesehenen Verwendung des movers ohne manuelles Rumfummeln unter der Haube ist hingegen User-Freundlich. Also nutz das GUI und überlass alles Unraid. Dann passt das. Die Bordmittel werden aufgebohrt:

Ich denke, dass diese Vorgehensweise nicht im Sinne des Erfinders ist. Du hast dem User-Share AEV im Array einen ZFS-Pool "cachesam" vorgeschaltet. Solange AEV auf dem Array existiert, wird wohl AEV auch auf dem Pool existieren. Du hast ja auch eingestellt, dass diese Verknüpfung existiert. Ich arbeite nicht mit User-Shares deshalb muss ich fragen: Wie ist das mit einem BTRFS Pool? Würde der Mover zum Abschluss den Ordner AEV auf dem Pool löschen? Meines Erachtens wird mit ZFS ein User-Share auf einem Pool zu einem Dataset. Der Unterschied zwischen BTRFS und ZFS wäre dann nach meinem Verständnis: BTRFS legt den User-Share Ordner automatisch per MKDIR auf dem Pool an und löscht ihn - wenn der User-Share gelöscht wird - mit RMDIR. ZFS hingegen legt mit create einen Dataset an und der muss mit destroy gelöscht werden. MC kennt und kann das aber nicht. Nur mit mkdir erzeugte Ordner können mit rmdir gelöscht werden. IMHO musst Du nix anderes machen als die Finger vom Root-Ordner AEV zu lassen ... Du spielst mit einem RC - das ist noch nicht für den ernsthaften Betrieb gedacht. Außerdem ist die ZFS Integration laut des Announcements erst mit dem nächsten Release komplett. An dieser Stelle lohnt es sich somit, einen Schritt abzuwarten. Auch ich warte auf einen besseren Pool, aber das alles schreckt mich noch ab. Meiner persönlichen Meinung nach muss Limetech nochmal zurück ans Reißbrett um das Verhältnis Array <-> Cache <-> ZFS-Pool glatt zu ziehen.

Gehäuse, Netzteile, Backplanes (Supermicro SC846): Ich denke um die 8-10 Jahre. Rennen 24/7/365 und rennen und rennen. Das zugehörige Mainboard (ich glaube Supermicro X7 Serie) hatte ich 2021 ausgetauscht. Das würde aber wahrscheinlich heute noch laufen. Auch CPUs halten extrem lange und RAM, keine Ahnung, RAM ist mir noch nie kaputt gegangen und ich staune immer wenn ich hier über MEMTEST lese. Bis mir jemand das Gegenteil beweist halte ich MEMTEST für ein Plazebo bzw. eine Möglichkeit die eigentlich Fehlersuche nach hinten zu schieben Gute Hardware hält sehr lange. Im Grunde genommen kaufe ich meistens gebrauchtes und professionelles Werkzeug, als irgendeinen hippen neuen Kram.

MC, ... Ich dachte es geht um "cachesam" und das ist eindeutig ein ZFS Pool. "cachesam" liegt gem. Deiner Screenshots definitiv nicht auf dem Array. Und das Löschen von AEV auf dem Pool scheitert. So mein Verständnis und daraus hatte ich abgeleitet: "cachesam" ist ein ZFS-Pool. Nun kopierst Du von extern Dateien und Ordner darauf. Darunter befindet sich der Ordner "AEV" und unter "AEV" ggfs. weitere Unterordner. Meine Frage oben zielt darauf ab, ob es einen Unterschied beim Löschen von AEV oder einem Unterordner von AEV gibt. Das wiederum kann Aufschluss darauf geben ob AEV ggfs. als Dataset automatisch angelegt wird und ob AEV zu einem User-Share wird (wie beim Array). Ich habe noch nie in den vergangenen 15 Jahren mit Unraid permanent Wurzelordner (AEV) angelegt und wieder gelöscht. Da diese ja eigentlich zu "User-Shares" werden kann es durchaus sein, dass Unraid diese unter ZFS besonders behandelt bzw. behandeln muss. Dass die Doku angepasst werden muss ist jedem klar. Schon alleine das ZFS Pools Cache-Only benötigen um korrekt zu funktionieren weicht heftig vom Array ab. Aber das wurde schon kommuniziert und bestätigt. Der Cache ist ein Dinosaurier und spätestens mit ZFS muss der anders deklariert und behandelt werden. Wenn ich das falsch verstanden habe, sorry. Wenn das Wurzelverzeichnis AEV permanent auf dem cachesam Pool verbleiben würde, dann tippe ich, dass Du diese Probleme nicht hättest. Deshalb würde mich interessieren ob Du auch Probleme mit dem Löschen von Unterordnern von AEV hast.

Dachte ich mir. Kannst Du einen leeren Ordner unterhalb (!) von AEV manuell (!) löschen? Nur noch mal für mich: AEV wurde während des Kopierens von Windows unterhalb von "cachesam" als Teil eines Kopiervorgangs automatisch angelegt? Bin sehr gespannt. Habe da so meinen Verdacht.

ZFS?

Dann geht's leider nur mit Augen und Fingern.

Nein. Du kannst nur erkennen ob überhaupt zugeordnet wurde (siehe oben). Mit Programmierkenntnissen könnte man mittels der Web-API von Plex durch den Bestand wandern und dann gegen den Ordner abgleichen ob etwas fehlt oder zu viel ist. Ich nutze die Web-API sehr intensiv. Mit der Web-API hole ich die folder.jpg, fanart.jpg und movie.xml/serie.xml Dateien auf die Platten: https://support.plex.tv/articles/201638786-plex-media-server-url-commands/

Das stimmt. Während ich bei Filmen und Serien einen normierten Originalnamen verwende, weiche ich bei Episoden deshalb davon ab. Die heißen bei mir einfach nur S01E01 oder S1940E01 oder S01E01-E02. Den Titel patche ich mit eigenen Skripten in die MKV Dateien - das mache ich bei den Filmen zusätzlich ebenfalls:

Ich nicht. Hab mir gestern mal die Details zu "In aller Freundschaft" angeguckt. Auch so'n Langläufer

IMHO wird das zu einem Fass ohne Boden. Verteil doch einfach zu Beginn den vorhandenen Content innerhalb der Platten nach Deinen Wünschen. Beispiel: /disk1/Medien/Ein Film/ --> /disk1/Filme/Ein Film/ ... /disk2/Medien/Eine Serie/ --> /disk2/Serien/Eine Serie/ ... Ich denke Du erkennst worauf ich hinaus will. Das dürfte relativ schnell über die Bühne gehen da nur "mv" innerhalb einer Platte mit dem Werkzeug Deiner Wahl. Bei Nutzung von User Shares wars das dann schon. Du greifst dann einfach auf /mnt/user/Filme/ oder /mnt/user/Serien/ zu. Ich habe am Anfang auch so angefangen wie Du, das kam aber sehr schnell an seine Grenzen. Bei mir sind es nicht nur Platten, es sind drei Unraid Instanzen. Die ganze Verschieberei und Sortiererei wird dann irgendwann mal zur Arbeitsbeschaffung. Was die Benamsung und den Inhalt der Medienordner anbelangt, da liegt Plex mit seinen Regeln eigentlich ganz gut: https://support.plex.tv/articles/naming-and-organizing-your-movie-media-files/ https://support.plex.tv/articles/naming-and-organizing-your-tv-show-files/ Von wenigen Ausnahmen abgesehen halte ich mich an diese Regeln. Die Ausnahmen sind bei mir a.) keine Staffelunterordner bei Serien und b.) keine Doppelung der IMDB/TVDB/TMDB Hints in den Ordnern - die gibts nur in den Namen. So sieht das bei mir aus und es funktioniert perfekt: 1.) Filme: Die Verwendung solcher Regeln bringt echten Mehrwert: 2.) Serien: ... und was die Anzahl der Episoden angeht - Lindenstrasse 1767 ... Überdenke das einfach nochmal. Wenn Du einmal mit dem sortieren angefangen hast, dann wird Dich das auf Dauer beschäftigen.

Diese 70 W waren u.a. der Grund zum Wechsel auf mein aktuelles System. Egal was ich machte, in nvidia-smi (hieß das so?) standen minimum 70 W Verbrauch. Bin aber auch aus anderen Gründen zufrieden mit dem Wechsel - freut mich für andere wenn es nur bei mir fehlerhaft war.

Dann wurde wohl gelöscht. Hast Du ein Backup? Ansonsten würde ich Dich hier weiterreichen an jemand der schon mal versucht hat gelöschte Dateien aus einem Dateisystem (welches?) zu rekonstruieren. Diese Person wird aber erheblich mehr Informationen benötigen als Du bisher ausgepackt hast. Wo liegen/lagen diese Shares oder User Ordner - ich persönlich kenne sie nicht. Die musst Du also selbst angelegt haben. Mach auf jeden Fall einen Screenshot der Hauptseite sowie poste Deine Diagnostics.

Guck doch einfach mal auf Deine Platte(n) in der Unraid GUI. Fehlen da jetzt irgendwo 6 TB? Werden irgendwo 6 TB mehr freier Speicherplatz angezeigt? Was ist der Shares Ordner? Wo liegt der (Datenplatte im Array, appdata, ...)? Wie bzw. als was hast Du ihn in Nextcloud eingebunden? Als config oder als data oder als weiteren gemappten Pfad?

Die 1050ti? Die mit 4GB RAM? Nie im Leben. Ich habe die vor zwei Jahren wegen eines Grundverbrauchs von ca. 70 W rausgeworfen. Da müssen die NVIDIA Treiber in den vergangenen zwei Jahren schon massiv geändert worden sein. Aber ich lasse mich gerne eines Besseren belehren.

1.) Das ist ein Release Kandidat, da passiert so was schon mal. 2.) Mit Fehlern in Beta oder RC Releasen kann nicht jeder helfen. Ich würde so etwas immer im offiziellen Bug Report Forum für Prerelease melden. 3.) Ich meine diesen konkreten Fehler mit den beiden Pfeilen in irgendeinem Bug Report schon mal gesehen zu haben. Müsstest mal suchen ob er nicht schon drin ist.

Alles komplett drauf. Wir haben insgesamt vier Komplettsicherungen der relevanten Daten - davon 1x Cloud, 2x externe Safes, 1x feuer- und wasserfester Dokumentenkoffer - letzteres falls man mal schnell weg muss Ich bin paranoid was das angeht. Hab schon zu viel kaputt gehen sehen (Bandsicherungen die sich aufwickeln, CDs über die man mit dem Bürostuhl rollt, ...). Unser ältestes, digital gescanntes Bild ist aus 1920 - ich will das alles nicht verlieren. Da hängt zu viel Zeit, Arbeit und Liebe drin. Aber dazu hat jeder eine andere Einstellung. Vielleicht muss man erst etwas älter werden bevor man das alles wertschätzt.

Ja, sogar in zwei verschiedenen externen Safes. Die wichtigen Daten sind uns seehhhrrrr wichtig. Ob emotional oder monetär spielt zunächst keine Rolle. Manche Daten repräsentieren ein langes Leben, andere hat man in mühevoller Kleinarbeit zusammengestellt. Da will man nix verlieren. Wöchentlich wäre mir das zu wenig. Ich nehme mal ein Beispiel an Plex was Du machen könntest um die Last zu minimieren: Ich sichere und "dumpe" täglich die wirklich relevanten Daten von Plex (Datenbank, Settings, Abspielstatistik). Mit diesen Daten kannst Du Plex nach einem Totalverlust wieder aufsetzen. Die Metadaten sind zunächst nicht so wichtig, die sichere ich dann aber trotzdem einmal pro Woche. Was ich sagen will: Auch innerhalb von sicherungswürdigen Inhalten kann es nochmals Abstufungen geben.