Synology DSM 7.0 and CHANNELS DVR

Synology is releasing a major upgrade (DSM 7.0) on Tue Jun 29.
Has this new release been veted and approved on the latest release of CHANNNELS?

I see back on Feb 4th some CHANNELS / SYNOLOGY users were having issues with the DSM 7.0 beta release ;
"I wasn't paying attention and didn't realize they (synology) block all 3rd party packages."

Let me know

1 Like

As you probably know, you don't have to update to DSM 7.0 yet, but in preparation for that...

I just today moved Channels DVR server from the Synology package to running in a Docker container on both of my Synology NAS's.

Easy enough to do and it kept my settings, directories, shows and passes intact.
On my newer one (DS1019+) it's able to use hardware transcoding inside the tve docker container.

It has not been tested on 7.0 yet I don’t believe. If you run it natively (as I do), I would recommend not upgrading until the Devs give the green light.

Are you able share the approach?

In general (and as previously stated by the developers) Channels DVR is not tested on beta software. Once a stable release has been made generally available they (may) test their software against the new release. In short, don't expect official support for beta or just-released OSes/platforms.

On a side note: Docker/Podman support is good, and if your platform supports either container platform, that would probably be both a better direction going forward, and more likely to get official support.

Sorry wasn’t clear. I was interested in the approach to migrate to docker retaining recordings etc

If you are already using Docker to containerize your DVR, you shouldn't experience any difference. The only issues are those related to bare metal installations on DSM, primarily related to permissions.

Sure, you may have to adjust the following in my example based on your install.

IP address '192.16.1.4'
Synology directory Channels DVR records to '/volume1/arkives/ChannelsDVR'
Synology directory for Channels DVR docker program '/volume1/docker/channels-dvr'
Time Zone 'TZ=America/Los_Angeles'

I was using the Channels DVR Synology package on my DS1019+ running DSM DSM 6.2.4-25556
I access this Synology through its LAN1 port at IP address 192.168.1.4
I had it recording to /volume1/arkives/ChannelsDVR (/volume1/arkives is a Synology Shared Folder)
Did a DVR Database Save Database Backup in Channels (and noted the time I did that)
Stopped the Channels DVR Synology package
Installed and ran the latest Synology Docker package
Created the directory /volume1/docker/channels-dvr for the new Channels Docker Container to use
SSH into my Synology and issued the docker run command

docker run --detach --name=channels-dvr-tve --env TZ=America/Los_Angeles --network=host -p 192.168.1.4:8089:8089/tcp --restart=on-failure:10 --device /dev/dri:/dev/dri --volume /volume1/docker/channels-dvr:/channels-dvr --volume /volume1/arkives/ChannelsDVR:/shares/DVR fancybits/channels-dvr:tve

Breakdown of that command for easier viewing

docker run
--detach
--name=channels-dvr-tve
--env TZ=America/Los_Angeles
--network=host -p 192.168.1.4:8089:8089/tcp
--restart=on-failure:10
--device /dev/dri:/dev/dri
--volume /volume1/docker/channels-dvr:/channels-dvr
--volume /volume1/arkives/ChannelsDVR:/shares/DVR
fancybits/channels-dvr:tve

Once it's running
configure it at http://192.168.1.4:8089/welcome by restoring from the backup you made
set it to use /shares/DVR for its DVR storage path

Updated in case someone was actually using this...

When you restore your backup, you have to use the directory picker as Channels DVR sees the directories from inside the Docker Container, so in my example my backups as seen from Channels DVR running in the Docker Container are in /shares/DVR/Database which equates to the Synology directory /volume1/arkives/ChannelsDVR/Database

Also to note that I set the Synology Docker package to not autoupdate.
When I want to update it, I stop all Docker Containers, stop the Synology Docker package, update the Synology Docker package, then start my Docker Containers. Otherwise have fun with the errors.

Since a new install like this only grabs the latest released version of Channles DVR, I would recommend updating to the latest pre-release version of Channels DVR if you're using a TVE, Locast or m3u source.

2 Likes

Or the Channels devs could fix their package to stop running with elevated privileges. Linux package creators/maintainers the world over do it day in, day out. It's really not that difficult.

What's happening is Synology is finally enforcing upon developers what they should have been doing all along.

When I was using our main network server to evaluate Channels DVR I took one look at the install and said to myself "Hell no!" Shut it down and fixed it. Was simply a case of creating a "channels" user and group, changing all the file and directory ownerships to "channels:channels", and running the channels dvr stuff as suid:sgid channels:channels.

I think it took me all of about an hour to track it all down and make the necessary changes.

I never did that on our NAS because 1. I'm not running anything sensitive on there, anyway and 2. Package updates would break my manual fixes and I'd have to keep re-applying them.

I guess if the Channels devs aren't going to fix their package I'll just never update DSM as I'm disinclined to deal with Docker--particularly to fix something that shouldn't be so egregiously broken in the first place. (Yes: As a retired systems & network admin this annoys the living hell out of me.)

Have you ever tried to create a package for Synology DSM? The process is overly difficult, incredibly counter-intuitive, and an overall PITA. Add to the fact that Synology uses their own separate user/group management and ACLs paired with out-of-date kernels, and you have a packaging nightmare.

While there exist some third-party tools that assist in packaging—the SynoCommunity group has created their own toolchain, which supports non-root users both in the system and UI—they are still a hassle to use.

A standard cross-platform means to deliver Channels makes the most sense to pursue going forward.

Except Docker and similar packages have not been without their own security and vulnerability issues. So now users are expected to deploy a broken package to support an inherently broken package?

Shades of MS-Windows

No thanks. I'll just continue to run it as-is and continue to treat our NAS as an untrusted device.

(In our case I'm not certain it's all that big a deal, anyway. We're only using the NAS for Channels and Synology Surveillance Station. The latter, along with it's client apps, are thoroughly broken products I plan to replace, anyway. And I don't know how much longer we'll need the Channels DVR.)

True, but "Docker" isn't necessarily "Docker". What everyone calls a "Docker container" is actually an OCI container, which can be used with many different runtimes, not just Docker.

Personally, I prefer Podman, which can run both daemon-less and root-less, and does not require the insecure kernel-hooks that Docker does. But that is only one alternative; others exist as well, such as kata.

@racameron, we're clearly not going to come to an agreement on this point. As an ex-software developer, myself (both in a professional capacity and as a team member or contributor for various open source projects through the years), and as an ex-systems and network admin, my feeling has always been "simpler is better."

Stacking software atop software, design/code it poorly and apply band aids, is the MS-Windows universe way of "fixing" flaws, which is one reason I've never used it. (Nowhere is this more evident than the raft of products end-users are urged to install and maintain to mitigate against MS-Windows' and MS-Windows' apps' legions of flaws and vulnerabilities. We all know how well that's worked out.) ​

I'm simply not going there. I certainly wouldn't be going there on our primary network server, which is where Channels temporarily ran.

Let me clarify a point: The Channels products are, overall, pretty darn nice and Channels' devs are, overall, pretty darn helpful and responsive. (Particularly as compared to some other devs whose names shall go unmentioned to protect the guilty :wink: ) It is only this one flaw to which I take exception.

1 Like

I too have the itch to update to DSM7....but I don't use Channels in Docker yet. I could always switch it back over to my Mac Mini until the support is there. But I too would like to see native support.

I've successfully installed ChannelsDVR in docker so I guess I'm one step closer to being able to use DSM7. I just can't figure out how to change the user that it runs as. I want to have it run as channels ID and not root.

Check out the --user/-u option:

I'm trying to figure out where to do that from the Synology GUI. I can't find the run command from the container

Their UI probably doesn't expose all options, only the most common. You probably need to SSH into your NAS and create your container from the command line.

Ah ok that makes sense. Just need to figure out how.

How necessary is it since I’m in a docket container?

If you have it running in a Docker Container, you don't have to worry about that. It can run as root in the container, but that's not the same root user as your Synology. It's root in its own Linux OS inside the container which Docker isolates from the Host Synology OS.

1 Like