Beiträge von hi2hello

Ich glaube mittlerweile nicht, dass es an den Clients liegt bzw, dass diese damit etwas zu tun haben. Mir ist emby auch schon abgeschmiert, als neue Filme in die Bibliothek gepackt wurden und weder Zugriff auf die GUI, noch durch einen Client stattfand. Das Scannen hat noch funktioniert, danach … shutdown.
Generell scheinen Tasks immer erst mal in Ruhe abgearbeitet zu werden, bevor emby die Läden schließt.
Sehr löblich

@Justray2k: Du bist bereits auf 6.4.1(siehe Deiner Signatur) ? Auf RC2? Oder ist die Version schon stable draussen? Keine Verbesserung?

Deine Fragen wurden bereits beantwortet. Ich denke ebenfalls, dass alles ganz gut aussieht soweit ich das beurteilen kann.

Ich nutze meinen Server mit unRAID als Archiv und Medienserver mit emby, also ähnlich wie Du es vorhast. Gleicher Prozessor, ähnliche Config (nur kleiner im Format) …

Würde ich meinen Server heute noch mal bauen, würde ich ihm mehr als 8GB RAM gönnen. Nicht falsch verstehen - das läuft ganz gut aber wenn man dann doch mal auf die Idee kommen sollte, VMs zu nutzen oder die Anzahl der Docker mit der Zeit steigt …
Lange Rede, kurzer Sinn: Wenn Du die Möglichkeit hast - ich würde 16GB RAM empfehlen.

Noch was zum Stick: 16GB sind meeeeeehr als ausreichend (meiner hat keine 5% Auslastung). Einen neuen würde ich aber nicht extra kaufen, es sei denn, Du möchtest die 32GB lieber für etwas anderes nutzen. Kleine Randnotiz: Wenn Du in der Testphase bist kannst Du diese Lizenz nicht von einem Stick auf einen anderen übertragen.

Die beiden SSDs kommen als Cache im Raid-Verbund rein?
Welche Lizenz wirst Du Dir besorgen? 6 Platten oder hast Du mittelfristig mehr vor?

Ich habe Abstürze bei Zugriff von mehrere Devices bemerkt. Am häufigsten scheint es unter LibreElec auf meinem Odroid C2 vorzukommen. Aber auch bei Verwendung nativer iOS Apps ist es schon passiert, dass der emby Server sich verabschiedet. Via Browser ist es bisher noch nicht passiert aber ein Muster oder bestimmte Devices kann ich bisher nicht identifizieren.

Das Performance Thema habe ich auf den Aufbau der GUI im Browser (sowohl Chrome als auch Safari unter OS X) bezogen. Das war vorher (wenigstens mal mindestens gefühlt) schneller. Die nativen Apps auf iOS sind top performant und mittlerweile auch sehr stabil.

Ich habe auch den Eindruck, dass der Container generell langsamer ist. Der Aufbau der Grafiken und Vorschaubilder ist z.B. deutlich sichtbar. Caching?
Zudem hakt emby auch gerne mal für eine halbe Minute mal komplett bevor es weitergeht.

Ja, das war vorher deutlich flüssiger. Aber hilft ja nichts …

Ich schaue mich mal im Emby Forum um. Vielleicht findet sich ja was. Halte Dich dann auf dem Laufenden falls das so sein sollte.

Cheers

unRAID 6.4.1-rc2 sagt Kernel von 4.14.13 (in 6.4.0) auf 4.14.16., 6.5.0-rc1 auf 4.14.23. In den changelogs kann ich leider aber nichts zu unserem Thema oder zu der libcore.so ausmachen, die den Fehler zu verursachen scheint.

Da hilft wohl nur abwarten …

Schade jedenfalls, dass sich drüben bei Limetech gar niemand mal zu Wort meldet. Meinst Du, es liegt vielleicht an der Überschrift des Threads? Könnte es sein, dass sich die Entwickler von Emby-Problemen nicht so recht angesprochen fühlen? Bisher hat außer Dir und mir auch nur eine weitere Person vom gleichen Problem berichtet.

Hallo zusammen,

das Hinzufügen eines Cache-Drives zu unRAID hat gewichtige Vorteile denn es steigert u.a. die Performance der Schreib- und Kopiervorgänge enorm. Für viele sind die Verwendung und die Optionen aber ein Mysterium, zudem kommt es hier im Forum immer wieder zu Missverständnissen, was die einzelnen Optionen denn nun eigentlich bewirken, wie sich unRAID verhält und welche Einstellungen man denn nun wählen sollte.

Ich versuche hier mal ein wenig Licht ins Dunkel zu bringen …

[h1]1. Cache-Drive-Optionen[/h1]
Was bedeutet welche Option?

• NO
  Daten werden nicht auf dem Cache-Drive abgelegt. Daten werden direkt auf das Parity-geschütze Disk-Array geschoben.
• YES
  Daten werden auf das Cache-Drive geschoben UND auf dem Array abgelegt, sobald der Move-Befehl angewendet wurde.
• ONLY
  Die Daten werden nur auf dem Cache-Drive abgelegt.
• PREFER
  Daten werden so lange auf dem Cache-Drive abgelegt, bis das Cache-Drive voll ist, Weitere Daten werden erst dann auf dem Array abgelegt. Sollte beim Wählen dieser Einstellung noch kein Cache-Drive vorhanden sein, so werden Daten auf dem Array abgelegt. Wird dann ein Cache-Drive nachträglich hinzugefügt, so werden über den Mover Daten vom Array auf das Cache-Drive verschoben.

[h1]2. Welche Option sollte man für die Freigaben (shares) wählen?[/h1]

• PREFER
  ist die zu bevorzugende Option für Daten, die ständig in Benutzung sind und bei denen Geschwindigkeit eine gewichtige Rolle für die Performance des Servers spielt
  
  
  • appdata (docker container und deren einstellungen)
  • domains (vms und deren einstellungen)
  • system (unraid system dateien)

[icon='fa-bomb',32][/icon]Achtung!
Die Daten liegen im Modus „Prefer“ NUR auf dem Cache-Drive und haben daher kein Backup auf dem Array! Sie sind in dieser Form also ungeschützt, falls das Cache-Drive den Geist aufgeben sollte! Daher unbedingt an Backups der entsprechenden Freigaben denken (z.B. mit dem Plug-In: CA Backup / Restore Appdata).

[icon='fa-hand-peace-o',32][/icon]Anmerkung / Besonderheit:
Die Freigabe "System" bzw. deren Inhalt verbleibt trotz der Cache-Einstellung „Prefer“ erstmal weiter nur auf dem Array. Dies liegt daran, dass Docker-Container und VMs immer in Benutzung sind und diese Daten daher nicht kopiert bzw. verschoben werden können. Um die Daten vom Array auf das Cache-Drive zu transferieren, müssen Docker und VM vorübergehend abgeschaltet werden. Nach einem erfolgreichen Move-Prozess können Docker und VM wieder eingeschaltet werden.

• YES
  ist die bevorzugte Option, für Daten die oft in Benutzung sind, sich aber auch ändern oder auch größere Daten, bei denen das Schreiben auf das Array zu lange dauern würde.
  
  
  • downloads
  • medien
  • isos

[icon='fa-bomb',32][/icon]Achtung!
So lange die Daten nicht per Move vom Cache-Drive auf das Array verschoben wurden, sind die Daten ungeschützt!

• NO
  Diese Option sollte für Daten gewählt werden, bei denen Geschwindigkeit keine große Rolle spielt, aber Sicherheit ein wichtiges Thema ist. Beispiel wären hier sensible und persönliche Daten oder alles, was in den Bereich Archiv (Daten, die bereits auf dem Server liegen und in einen Bereich verschoben werden sollen) oder Datengrab fällt. Auch kleinere Dateien wie z.B. Fotos fallen unter diesen Punkt. Dies ist eigentlich so etwas wie der klassische NAS-Modus.
  
  
  • archiv
  • backups
  • foto

• ONLY
  Mir fällt kein plausibler Grund ein, warum man diese Option wählen sollte.

[icon='fa-video-camera',32][/icon]Hier noch ein super Video (leider in englischer Sprache), dass Cache-Drives und deren Verwendung unter unRAID umfangreich erklärt:
How to add a cache drive, replace a cache drive or create a cache pool

Nichts außergewöhnliches
2 x 4 TB WD Red HDD als Storage
1 x 4 TB WD Red HDD als Parity
1 x 256 GB Samsung EVO 850 SSD als Cache
alles als btrfs an SATA mit einem G4560 auf einem Gigabyte GA-H270N Board.

Nur 8GB RAM machen mich nicht so glücklich aber das ist ein anderes Thema.

PS: Wieder eine Menge gelernt aber in Summe für die Fragestellung trotzdem keinen Schritt weiter, zumindest so lange ich nicht mal den Midnight Commander getestet habe.

Hahaha - trotzdem immer wieder schön, mit Euch zu plaudern und sich auszutauschen!!!

@Snickers: Cloud Commander ist ebenfalls wieder von der Platte geflogen. Leider zu langsam bei "großen" Verzeichnissen.
Was soll’s, geht ja irgendwie trotzdem und es bleibt ja wie gesagt noch der Midnight Commander und die Möglichkeit, dass ich mir endlich mal die shell besser drauf schaffe (ächz).

Weiss nicht, ob wir vom selben sprechen oder ich Dich richtig verstanden habe aber die Ausgangsfrage war, warum ich auf der Suche nach einem Dateimanager bin bzw. warum ich Dateien intern hin und her schiebe und nicht über SMB bzw. das Betriebssystem.
Über interne Dateimanager kann man in unRAID Freigabenübergreifend sowohl MOVE, als auch COPY einsetzen. Auf meinem OS X aber funktioniert MOVE nur innerhalb einer Freigabe ansonsten wird automatisch COPY angewendet.
Mit einer GB-LAN-Verbindung reisst es ein Cache-Drive in Sachen Geschwindigkeit bei einem COPY-Vorgang auch nicht mehr raus. Jedenfalls nicht im Vergleich zu einem MOVE.

Mit anderen Worten: intern = MOVE = schnell / extern = COPY = laaaaangsam

Oder meintest Du etwas anderes?

Nachtrag:
Habe mir das jetzt noch mal angeschaut und bei mir ist das Verhalten exakt so, wie ich es zuvor vermutet und beschrieben habe. Unter OS X kann ich mit SMB innerhalb eines Shares bzw. einer Freigabe Daten beliebig hin und herschieben, komplett ohne Zeitverzögerung. Die Dateien werden also geMOVEd. Sobald ich Dateien von einer Freigabe in eine andere schiebe werden diese in oben erklärter Weise kopiert und MOVE ist nicht möglich. Exakt das selbe Verhalten bei der Verwendung von AFP anstelle von SMB. Dabei ist es übrigens unerheblich, ob Daten auf dem Cache-Drive liegen oder auf einer anderen Disk.

Mit einem Dateimanager können die Dateien problemlos mit dem Move-Befehl verschoben werden, völlig unabhängig, auf welcher Freigabe diese auf unRAID gespeichert sind.

Bleibt dann wohl also doch nur der "Umweg" über Dateimanager, Shell oder was-auch-immer-Commander.

@Justray2k Dann ist das exakt so eingestellt wie bei mir.

Zitat von Justray2k

Hast du deinen Freigaben verschiedene Platten zugeordnet?

Nein, eigentlich nicht. Alle Freigaben inkludieren alle Platten - jedenfalls die Freigaben, die in diesem Fall relevant wären.
Die Freigaben stehen aber nicht auf "Use Cache Disk" > prefered, sondern auf "Yes". Die einzigen Freigaben, die bei mir auf Cache > prefered steht, sind "Appdata" und "System" für schnellere Zugriffszeiten auf Einstellungen, Metadaten etc. Von diesen Freigaben wird vom Mover dann aber nie etwas auf die anderen Platten ausgelagert oder verschoben, so wie ich das bisher beobachten konnte. Worin der Unterschied also zwischen "prefered" und "only" steht hat sich mir in der Praxis noch nicht erschlossen.
Es gibt übrigens noch eine Option "enable copy-on-write", die klingt, also ob sie zum Thema passen würde, bei mir aber ausgegraut auf "Auto" steht.

Sind bei Dir "Transfer" und "Storage" separate Shares bzw. Freigaben? So wie ich das verstehe, ja.

Das widerspräche aber meiner Vermutung, dass man unabhängig vom Cache-Drive automatisch einen copy-Befehl auslöst wenn man eine Datei von einer in eine andere Freigabe verschiebt. Verschiebt man innerhalb einer Freigabe, scheint das problemlos und in Nullzeit zu funktionieren.
Es sei denn, man benutzt einen Dateimanager. Dann funktioniert das Move-Kommando wohl auch über shares hinweg. So viel jedenfalls zur Theorie bzw. meiner Erinnerung, da ich das leider gerade nicht testen kann.

Ich gehe heute Abend mal Deiner Vermutung mit dem Cache-Drive nach …

Zitat von darkside40

Das kommt auch drauf an welches OS du einsetzt.
Bei AFP denk ich an Apple, da wird es garantiert nichts mit dem Move Befehl übers Netzwerk.
Windows 7 wie bei meinem Encoding Knecht kann es auch nicht, deshalb mache ich es meistens per mc, denn ansonsten habe ich die gleiche Problematik wie du.

Verbinden mich äussert selten mit AFP (ja, Apple stimmt) und ich mag mich irren, aber ich würde meine Hand jetzt nicht dafür ins Feuer legen, dass beschriebenes Verhalten etwas mit dem Protokoll zu tun hat. Gefühlt hat das bei beiden Verbindungen -also sowohl SMB, als auch AFP- schon geklappt oder eben auch nicht. Ich müsste tatsächlich mal testen wann es auf OS-Ebene zum Move- und wann zum Copy-Befehl kommt.

Zitat von Justray2k

Blöde Frage:Und wieso muss diese Verschieberei direkt auf unRaid-Ebene passieren? Samba-Freigabe und die Sachen auf einfache Weise zb im WIndows Explorer schieben?
Das passiert bei mir dank Cache quasi alles in Nullzeit.

Vielleicht habe ich ja etwas falsch konfiguriert aber wenn ich via SMB (oder auch AFP) mit (m)einem Rechner auf den Server zugreife und dort Dateien von einem Verzeichnis in ein anderes schiebe, geht das ohne Zeitverzögerung, also quasi als Move-Befehl und nicht copy-Befehl, nur ziemlich selten.

In den meisten Fällen bedeutet das, dass ich eine u.U. mehrere GB große Datei von der Serverplatte durch mein Netzwerk zur Festplatte meines Rechners jage, um sie anschließend wieder übers Netzwerk auf den Server -, nur in einem anderes Verzeichnis zu kopieren. Das dauuuuuuuuuueeeeeeeeert …, in jedem Fall länger als das auf dem Server direkt zu machen. Nutze übrigens auch ein Cache-Drive.

An was es genau liegt, dass Dateien manchmal wie gewünscht und ohne Zeitverzögerung bewegt werden und manchmal einen langwierigen und umständlich Kopierprozess anstoßen, habe ich noch nicht wirklich herausgefunden. Meine Vermutung wäre, dass Dateien, die zum selben Hauptverzeichnis gehören verschoben werden können, andere werden kopiert. Könnte aber auch einer Rechtethematik liegen oder daran, dass Dateien bereits vom Cache auf einer Platte gelandet sind.

Ich lerne gerne dazu. Mein Herz hängt jetzt jedenfalls nicht an Dateimanagern wenn es auch bequemer geht.

Zitat von darkside40

Ne ne nicht der Zeichenzahl, man muss nur die richtigen Tricks auf der Linux Kommandozeile kennen, und die TAB Taste lässt dich schneller tippen als jede Stenotypistin

Ich höre und bin ganz Ohr!!! Quatsch – Ich lese und bin ganz Auge!!!

Zitat von Justray2k

Was muss man denn so oft hin und her kopieren bei unraid? Frag rein interessehalber. #nohate

Ich nutze unRAID als Medienserver und Archiv. Hier habe ich mir eine Ordnerstruktur geschaffen, die z.B. Filme, Serien und Dokus, aber auch Musikalben / 12inches, Fotos (RAWS) nach Ereignissen etc. in unterschiedlichen Kategorien und Ordnern ablegt. Zum Beispiel gibt es im Bereich Filme nochmals Unterordner für Sport, 3D, Animation bzw. Kids, … . Im Bereich Dokumentation werden diese weiter unterschieden nach Einzeldoku oder Dokuserie …
Konvertiert, rippt, entwickelt, … man Medien direkt auf dem Server, müssen diese anschließend in entsprechende passende Verzeichnisse verschoben werden.
Ich habe bisher keine schlaue Routine gefunden, das konvertiertes Medienmaterial automatisch und vor allem richtig in die entsprechenden Verzeichnisse bewegen würde. Ehrlich gesagt, wäre mir einen solche Konfiguration wohl auch zu umfangreich und fehleranfällig. Das mache ich dann also einfacher und vor allem schneller manuell und für diese Move-Operation benutze ich einen Dateimanager.
Wie man sich vorstellen kann bedeutet die obige Struktur ziemlich viele Unterordner und mir ist es einfach zu mühsam, jedes Mal ellenlange Pfade abtippen zu müssen bzw. mich genau daran erinnern zu müssen, wie denn jetzt der genaue Pfadweg aussah.

Zitat von darkside40

Setz dich 10min hin und lerne die Vorteile der TAB Taste auf der Kommandozeile und Kürzeln wie CTRL+T, CTRL+S etc. beim Midnightcommander kennen dann brauchste keinen grafischen Dateimanager mehr.

Und ja auf der Kommandozeile ist man auf jeden Fall schneller.

Den MidnightCommander werde ich mir tatsächlich mal ansehen und Geschwindigkeit ist eine Frage der Zeichenanzahl.

Zitat von BigChris

Ah, ok. Mausschubser
Ich mache das komplett über die Konsole und ich glaube nicht das ich langsamer bin.

Ich brauche zu lange, bis ich die ganzen lästigen "Pfade des Grauens" abgetippert habe.

@Snickers Kurzes Feedback zu Deinen Hinweisen: Dolphin war auf den ersten Blick vielversprechend, dann aber doch "dank" Guacamole (würg) gähnend laaaaangsam und ähnlich "performant" wie Krusader – also imho leider eher nichts. Cloud Commander sieht nach einer schlanken Applikation aus, ist aber auch noch nicht das Gelbe vom Ei (zu viel reingepackt in eine vom Platz her recht schmale Ansicht, so gut wie keine Konfigurationsmöglichkeiten). In Sachen Performance und Stabilität aber das bisher einzige, was man vielleicht länger benutzen möchte und daher mit Abstand am Besten.

Just my cup of tea
Danke nochmals für die Tips

PS: Falls jemandem noch ein Dateimanager einfällt … immer gerne!

@Snickers Packen/Entpacken brauche ich an dieser Stelle nicht bzw. kann ich darauf verzichten. SSH und Terminal sind mir in diesem Fall zu fuddelig.
Werde mal die von Dir angesprochenen FileManager testen. Dolphin und dann CloudCommander.

Danke Dir!

Gibt es schon neue Erkenntnisse zu der netcore-Crash-Thematik?
Auf limetech tut sich rein gar nichts. Habe das Thema mal "gebumped".

Kleiner Nachtrag:

So sieht bei mir die gekürzte Fassung des unRAID-Logs bei einem nachfolgenden Crash des Emby Dockers aus:
Feb 27 12:57:27 ServerName kernel: traps: EmbyServer[28326] trap invalid opcode ip:153485a522d4 sp:153470441a30 error:0 in libcoreclr.so[1534857c4000+39e000]

Und beim anschließenden Beenden von Emby findet sich das als letzte Einträge im Emby-Log:
Illegal instruction
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] syncing disks.
[s6-finish] sending all processes the TERM signal.
[s6-finish] sending all processes the KILL signal and exiting.