tobytl

All of this assumes the "jshridha/blueiris:gpu" repository is being used (template default, for me at least). Updating Blue Iris: You can update the Blue Iris app itself by temporarily disabling the autorestart from supervisord. The file /etc/supervisor/conf.d/supervisord-normal.conf contains the supervisord config in normal mode. The problem is that there aren't any common text editors in the docker image, so you need to install one (or use sed if that's your thing). Just remember every time you update the docker or edit/save the docker settings, this will reset and you'll need to install nano again. So to install one from the docker command line (or 'docker exec -it blueiris bash' from the unraid terminal): apt update apt install nano nano /etc/supervisor/conf.d/supervisord-normal.conf Use the arrow keys to go down to the bottom of the file. Under the [program:blueiris] header, change autorestart=true to autorestart=false. Press ctrl+o then enter to write changes. Press ctrl+x to exit. Restart the container. At this point you can go to the web vnc interface, check for updates and install as normal. If you use the UI3 web interface, you have to update that as well. Minimize the blue iris app (down arrow in the upper right, just like windows) Right click on the desktop and choose Applications -> Blue Iris -> Install Latest UI3. Alternatively, this part can technically be done on the commandline instead: unraid terminal: docker exec -it blueiris runuser -u wineuser /home/wineuser/get_latest_ui3.sh or, docker image terminal: runuser -u wineuser /home/wineuser/get_latest_ui3.sh I suppose you could automate that part on container start, but I don't know the consequences of updating UI3 independently of Blue Iris itself, so I just do it manually every update. Don't forget to set autorestart=true in the supervisord-normal.conf file when done, otherwise blueiris will not recover if it crashes (it's wine, it will crash eventually). Service Mode Quirks: Also, to anybody who wants to run this in service mode, just to not have xorg/vnc/fluxbox and the blueiris console running in the background, there's some stuff you need to take care of. First make sure the UI3 web interface is set up and working, it will be your only way to access blue iris from your PC in this mode (obviously). Enable the service from blue iris options -> startup tab, once the service option is checked (or sometimes after clicking OK) it might appear to be locked up, just hit ENTER on the keyboard (there's supposed to be a prompt that isn't being displayed properly, yay wine). Then click OK to close the options dialog. DO NOT RESTART THE CONTAINER YET! To work around another wine quirk or blue iris bug you'll need to edit the service entry in the registry (there's a missing quote ' " ') Unraid terminal: docker exec -it blueiris runuser -u wineuser wine reg add "HKLM\System\CurrentControlSet\Services\BlueIris" /v ImagePath /t REG_SZ /d "\"C:\Program Files\Blue Iris 5\BlueIris.exe\"" /f Or, docker image terminal: runuser -u wineuser wine reg add "HKLM\System\CurrentControlSet\Services\BlueIris" /v ImagePath /t REG_SZ /d "\"C:\Program Files\Blue Iris 5\BlueIris.exe\"" /f Back in the unraid web interface: Docker -> blueiris -> edit to get to the config for the docker image. Click the "BASIC VIEW" toggle to switch to advanced view. In the "Post Arguments:" field enter: -c /etc/supervisor/conf.d/supervisord-service.conf Save. It should rebuild and restart the image. The VNC interface will not work, but the UI3 web interface should come up fairly quickly. Removing the "Post Arguments:" content will revert back to normal. This also removes the service entirely, so you will need to start over and re-enabling it in blue iris itself to go back to service mode if desired.

The JVM_MX variable addresses the memory usage problem. The unifi-video launcher sets the java heap to 25% of your memory by default, which is a tad excessive. They set it to 1548M on their own hardware, so that's probably safe. Edit your UniFi-Video docker container, click the "Add another Path, Port, Variable, Label or Device" at the bottom, and set it up as in the image provided by @CorneliousJD below:

After a full 24 hours, it's still stable. I'm not going to call it a "fix", as I don't think it addresses any root problems, but it's a pretty good mitigation. So far at least, completely stable. I'll leave it running on the main server. Meanwhile, I'm going to play with getting a "wiredtiger" implementation working in the docker container on a test system to see if that affects anything. Don't think it will, and it's a nightmare to in-place upgrade the DB reliably, so I bow to the container dev in that endeavor. Good luck on whenever that becomes necessary (assuming UBNT don't figure out a way to do that nicely.... not holding my breath though).

I'm seeing the same behavior as @IamSpartacus, including the OOM reaping with any memory limit set (up to 8G). Beyond that... Welcome to the madness that is linux memory management... For instance, in my case the issues start well before any errors ever crop up in any logs. After running the UFV container for a few hours, the Plex container starts getting weird, transcodes will be fine, but "Direct Play" content will suddenly disappear from memory while streaming which throws an error on the client about the server or connection not being fast enough to stream. A few hours after that, I'll start seeing unresponsive containers, they are running and the process inside them is running (and working), just not responding to input (webui/commandline/etc). And then after about a day of running the UFV container, the dreaded "unable to fork" and "resource temporarily unavailable" messages start popping up all over the place. All of this while the host still thinks only about 50% of ram is being used. Fun. Anyway, I'm currently testing with an enforced low JVM memory heap for the container to see if that helps. By default the unifi-video script sets a heap size of 1/4 of your system memory (8G in my case), but only 1548M on their nvr appliance. But, it also has an ENV override variable, so I added a variable to the docker template for "JVM_MX" set to a value of "1548M", and it worked in setting the heap size at least. So far a couple of hours in, and it's not using a ton of memory yet, and the early symptoms haven't started. Needs a much longer testing period though.

I am seeing this as well in 6.6.3. Even in safe mode, and disconnected from the network entirely. Set vfs_cache_pressure to 0 ("sysctl vm.vfs_cache_pressure=0") Execute find /mnt/user/SHARENAME of a fairly large share periodically for a while (I used the watch command) Eventually (sometimes it's more or less immediately, sometimes it takes a few hours) the find command will spin up and read some/all disks that share is on even though the dentries should be cached permanently. This will then proceed to happen more and more often, until it happens every find command issued. This does not happen on 6.6.1, I don't have to install files to test on 6.6.2.