Open thomasjslin opened 4 years ago
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
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?
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.
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.
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:
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:/#
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
Mounting the tmpfs at /var/cache/unifi-video
is 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.
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