Video doesn't start recording automatically after the unifi-video container restart.

[thomasjslin]

I set the video record mode as "always record", but it does not start recording automatically after the unifi-video container restart. I have to remove the unifi-video container and re-install it to make it in recording mode.

NAS: Synology DS1618+ Docker version: Docker version 18.09.8, build bfed4f5 UniFi-Video-Controller(beta version): docker pull pducharme/unifi-video-controller:beta Note: My UVC G3 Flex, frimware: v4.22.13 can't be detected in version 4.10.11

Log from stop to start:

unifi-video.txt

[thomasjslin]

My install command:

docker run -d
--name unifi-video
--cap-add DAC_READ_SEARCH
-p 10001:10001
-p 1935:1935
-p 6666:6666
-p 7080:7080
-p 7442:7442
-p 7443:7443
-p 7444:7444
-p 7445:7445
-p 7446:7446
-p 7447:7447
-v /volume1/docker/unifi-video/data:/var/lib/unifi-video
-v /volume1/docker/unifi-video/videos:/var/lib/unifi-video/videos
-v /volume1/docker/unifi-video/logs:/var/log/unifi-video
--tmpfs /var/cache/unifi-video
-e TZ=Asia/Taipei
-e PUID=99
-e PGID=100
-e CREATE_TMPFS=no
-e DEBUG=1
pducharme/unifi-video-controller:beta

[fryfrog]

When updating, one would normally remove the old container. I actually run mine with the --rm option to make this more obvious. What do you mean by "reinstall"? Do you have to re-run all the unifi video setup? Or just re-run the Docker command?

[thomasjslin]

I meant reinstall is re-run the docker command. The problem would be the video won't start recording automatically if the NAS recover by UPS power. I have to re-run the docker command manually. If I don't aware the the NAS has been restart, the recording won't be start.

[thoschworks]

I have similar issues on a Linux host after reboot. I think it is something like Issue #178

I would suggest that you peek into your container (docker exec -it <container name> /bin/bash) when the failure accors and look if /var/cache/unifi-video/hls is existing.

If there is any mechanism on your platform to invoke a script at the end of the boot process you can add script which is destroying and restarting the container.

[dukekautington3rd]

I believe I have this issue as well. When my server reboots (hard or soft) my container comes up and seemingly works 100% except for recording (I use on motion only but never records until I destroy/rebuild the container). docker-compose down && docker-compose up -d and my video records again. Not sure why this happens.

Here is my compose file:

version: '3'

services:
  unifi-nvr:
    image: pducharme/unifi-video-controller:latest
    restart: always
    networks:
     vlan2:
      ipv4_address: 172.16.10.158
    environment:
      - TZ=America/Chicago
      - DEGUG=1
      - CREATE_TMPFS=no
      - PUID=99
      - PGID=100
    tmpfs:
      - /var/cache/unifi-video/hls
    cap_add:
      - SYS_ADMIN
      - DAC_READ_SEARCH
    security_opt:
      - apparmor:unconfined
    volumes:
      - config:/var/lib/unifi-video
      - /LARGE/nvr-videos:/var/lib/unifi-video/videos

networks:
  vlan2:
    external:
      name: vlan2

volumes:
  config:

[dukekautington3rd]

You're right @thoschworks. This is undoubtedly related to issue #178 even though mine is not synology.

root@hodor:~/compose/nvr# docker-compose exec unifi-nvr bash
root@5281c851b798:/# ls -l /var/cache/unifi-video/
total 4
drwx------ 2 unifi-video users 4096 Jul 26 11:59 exports
drwxr-xr-x 2 root        root    40 Jul 27 14:37 hls
root@5281c851b798:/# exit
exit
root@hodor:~/compose/nvr# **docker-compose down && docker-compose up -d**
Stopping nvr_unifi-nvr_1 ... done
Removing nvr_unifi-nvr_1 ... done
Network vlan2 is external, skipping
Creating nvr_unifi-nvr_1 ... done
root@hodor:~/compose/nvr# docker-compose exec unifi-nvr bash
root@3f4b2ae2311c:/# ls -l /var/cache/unifi-video/
total 4
drwx------ 2 unifi-video users 4096 Jul 27 15:06 exports
drwxrwxrwt 2 root        root    40 Jul 27 15:06 hls
root@3f4b2ae2311c:/#

[dukekautington3rd]

Turns out the problem was with my tmpfs line.

    tmpfs:
      - /var/cache/unifi-video/hls

Not sure why I had it this way but... This caused the hls directory to be owned by root:root and ownership mask of 777 for a fresh start with docker-compose up -d. The recordings would work in this state. However if there was an abrupt end to the container and it's restart was incited by restart: always the hls directory would still be owned by root:root but would have the mask of 755 which resulted in error messages such as Mount point for /var/cache/unifi-video/hls not found in RecordingService-EmergencyShutOffCheck and recordings not occurring. I don't know why a destroy and rebuild would result in different file permission mask vs. an abrupt restart of the container.

after changing tmpfs to

 tmpfs:
      - /var/cache/unifi-video

hard and soft restarts of the container or host result in an hls directory owned by unifi-video:users or 99:100 and recording works perfectly. Cross posting to #178

[thoschworks]

Mounting the tmpfs at /var/cache/unifi-videois and was always the recommended way. Due to the Problems in Isse #178 @fryfrog added in 0a1789a a mechanism to fix the missing var/cache/unifi-video/hls. But this is only working if the tmpfs ist mounted at var/cache/unifi-video.

I have an idea, why there is a different behavior on the (first) start and the restart of a container (it is based on my analysis of the #178), but I did not had the time to make the necessary tests.