i was struggling to get docker to work on synology and i found for some reason it wouldnt accept my custom ports.
switched off the current package running and then boom on 8089 its running and logging in with yttv credentials.
So now i need to fix it from my test folders to use the storage volume i had on the original install
did you just restore from the backup file? or point to all the same directories ?
I used the same /volume1/ChannelsDVR directory that the native app created and used. As I stepped through setup it had me select a specific directory in the mount at /shares/dvr. Setup had me select a backup of the library database to restore and it was easy to find the backup made minutes earlier.
i use a external drive, its weird the docker instance cant get to usb.
but i dont have any special restrictions....time to spend more hours toying with synology's docker
Up to Synology DSM 6, the usb drivers were included in the kernel but then on 7+ Synology removed usb support.
ah , the native channels app accessed by drive just fine.
never messed with docker on synology since i have a different system where my docker stuff goes
With Docker, you have to map the Synology host direcories into the docker container in order for Channels DVR running in the docker container to see them.
When I played with using a USB drive in this post, it was accessed on the Synology at /volumeUSB1/usbshare
So you would need to map the Synology USB drive directory to the docker container /shares/dvr directory
--volume /volumeUSB1/usbshare:/shares/dvr
And then select the /shares/dvr directory from Channels setup (running in a container)
yup i did that still wouldnt show, but i tried mapping the volume of the usb to a different container mapping and bam got usb drive.
going through the synology gui took way longer than if i had just installed portainer or used cli
What, exactly does that mean?
so lets say i had it mapped /volume1/usb1:/share/dvr
that wasnt seeing the usb, but passing it as /volume1/usb1:/usb1 i was then able to reach all my recordings and backups.
OK, most likely you typo'd something on your first attempt, or had capitalization wrong (linux is case sensitive)
There is no difference in those two mappings, other than the Synology directory /volume1/usb1 appearing inside the docker container at /share/dvr in the first one (I use /shares/dvr) and /usb1 in the second
Any one find a fix for this?
Does anyone have a guess why using Docker Google would see the Browser as Secure and think it is not Secure when not using Docker?
Another workaround. I have a second Synology NAS running a LINUX VM (pop-os). I installed Channels DVR on that LINUX VM with Google Chrome (google account) logged in. And YouTube TV worked. I then Logged out of Google Account and Channels Continued to work. I then rebooted Synology with the Linux VM set to autostart and Channels continue to work on restart with Google Account still not logged in.
What version of Chrome is reported when you use docker?
Someone else here reported they are using docker. I am not.
Docker version 2023.12.06.1555
Chrome version 117.0.5938.62
Running on Synology SAN
If you are running a NAS on an x86_64 processor and are running into the "may not be secure" error with YouTube TV, you can test something out by doing the following:
curl -XPUT 'http://<dvr-ip>:8089/dvr/hacks/tve.chromium_tag/116.0.5845.14'
Once you are done testing, you can get back to the standard install by running:
curl -XDELETE 'http://<dvr-ip>:8089/dvr/hacks/tve.chromium_tag'Some time ago I contacted CDVR support and asked about switching from Synology native to Docker. I was told both were the same binary. Perhaps that was true then, but it doesn't seem to be true now.
I am not OP, but I tried this and it did not work for me. I submitted diags ( fd05a3cc-7742-4d70-8e75-bbdad84745bc)
It would be great if I could get past the YTTV not secure error.
@camman595 Have you tried the route of running the DVR in Docker?
We are reaching the end of the line for potential solutions for this. We don't know exactly why Google is blocking the connections from Linux NAS-based systems. It isn't clear what the circumstances that make it not work for some people and work for others are. A lot of people have tried a lot of things, and a lot of times people will pass on secondary information that muddies the water of what has been tried and what has been successful.