I agree 100% on the hostnames. I am using that successfully to access some hosts transparently from home and away and it's great! I've avoided it a little with the channelsdvr mainly because the numbers may be a little easier for typing on a firetv app (shorter to type) but I think if the IP is going to potentially change, I may have to create a cname on a short DNS domain name, so I can adjust the cname if needed so my non-technical mother doesn't have to type something new into her FireTV! I guess I'm mainly curious if this is going to be a limitation of how channels implements tailscale, or if it's an issue that may eventually be fixed. Not sure if this has truly been acknowledged by the dev team, and/or if they had any comment on it yet?
It's been brought up before in this thread, and I don't recall it being acknowledged -- keep in mind this is an experimental feature, so it's on low flame.
If you really don't want to expose your host to Tailscale, you can either wait for the feature to maybe be fixed. Or, move your Channels DVR to a Docker host or VM/CT running Docker. I have mine running in a Proxmox VM with pretty much nothing else of note, and have both the Channels integrated Tailscale and host Tailscale running.
EDIT: If you decide to go the Docker route, a lot of people don't know that Tailscale works great as a container. So you could have a Docker host running just your Channels related stuff and Tailscale. Portainer highly recommended! Here's the docker-compose for Tailscale:
version: '3.9'
services:
tailscale:
image: tailscale/tailscale
container_name: tailscaled
cap_add:
- NET_ADMIN
- NET_RAW
environment:
#- TS_HOSTNAME=${TS_HOSTNAME} # Usually not necessary for your hostname to be the same name on the tailscale network
#- TS_AUTHKEY=${TS_AUTHKEY} # Generate auth keys here: https://login.tailscale.com/admin/settings/keys
#- TS_ROUTES=${TS_ROUTES} # Creates a subnet router for Tailscale. Use your subnet's CIDR in the form: 192.168.1.0/24
#- TS_ACCEPT_DNS=${TS_ACCEPT_DNS} # Set to false for Pi-hole Docker setups
- TS_SOCKET=${TS_SOCKET}
- TS_EXTRA_ARGS=${TS_EXTRA_ARGS} # Add any other supported arguments in the docker commandline style: e.g. --advertise-exit-node
- TS_STATE_DIR=${TS_STATE_DIR} # Required to create a persistent container state that will survive reboots
volumes:
- /data:/var/lib # Creates a tailscale directory under /data for persistence
- /dev/net/tun:/dev/net/tun
network_mode: host
restart: unless-stopped
Environment variables like this:
Look in the log after the first time you launch the container, and the authorization URL can be found there.
Thanks, yeah - I definitely get that it's a beta feature, I'm mentioning also because I am willing and able to help troubleshoot this if someone needs logs, but on the otherhand, if it's been looked at, and determined to be just a fact of how some of this is implemented and it isn't going to change, I'd stop mentioning it..
If a dev sees this, wants logs or some other way I can help, I'm happy to do so.
As for running it as a docker, I'm less familiar than I'd like to be with dockers themselves.. I do run some containers on my UnRaid systems, and I'm close to giving it a shot with this, but with channels being so important on the "Family acceptance factor" scale, for now I've left it as a windows VM where I'm more familiar, and if something goes wrong, I can more easily correct it due to familiarity.. I do get that there's an argument to be made that the docker is more reliable, and that's probably true.. I will get there, it's just going to take time!
Thanks for all your info and help!
This has been resolved in the latest pre-release that will be available in a few minutes. When you log out of Tailscale in Channels DVR Server, and log back in, it will use the same hostname and will also retain the same IP address.
AWESOME! This is great news!! This feature has been amazing.. Definitely available if there's anything I can do to troubleshoot or send logs for any further testing of this!!
Thanks so much!
This Tailscale support has been released as generally available. Thanks for everyone’s help!
If this happens again, please submit diagnostics as soon as you notice it and let us know here.
If you could update to the latest pre-release coming out shortly v2023.09.21.2118 and then submit diagnostics, I may be able to get more useful details about what's going on now.
This is done:
d2621746-f09b-4f40-8f30-87968bbf3d56
Let me know if you need me to send the email as well.
FWIW, when I did the update, it did cause me to need to reconnect tailscale, but as you said would happen, it did keep the same hostname this time. It only generated a new hostname twice out of maybe 10 restarts..
Thank you for the diagnostics. We have a build coming out shortly that may help — can you try out v2023.09.21.2256 and once it updates and you login, restart the DVR once more and let us know if it loads without needing to re-authenticate?
It looks like we had an issue with Windows that was preventing us from persisting the Tailscale information we needed to across restarts.
Thanks for the quick response!!
I upgraded, and it needed me to reconnect to tailscale, which I did, then I used the services control panel to restart the channels DVR service, and it needed me to re-connect again, so I dont think it worked for me. I uploaded more diags: 68b88d30-3342-4413-8cc1-01d741dbd4d0
I also tried it twice, because I thought perhaps I didn't wait long enough to let it reconnect to tailscale in the background, but even after 4 minutes now it is still not connected (I've refreshed the admin webpage several times).
Happy to run wireshark or fiddler traces, or forward logs from windows if it will help..
-Steve
One other comment - I do notice on the diags screen it tells me I dont have firewall rules in place for channels DVR but when I look at the firewall rules, they're there:
Also, regarding a DNS error about using google DNS, I dont think it's relevant here, but just for full disclosure, I'm running an active directory domain here at home, and have a very "non standard" DNS setup to say the least. If you think DNS may be an issue, I'll revert at least the channels server to something more traditional, but DNS is working for everything else..
(Long version of the story is that I have my virtual DCs setup with secondary NICs which are configured with 1.1.1.1 and 1.1.0.1 which are real public DNS servers. By advertising those routes from my domain controllers, I can let my member workstations use "1.1.1.1" as DNS and still be accessing my local active directory for proper internal name resolution, while at the same time if the DC's go down (it is an unreliable home lab afterall), the route advertisements go away, and my various hosts around the house revert to the REAL 1.1.1.1 on the internet and continue to work.)
Hello,
I have an issue with tailscale - as soon as I enable tail scale I cant even watch my playlists locally as it essentially overwrites the IP address Channels uses.. I have a TVHeadend server where I essentially manage all of my channels from different sources and pass a curated custom M3U list to Channels on a local IP address.
As soon as I enable Tailscale - it throws the following error when streaming - or modifying the playlist settings and hitting save.
Replaced IP address below with LOCAL_LAN_IP and TAILSCALE_IP
This isn't how it should work with tailscale and I dont have this issue with any other tailscale service I use.
Error message:
invalid source url: Get "http://LOCAL_LAN_IP:9981/playlist/channels.m3u": read tcp TAILSCALE_IP:46419: connection reset by peer
Version of Channels - 2023.09.21.2256 - Pre-Release Channel.
Please go to Support -> Troubleshooting -> Submit Diagnostic Logs from the web interface of the DVR and let us know when it's been submitted so we can have a better idea of what was going on.
thanks for reply Eric, logs submitted f8e153f2-d3ee-4cd8-a304-fb2f4064ee77 ill email support
It looks like there’s something funny going on with your subnet routes and how we have our Tailscale integration setup. I’m very surprised this wouldn’t Just Work. Can you confirm that other Tailscale clients that aren’t on the same network as the 10.0.0.0/8 hosts are able to reach that .40 endpoint over Tailscale?
Yep my thoughts too!
My whole tailnet is able to reach the 10.0.0.0/8 subnets.
The .40 is reachable (I’m actually away from home now, and able to hit the .40 on my phone over Tailscale.
But what I don’t understand is why is it even messing with the playlist creation/addition etc? That shouldn’t even be a problem since that’s on the LAN to the server…
That Tailscale address should just be used for listening to rather than changing the entire ip table of the container?
I also don’t understand why no one else numbed into this yet 
Because the way we’ve hooked into Tailscale with our integration is taking any IP that is exposed as a route over Tailscale and sending it over the tunnel. What should be happening is the connection should go over Tailscale to the tunnel to the subnet router and then to the destination (because we don’t have an easy way to identify what is local and what isn’t).
We currently tunnel anything that is exposed over Tailscale via Tailscale, but it may make sense to only try to connect to IPs in the main Tailscale netblock over Tailscale.
I’m guessing there aren’t a lot of folks that have enabled the subnet routing on Tailscale…
I’ll see about adjusting the logic when I get a chance…
Thanks for the responses Eric much appreciated, I’ve got an alternative work around at the moment but glad it’s just not me going crazy and doing something dumb!
Let me know if I can be of help to test this when you guys get around to it, happy to help.
Looks like the Windows issue with reconnecting is a bug in Tailscale that we will need to figure out how to fix or work around.