azche24

If you configure your library to convert video to HEVC and the file is already H265, then unmanic will not pick up conversion again. If you want to runn other tasks against that file, you can do that with another plugin in the same library. For example if i run my "convert audio to AAC" library (which is a copy of my original library) against the existing files, this will a) convert audio and b) skip video H265 transcoding, if the file is already H265. So no need for an extra plugin or configuration here.

Thx. I'll switch back.

I rebuilt my 2x1 TB NVME cache pool from BTRFS to ZFS after version 6.12 came out. Now (after several weeks) i noticed, that mover action was incredibly slow. Even if running mover without any filters (or mover tuning plugin) a move of about 100 GB of media data needs more than 2 hours. Which is way too slow in my system. In BTRFS this was about 15 minutes or so - just maxed out by the write speed of the array at about 60 - 70 MB/s. Before i switch back to BTRFS: Has anyone an idea where to look or optimize. Because the r/w performance to cache is excellent, when using ZFS cache pool.

Yes, both are Samsung 980 SSDs.

These are reads (if so) not writes. As far as i know, unRAID does not do "read caching". These drives have heat-sinks and the are getting "one by one" up to 84 C (and then throttling). Does not seem "normal" to me.

Hi, every time i'm doing a backup job via rsync like \\NAS02\Media -> \\backup-nas\backup (where NAS02 is a unRAID share with cache and "backup-nas" is a remote share mounted in unRAID via SMB) my cache drives (2x1 TB NVME-SSDs) are overheating several times. I'm speaking of large (> 4 GB) backup jobs running for hours. This is coming from log files or what? How can i avoid this? Rsync is started with "user-script" plugin, but that should not be the concern.

Ich hatte (vor etwa 15 Jahren) den Vorgänger von Zentyal "SME-Server" in einem Büro mit etwa denselben Merkmalen laufen. Damals noch ziemlich viel Hardware, riesige Festplatten usw. - was mich zur Abkehr brachte, war die Notwendigkeit von MS-Exchange und der ewige Stress mit einem selbst gehosteten E-Mail Server. Das würde ich mir nie wieder antun. Bis auf den Photo-Upload (den ich im Zweifel über ein kommerzielles Cloud-Angebot realisieren würde, wenn nicht mit Synology Photo-Station wie jetzt) und die ziemlich "rohe" Implementierung von E-Mail war Zentyal sehr gut. Wer ohne Exchange oder abgefahrene Groupware auskommt, ist damit für eine Büroumgebung wohl auch heute noch (ich habe neulich eine aktuelle Version zum Test installiert) bestens bedient. Vor allem hat Zentyal eine "komplette" SMB Implementation. Alles, was ich bei unRAID auf diesem Gebiet vermisse, wie Home-Directories, granulare Gruppenberechtigungen, AD - Zentyal läuft insoweit komplett out of the box. User anlegen, Rechte und Gruppe zuweisen. Fertig! Zentyal ist allerdings nicht ganz umsonst. Bereits einfache Dienste wie besseres Backup, DynDNS, Monitoring, Support kosten (und zwar nicht wenig). Das lohnt sich normalerweise nur, wenn man darauf verzichten kann oder eine krasse Menge an Benutzern mit einem Server versorgen will. Die community war damals toll und sehr global: Viele Leute aus AUS und US, da bekam man im Forum innerhalb von Stunden gute Tipps. Und ansonsten ein sehr wartungsfreies System, das sich auf jedem besseren PC sehr performant einrichten lässt (RAID1, gute Netzwerkanbindung und los geht's). Zentyal wurde bei mir von Synology abgelöst - je nach notwendigem Speicherplatz und RAM-Anforderungen bleibt man da unter 1000 € in Hardware und die Cloud-Backup Lösung von Synology ist unschlagbar gut und günstig. unRAID verwende ich nur als Datengrab für Medien (Musik und Filme) - das hat durchaus spielerischen Charakter. Die Speicherplatzlösung ist ja für selten benutzte Daten sehr ausgereift und robust. Alle anderen Anwendungen scheiden im professionellen Bereich für mich aus. Backup ist kompliziert einzurichten, die Lese- und Schreibgeschwindigkeiten (vor allem Lesen!) sind für meine Zwecke nicht ausreichend und im Zeitalter der riesigen schnellen Festplatten habe ich mit DSM auch keine Speicherplatzprobleme mehr. Derzeit überlege ich sogar, die Medien zurück zu ziehen. Bei erschwinglichen Festplatten mit 18 TB Kapazität und dank Portainer kann ich eigentlich auf meiner DS 1821+ fast alles umsetzen, was ich sonst auf unRAID habe. Ymmv, aber Synology bringt eigentlich für nicht professionelle Serverbesitzer mit professionellen Ansprüchen ein gutes Gesamtpaket auch für den professionellen Bereich. Active Backup, Hyper Backup - das sind überlebenswichtige Anwendungen, die es bei DSM praktisch umsonst gibt. Und es funktioniert alles. Das Einrichten von Docker Containern ist etwas fummelig, aber ansonsten... Nur die Preise von Synology sind explodiert. Seit die anfangen, Hardware nur noch mit ihren eigenen, sündhaft überteuerten Festplatten zu bestücken, wird es grenzwertig. Da ist man ganz schnell im oberen 4stelligen Bereich. Andererseits hat mein unRAID auch knapp 1000 gekostet (ohne Festplatten). Wenn Du nicht bei Synology bleiben willst, probiere ruhig mal Zentyal aus. Da gibt es aber m.W. keine Docker.

It was a docker related issue: Somehow my docker installation changed from "image" to "folder type docker" - perhaps automagically during a major update of unRAID. This lead to a "/mnt/user/system/docker/docker" instead of "/mnt/user/system/docker/" under "Settings/DockerSettings". So i had to shut down the dockers (and make a backup) move the content from "/docker/docker" to ".../docker" restart. Also i noticed, that roon still is slow (about 15 sec), when shutting down. This seems to be related to the general docker "cache vs. /mnt/user" problem - fuse filesystem is slowing down things, when the app share is addresed through the "normal" /mnt/user/appdata directory. After some reading i followed directions to start mover (to transfer all "appdata" to cache) shutdown array (to finalize this) restart array change share appdata to "cache only" adjust the paths in the docker template(s) especially roon from "/mnt/user/appdata" to "mnt/cache/appdata" - the same way the template creator made this in his template from the start Reasons for doing so are described elsewhere, but this indeed did speed up things (and brought down the standby power consumption a few watts). hth

Did you find the share? Then simply delete/rename it! I had this error pointing to a directory "/" above "appdata", left over from a hanging "delete network share" action. I had to go -> console -> mc -> /mnt/user and delete it there (from the command line). Also in my case the button "ignore" did not work.

Would be nice, but still does not work. I'm not able to stop the Roonserver Docker. It simply does not stop (which is bad for app-backups and system security). It just times out. After that I get the error Nothing helped. Not nuking/reinstall. Not installing into /.../mount/user/apps/... instead of /mount/cache/apps/... - i'm a bit sick of it, because the same thing runs easily on my other (Synology) NAS as a docker. Any more ideas? Shouldn't there be mapping for temp files also (i had this with Unmanic, where it is helpful to map tmp to RAM in any way. Any ideas?

Sorry, but no. I only use unRAID to store stuff and back it up to local disks via smb or to cloud.

OK, hab's begriffen und geändert. Die *.tmp Dateien gehen jetzt in /dev/shm. Habe genug Platz mit 64 GB RAM. Ist immer ärgerlich: RAM ist schnell und oft zu knapp 🤔

Update: ecoDMS still working (docker template edit needed). For reference i would like to contribute, what has happened to ecoDMS, a document archive and management system. The app in the repo is still based on ecoDMS 18.09 - this is not convenient any more - the actual version is 22.08! Also ecoDMS is pretty hard to maintain on a Synology NAS - you always have to re-install the whole stuff after every major update, which can be twice a year. So here unRAID comes in, which makes it sooo easy to install and update docker containers. These steps i would like to recommend for folks, who want to use ecoDMS: First create shares for scan input - should be readable/writable for the users and the docker container. In my case this directory resides on another NAS and is mounted via unassigned devices plugin. backup - very important, for this must be outside the docker container (don't use a directory in the apps-directory!) and must be backed up externally on a regular basis. I put this in a smb-mounted share (like "officedata") on another NAS, which is mounted by unassigned devices plugin. This is (aside from the data directory itself) the directory to back up externally (to the cloud or whereever). restore - should be reachable, can be on the unRAID nas (recommended) or somewhere else. Here you initiate the restore if needed. First install ecoDMS (APU 18.08) from the repo. This is the template to start with. After successful installation you have this (including the customisations) in your personal archive in "apps". Change the settings like in the screenshot. Docker should come from ecodms/ecodms repository, so updates are automatically done for you. Remember: The "backup" directory mapping should be outside the app-directory on unRAID. In my case this is also in the "working" directory on another NAS, which is backed up on a regular basis. This directory should not be in the /apps share - it can become quite large (4 GB in my case) and therefore should be kept and backupped outside. "restore" and "data" can stay in the /apps share on the cache drive. But you have to make shure, that the "restore.zip" (after a initial restore from your old data) is deleted after import - it can be pretty big also. Now have a look into the other settings and start the container - done!

Das ist schon ein Grund, Plex und Unraid nicht mehr für Downloads zu verwenden. Sämtliche Versuche, mit /transcode -> /tmp einen Download auf das iPad durchzuführen, scheiterten hier kläglich. Der Server erzeugt riesige Dateien im /tmp (von einem 2.5 GB H265 codierten Film bis zu 12 GB "output.mkv") und bricht dann ab - die Dateien werden durch den Plex-Server danach gelöscht. Gemerkt habe ich den Mist nur, weil Download im Plex nicht mehr möglich war und mein Unmanic Docker nicht mehr konvertieren konnte (/tmp war voll) Und Transcodierung in ein SSD Verzeichnis, z.B. /mnt/user/cache/Transcode ist auch keine Alternative, wenn man sich mal anguckt, wie viele und teilweise auch große Dateien Plex nur beim Streamen oder gar beim Download erzeugt. Das ganze Zeug möchte ich echt nicht dauerhaft auf die SSDs geschrieben haben. Edit: Habe es hinbekommen. Im Plex-Client auf dem iPad Settings->Downloads->Videoqualität 720p (Hoch), Ton 128 kbps und auf dem Server (Plex) -> Einstellung -> Mediathek -> erzeuge Kapitel-Thumbnails und Vorschau-Thumbnails = NIE. Wenn dann noch HW-Encoding funktioniert, geht es. Dauert etwa 15 Minuten für einen Download und erzeugt eine Datei auf dem iPad, die ca. 70 % vom Original umfasst.

I did not go through this whole thread, but you already checked this? Excessive writes to cache drive from docker applications seems to be a bit of a design problem in the docker/UnRAID combination. Many many docker apps write logs and temp-files to the docker image / cache drive, which should not happen. For my installation i had to change plex official with binhex-plex, add a few extra-paths for temp-files and map these to /tmp/ and install a RAM-drive like explained by @mgutt here. It still does excessive writes. In my case these come from roon-docker, which has tons of logs in docker.img and writes tmp files there too. There should be a "design guideline" for dockers with UnRAID, because this is really annoying. From the UnRAID point of view the problem is related to the design or implementation of the docker apps.