Certainly looks stuck, but unclear why. I was afraid something like this could happen (or someone could have the ntp servers blocked on their firewall), which is why I started building out the UI for it. In older versions the DVR server would never start until time sync was achieved.
Maybe check find /run/systemd/timesync -ls
Then try systemctl restart systemd-timesyncd and see if that makes systemctl list-jobs list go away and get things started up.
22059 0 drwxr-xr-x 2 systemd-timesync systemd-timesync 40 Nov 4 18:26 /run/systemd/timesync
tried a dvr restart after restarting the daemon, no luck - same state - hanging on ntp sync
Hmm very strange. This part hasn't changed at all.
Would time.cloudflare.com be blocked for some reason?
Here's what I see after restart:
# systemctl status systemd-timesyncd
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/systemd-timesyncd.service.d
└─hassos.conf, ro.conf
Active: active (running) since Thu 2020-11-05 00:34:28 UTC; 4s ago
Docs: man:systemd-timesyncd.service(8)
Main PID: 587 (systemd-timesyn)
Status: "Initial synchronization to time server 162.159.200.1:123 (time.cloudflare.com)."
Tasks: 2 (limit: 2086)
Memory: 1.0M
CGroup: /system.slice/systemd-timesyncd.service
└─587 /usr/lib/systemd/systemd-timesyncd
Nov 05 00:34:28 dvr-server systemd[1]: Starting Network Time Synchronization...
Nov 05 00:34:28 dvr-server systemd[1]: Started Network Time Synchronization.
Nov 05 00:34:28 dvr-server systemd-timesyncd[587]: Initial synchronization to time server 162.159.200.1:123 (time.cloudflare.com).
Looks ok-ish to me:
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/systemd-timesyncd.service.d
└─hassos.conf, ro.conf
Active: active (running) since Wed 2020-11-04 18:26:00 EST; 10min ago
Docs: man:systemd-timesyncd.service(8)
Main PID: 1284 (systemd-timesyn)
Status: "Idle."
Tasks: 2 (limit: 4425)
Memory: 1.0M
CGroup: /system.slice/systemd-timesyncd.service
└─1284 /usr/lib/systemd/systemd-timesyncd
Nov 04 18:26:00 dvr-server systemd[1]: Starting Network Time Synchronization...
Nov 04 18:26:00 dvr-server systemd[1]: Started Network Time Synchronization.
Wed Nov 4 19:38:39 EST 2020
Maybe its so close its not kicking in the fix? Try these:
timedatectl status
timedatectl timesync-status
Local time: Wed 2020-11-04 19:40:52 EST
Universal time: Thu 2020-11-05 00:40:52 UTC
RTC time: n/a
Time zone: Etc/UTC (EST, -0500)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
Server: 162.159.200.123 (time.cloudflare.com)
Poll interval: 2min 8s (min: 32s; max 34min 8s)
Leap: normal
Version: 4
Stratum: 3
Reference: A100F63
Precision: 1us (-25)
Root distance: 11.893ms (max: 5s)
Offset: -297us
Delay: 20.709ms
Jitter: 491us
Packet count: 3
Frequency: -1.161ppm
Thinking maybe this is a red herring - it looks like ntp sort of finished, but DVR in same state (gui still waiting for ntp)
2020/11/04 18:22:38.917725 [SYS] Starting Channels DVR v2020.11.04.2258 (linux-arm64 pid:305) in /mnt/data/channels-dvr/data
2020/11/04 18:22:39.047175 [SYS] Started HTTP Server
2020/11/04 18:22:39.063123 [SYS] Waiting on dependencies network-online.target time-sync.target
2020/11/04 18:22:51.693717 [SYS] Waiting on dependencies time-sync.target
2020/11/04 18:29:21.008803 [SYS] Starting Channels DVR v2020.11.04.2258 (linux-arm64 pid:2109) in /mnt/data/channels-dvr/data
2020/11/04 18:29:21.017333 [SYS] Started HTTP Server
2020/11/04 18:29:21.037078 [SYS] Waiting on dependencies time-sync.target
2020/11/04 19:38:12.814762 [SYS] Done waiting on dependencies
2020/11/04 19:38:13.460796 [HDR] Found 3 devices
submited 87589182-3157-4bcd-97a0-bc8b6858d64e .
Can you submit diagnostics again
ha - great minds - just did 
Thanks. What does lslocks show
COMMAND PID TYPE SIZE MODE M START END PATH
wsdd2 321 FLOCK WRITE 0 0 0 /etc/machine-id...
winbindd 506 POSIX 21B WRITE 0 0 0 /run/lock/samba/msg.lock/506
channels-dvr 2109 FLOCK 64K WRITE 0 0 0 /mnt/data/channels-dvr/data/X-TVE.groups/store/root.bolt
winbindd 486 POSIX 12K READ 0 4 4 /run/lock/samba/names.tdb
winbindd 486 POSIX 8.7K READ 0 4 4 /var/lib/samba/private/netlogon_creds_cli.tdb
winbindd 486 POSIX 4B WRITE 0 0 0 /run/samba/winbindd.pid
winbindd 486 POSIX 20B WRITE 0 0 0 /run/lock/samba/msg.lock/486
winbindd 486 POSIX 1.3K READ 0 4 4 /var/log/samba/log.winbindd
channels-dvr 2109 FLOCK 64K WRITE 0 0 0 /mnt/data/channels-dvr/data/USA-CT56421-X.groups/store/root.bolt
channels-dvr 2109 FLOCK 64K WRITE 0 0 0 /mnt/data/channels-dvr/data/X-TVE.airings/store/root.bolt
channels-dvr 2109 FLOCK 1.2M WRITE 0 0 0 /mnt/data/channels-dvr/data/settings.db
channels-dvr 2109 FLOCK 1.7M WRITE 0 0 0 /mnt/data/channels-dvr/data/recorder.db
channels-dvr 2109 FLOCK 128K WRITE 0 0 0 /mnt/data/channels-dvr/data/USA-CT56421-X.airings/store/root.bolt
Okay go ahead and systemctl reboot. I think that will fix it. There's some weird state the DVR got stuck in where a lock wasn't released. I have the logs to look into it more.
phew. back up and running. Thanks!
Share still fails on reboot. Light solid green now. Sent logs.
I think the fix only kicked in after recreating share with this version, so if you reboot again it should mount cleanly. I hope so anyway.
No still have to recreate share after each reboot i tried 3 times. This is not a big issue for me I have to only 1 share to recreate after rebooting all imports are in sub directories under that. And hopefully the idea of a stand alone dvr server is not having to reboot all the time. Thanks again.
Can you try OS 2020.1105.1714 (requires click and hold) to see if the shares work after reboot.
I'll add a reconnect button next so atleast you don't have to remove/readd
Did the click and hold as usual shows up to date at os 2020.1104.2314 and software 2020.1105.0135. Did another reboot with same result so I sent logs.
Okay I'm fairly confident the share mounting is fixed in OS 2020.1105.2116
It will now correctly wait for the network to come up before mounting, but then also is set up to automount on access attempts in case there is a network disconnect or other issue the first time.
On the reboot to update, the share restored fine. Then I rebooted 2 more times both times the share failed to restore on reboot and I had to set back up. Sending logs.