I wrote a helper script and made it executable on boot up that emails me when channels cant find a file. it parses the channels log. Its kind of a hack, but at least its a strategy to have a soft landing for these kinds of issues.
Happy to share!
Do you have any advice for us users regarding MACOS26? Im going to hold off until the dust settles, but Im interested if you have any insight.
In my case, with a separate removable disk volume dedicated to the DVR, it appears that the new executable needs to be authorized to access "Files & Folders" or "Full Disk Access" (System Settings > Privacy & Security). This seems to be the case after an automatic update even though the new executable winds up in the same place the previous one did: ~Library > Application Support > ChannelsDVR > latest. I guess MacOS keeps track of the actual executable file that was allowed access and knows the new one is different though it has the same filename & location.
I get flashbacks
Isn't latest a directory symlink pointing to the new version directory?
i.e. ~Library > Application Support > ChannelsDVR > latest
points to ~Library > Application Support > ChannelsDVR > 2025.08.24.0217
And the directory the symlink points to changes with each update.
It is on Linux.
I'm running the server on MacOS and "latest" appears to be an actual folder. The previous versions all appeared in their own folders with the date/time naming convention you mentioned. I moved all those just to be sure and restarted the server without any issues.
Run this command in Terminal and it will show that latest is a symbolic directory link
ls -l ~Library/Application\ Support/ChannelsDVR/latest
Looks like this in Linux
$ ls -l /volume1/docker/channels-dvr-8089
total 28
drwxrwxrwx+ 2 root root 4096 Aug 11 18:55 2025.08.09.2304
drwxrwxrwx+ 2 root root 4096 Aug 14 14:07 2025.08.14.0637
drwxrwxrwx+ 2 root root 4096 Aug 16 08:54 2025.08.15.1429
drwxrwxrwx+ 2 root root 4096 Aug 19 11:56 2025.08.19.0525
drwxrwxrwx+ 2 root root 4096 Aug 20 18:51 2025.08.21.0013
drwxrwxrwx+ 2 root root 4096 Aug 23 11:19 2025.08.21.1637
drwxrwxrwx+ 9 root root 4096 Aug 17 09:40 data
lrwxrwxrwx+ 1 root root 15 Aug 23 11:19 latest -> 2025.08.21.1637
$ ls -l /volume1/docker/channels-dvr-8089/latest
lrwxrwxrwx+ 1 root root 15 Aug 23 11:19 /volume1/docker/channels-dvr-8089/latest -> 2025.08.21.1637
The executables are cryptographically signed and the details can be viewed via
$ sqlite3 "$HOME/Library/Application Support/com.apple.TCC/TCC.db"
after granting full disk access to Terminal
$ sqlite3 --box "$HOME/Library/Application Support/com.apple.TCC/TCC.db" 'select * from access where client like "%iterm2%"'
│ service │ client │ client_type │ auth_value │ auth_reason │ auth_version │ csreq │ policy_id │ indirect_object_identifier_type │ indirect_object_identifier │ indirect_object_code_identity │ flags │ last_modified │ pid │ pid_version │ boot_uuid │ last_reminded │
├────────────────────────────────────────┼───────────────────────┼─────────────┼────────────┼─────────────┼──────────────┼───────┼───────────┼─────────────────────────────────┼────────────────────────────┼───────────────────────────────┼───────┼───────────────┼─────┼─────────────┼───────────┼───────────────┤
│ kTCCServiceSystemPolicyDownloadsFolder │ com.googlecode.iterm2 │ 0 │ 2 │ 2 │ 1 │ �� │ │ │ UNUSED │ │ 0 │ 1744937330 │ │ │ UNUSED │ 0 │
│ kTCCServiceSystemPolicyDocumentsFolder │ com.googlecode.iterm2 │ 0 │ 2 │ 2 │ 1 │ �� │ │ │ UNUSED │ │ 0 │ 1754199221 │ │ │ UNUSED │ 0 │
└────────────────────────────────────────┴───────────────────────┴─────────────┴────────────┴─────────────┴──────────────┴───────┴───────────┴─────────────────────────────────┴────────────────────────────┴───────────────────────────────┴───────┴───────────────┴─────┴─────────────┴───────────┴───────────────┘```That’s a good idea, I’d love to take a look.
@bnhf, is this something that OliveTin could help with?
I would think so. The E-Mail Log Alerts Action already does this. It's just a question of having the right pattern or patterns to search for:
Here is one pattern for people to try if interested. You may find some false positives though, where an email is sent but channels recovered gracefully after a retry
tail -F "$LOGFILE" |
grep --line-buffered "no such file or directory" |
@Fofer So in olive tin, you could try experimenting with the term "no such file or directory" as a search term
I haven't tried the cool email feature in olive tin yet.
Ah, thanks for that. Any idea what the error log would say when channels-dvr can't "find devices on local networks?" I'll keep an eye out on my system, certainly the next time this happens.
I don’t recall parsing the logs and seeing that specific term. The best I could do at the time that I set my email notification script up was to indirectly infer that the drive became unmounted or unavailable by the no such file or directory term.
The drawback is that there can be falls positives if for instance you move some of your personal media around or even rename you personal local media that you had previously imported into channels.
Let’s keep refining these search terms and scripts.
Now that I know that these pop ups are occurring during point updates of macOS I’ll try and take another look at the logs next time I get the pop ups and look for more specific error patterns for my custom scripts and for olivetin.
I’m in the middle of some code development at the moment. Once that is stable I’ll do another MacOs point release and I’m pretty sure I’ll see the pops again
Shouldn't CDVR report its status via some endpoint like /health ? This would make monitoring easy.
I posted a question to the forum some time ago asking if there was any benefit to moving from MacOS 14 to 15 on my M1 Mac mini DVR server. Most of the responses were "scolds" for not mindlessly upgrading with zero reasoning put forth. It appears there IS a benefit to not using MacOS 15 for your server OS at this point.
Nope, apparently not a sym link on MacOS.
Try
ls -l ~Library/Application\ Support/ChannelsDVR
does it show as a link
lrwxrwxrwx+ 1 root root 15 Aug 23 11:19 latest -> 2025.08.21.1637
^
l means link, d would be directory
Also try stat ~Library/Application\ Support/ChannelsDVR/latest
stat /volume1/docker/channels-dvr-8089/latest
File: /volume1/docker/channels-dvr-8089/latest -> 2025.08.28.2100
Size: 15 Blocks: 0 IO Block: 4096 symbolic link
Device: f901h/63745d Inode: 104628268 Links: 1
Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2025-08-29 21:04:21.635446359 -0700
Modify: 2025-08-28 20:06:07.790632961 -0700
Change: 2025-08-28 20:06:07.790632961 -0700
Birth: -
Sounds like the dot releases may also affect the network privacy settings
Nope, on MacOS it's a directory
ls -l ~/Library/Application\ Support/ChannelsDVR
total 16
drwxr-xr-x@ 23 doug staff 736 Aug 31 07:32 data
-rwxr-xr-x@ 1 doug staff 2840 Dec 16 2024 install.sh
drwxr-xr-x@ 9 doug staff 288 Aug 24 13:56 latest
-rwxr-xr-x@ 1 doug staff 774 Dec 16 2024 uninstall.sh
Well, here's some good news. I've updated quite a few pre-releases of CDVR server since I started this thread, and also a few point releases of macOS Sequoia on this Mac mini, and I have NOT encountered these two Privacy & Security pop-ups again. There were pretty frequent a few months back, very noticeable, and at least twice, it proved to be a literal showstopper. And now, I'm not seeing them at all, despite doing manual updates regularly and sometimes remotely, just as before.
I even upgraded my Mac mini to macOS 26 Tahoe, then to 26.0.1, and the Channels DVR server is still launching automatically without any additional or unexpected pop-ups after restarts or reboots. So I think that was just an unfortunate bug with some earlier versions of Sequoia, an aberration perhaps? Fingers crossed that it's a thing of the past!
Felt like the tables had turned for awhile:
I still havent forgot about this issue. Im still holding off on upgrading to MACOS 26 , but will definitely report back my results as well once I do. Hopefully these pop ups from updates have been taken care of!
Thanks for the update - it’s encouraging.