mgutt

Through a mobile device this is a pain. PS I'm having this problem, too: https://invisioncommunity.com/forums/topic/427328-button-in-ckeditor-to-delete-content-of-text-area/

Ah ok. You passed multiple source paths and by that it uses one log for all source paths. This bug will be solved in the next version. I already fixed it, but I'm still testing the next release

Rein mechanisch ist den Platten das egal, aber für die Performance ist es in jedem Fall besser. Die Buffer/Chunks erscheinen mir nicht sonderlich groß zu sein. Wenn die Platte sagen wir mal im Schnitt je nach Position der Daten 150 MB/s schnell ist, heißt das ja bei einer Chunk-Size von 16M, dass er 16M liest und parallel kommt ein 16M Schreibbefehl von dem Sync, der herunterlädt. Rein vom Gefühl her würde ich alles auf 256M stellen (was laut meiner Recherche sogar der Standard ist). Was meinst du? Oder du aktivierst für den Share den Cache. Dann würden ja alle Downloads erstmal auf der SSD landen. Damit löst du das Problem sowieso.

It will never be "fast", even with RAM transcoding. The only fast options are direct stream/play or pre-transcoding to a lower quality version so it can directly play it. Netflix & Co pre-transcode all movies in all qualities. Of course this needs a massive amount of space.

Ich vermute es. Hier sind die verschiedenen Modi beschrieben: https://docs.docker.com/storage/bind-mounts/#configure-bind-propagation Wenn ich das richtig verstehe, dann ist ext4 nativ lokal gemountet und Docker will das dann auch noch mal mounten und das geht dann wohl nicht. Daher ist es nur ein "Slave"-mount, also eine Art Link auf den bereits bestehenden Mount. Bei NTFS kann ich mir gut vorstellen, dass da noch ein Treiber dazwischen liegt, so dass es deswegen da dieses Problem nicht auftritt. Aber alles nur Mutmaßungen

Über welche HDD sprechen wir genau? Also das Modell. Wie ermittelst du eigentlich die Transferraten? Vom Prinzip kann es schon langsam mit einer HDD werden. Besonders wenn er vom Anfang eines Platters liest und am Ende eines anderen Platters schreibt. Der Schreib-Lesekopf springt dann ja hin und her. Die Frage ist nun ob die Software genug Daten im Voraus liest und schreibt um das Springen zu überbrücken. Welche Cloud-Software verwendest du und kann man bei dieser den Buffer / Chunk einstellen? Bei rclone kann man beim Mounten zb beides einstellen: https://rclone.org/commands/rclone_mount/

Die Frage ist was OMV zusätzlich an Befehlen abgibt. Noch nicht getestet, aber unterstützt Unraid evtl auch den Befehl? systemctl suspend

This is the only line that generates the log file. I would wonder if the old logs raise in size?!

Da WebDAV nativ in Apache als Modul verfügbar ist, würde ich vermutlich auch Apache nehmen: https://hub.docker.com/r/bytemark/webdav/ Es hat allerdings keine GUI. Du müsstest zum Hochladen einen WebDAV Client deiner Wahl nehmen, FTP, SMB, etc. Scheinbar gibt es ja auch einen fertigen Container dafür. Der Vorteil wäre, dass man kein PHP und kein MySQL benötigt. Das Pwndrop sieht aber auch nicht verkehrt aus. Das basiert auf Perl oder? Edit: Nginx kann auch WebDAV?! Dann wäre das auch eine Option: https://github.com/ionelmc/docker-webdav

Ach du nutzt die Beta? Hast du noch einen Stick übrig? Dann könntest du mit einem neuen Stick und einer Trialversion kurz testen ob es mit der stabilen Version geht. Da nutzt Unraid ja auch noch den 4.19 Kernel.

Ist die Platte evtl einer VM zugeordnet? Krusader hast du /mit/disks zugeordnet? Die Platte wurde mit UD gemountet? Edit: Problem gefunden. Muss per "slave" eingebunden werden: https://forums.unraid.net/topic/57181-docker-faq/#comment-564314

Ok, also der CPU Lüfter zb läuft weiter? Unraid macht da so gesehen gar nichts, weil das vom S3 Plugin genannte Kommando geht direkt an den Linux Kernel: https://www.kernel.org/doc/Documentation/power/interface.txt Denkbar wäre, dass OMV eine neuere Kernel Version verwendet und dort ein Treiber für deine Hardware enthalten ist, die in Unraids Kernel fehlt. Kannst du das mal prüfen?

@hf00 As you can see, "ls" scans the backup path for all created backups. "t" sorts them by time and "A" let it return hidden folders as well. Then "while" starts looping through all the found backup folders. And the part you quoted, extracts the day, month and year out of the backup folder name. "0:4" means for example the first four chars of the folder name which is the year.

That's the reason why you should limit the RAM path to 4 or 8GB. Even your server can crash. Plex uses as much space for the temporary transcoding files as available. This has nothing to do with 4K. The same would happen if multiple clients transcode 1080p streams. Plex preserves so much files so the user is able to jump back on the timeline without the need to re-transcode. But as this is a rare case, you can limit the RAM usage without problems. Plex starts cleaning when there is no space left. In theory you could even limit it to 100MB (don't do it, causes juddering ).

Das S3 Plugin führt diesen Befehl aus: echo -n mem >/sys/power/state Es gibt diese Modi: mem = suspend standby = power-on suspend freeze = suspend-to-idle disk = hibernation Alle verfügbaren Modi deines Setups bekommst du so: cat /sys/power/state Eventuell probierst du über das Terminal einen anderen Mode um zu schauen wie sich die Hardware verhält. Also die LAN Buchse ist aus oder ist sie an, nur das Magic Packet greift nicht? Geht er denn über die Power-Taste an?

If I add a code in a forums post, the complete process is slow and the default formatting is HTML. I don't really see the benefit of this "fancy" code colors. I think a faster forum usage is more important. Maybe others think the same and this feature can be disabled?! And I like to have the quote and code button in the mobile view of the forums. Both are missing:

Wie gesagt. Config Dateien löschen, feste IP über die GUI einstellen und bei Bedarf noch mal neustarten. DNS muss auf den Router eingestellt sein also 192.168.178.1 Meine Config ist ähnlich: # Generated settings: IFNAME[0]="br0" BRNAME[0]="br0" BRSTP[0]="no" BRFD[0]="0" BRNICS[0]="eth0" PROTOCOL[0]="ipv4" USE_DHCP[0]="no" IPADDR[0]="192.168.178.9" NETMASK[0]="255.255.255.0" GATEWAY[0]="192.168.178.1" DNS_SERVER1="192.168.178.1" USE_DHCP6[0]="yes" DHCP6_KEEPRESOLV="no" SYSNICS="1"

Kommt jetzt natürlich drauf an wie viele Platten man anschließen will, aber wenn zb 5 extra Ports reichen, dann sollte der JMB585 locker 10W weniger verbrauchen. Mein M.2 SATA Adapter zieht um die 2W. Aber das stimmt schon. Powertop läuft mit dem Adapter nicht.

All overpowered for your use case. A G5400 or i3 is all you need. Later you can still buy a Xeon if you need more power. For what? Yes No, because the AMD iGPU isn't supported by Plex. M.2 is nice for VMs or 10G LAN, but even 10G LAN can be covered with RAM Caching (what I'm doing). Nevertheless I would buy a board with two M.2 slots to be flexible regarding upgrades. Note: not all boards allow using all m.2 and sata slots at the same time. An RTFM moment

Mach das nicht. Nutze eine feste IP außerhalb vom DHCP Bereich der Fritz!Box und lass den Server die setzen.

Doch, weil wenn der Ordner leer ist, dann verschiebt der Mover den Ordner auf die HDD und dadurch muss die HDD anlaufen, damit Papermerge den Ordner scannen kann. Liegt der leere Ordner dagegen permanent auf der SSD, dann passiert das nicht. Was auch richtig ist, wenn der Share appdata auf "prefer", "only" oder "yes" steht. Das ist ja der Sinn an der Sache. Der Share wird gecached. Wenn der Share auf "Prefer" steht, dann nutzt der Share ausschließlich den Cache, außer die SSD läuft voll. Bei "Only" nutzt er ausschließlich den Cache. Und bei "Yes" nutzt er den Cache bis der Mover aktiv wird und die Dateien auf das Array verschiebt. Über /mnt/user/appdata siehst du immer die Summe aus /mnt/cache/appdata, /mnt/disk1/appdata, /mnt/disk2/appdata, usw. Das ist nur ein "virtueller" Pfad.

Wenn das der Hauptzustand ist, dann erstell mal die folgenden Dateien: /mnt/cache/dein/papermerge/pfad/.hidden /mnt/diskX/dein/papermerge/pfad/.hidden Der Ordner ist dann "leer" und der Mover kann diesen Ordner nicht von der SSD löschen, weil die Datei ".hidden" nicht auf das Array verschoben werden kann. Alternativ könnte man auch nur die Datei erstellen: /mnt/cache/dein/papermerge/pfad/.hidden Und sie unlöschbar/unbeweglich machen: chattr +i /mnt/cache/dein/papermerge/pfad/.hidden Dann braucht es nicht mal die Kopie auf der HDD. Selbst der Root kann die Datei nicht mehr verändern. Rückgängig macht man das dann so: chattr -i /mnt/cache/dein/papermerge/pfad/.hidden

Which reason is so important to bypass these settings? Settings -> Global Share Settings -> Use cache disk -> No Settings -> Global Share Settings -> Min. free space -> Any value Shares -> Share Settings -> Use cache -> Yes (so the mover moved them) / No Shouldn't the user decide when he likes to bypass his own settings? But this does not happen if the user disables his cache after the container has been already installed. This happened to me while I was moving appdata back to my cache and starting the docker service without waiting for the mover finishing its work. The containers using /mnt/cache/appdata thought they needed to make a fresh install and finally I had files from a new installation mixed up with files from the old installation. Not funny ^^

Man könnte das Verzeichnis mit inotifywait überwachen und neue Dateien sofort mit dem Array synchronisieren. Der Mover lässt die Datei dann auf dem Cache, weil sie bereits auf dem Array existiert. Schlussendlich müsste man dann 1x am Tag hingehen und alle Dateien vom Cache löschen, die älter sind als x Tage. Allerdings weiß ich nicht ob dadurch die HDD wirklich aus bleibt. Müsste man mal testen.

Dann ist der Share "Appdata" nicht auf "Prefer" oder "Only" eingestellt oder du hast bei der Änderung den Pfad nicht korrekt gesetzt. Noch mal zur Kontrolle. Aus zB dem Pfad: /mnt/cache/appdata/pihole/pihole wird: /mnt/user/appdata/pihole/pihole