Will it work if you set up a custom source with hls and url with this as the url
http://2.2.2.2:8089/devices/ANY/channels.m3u?bitrate=3000You may need to follow these additional steps on your Synology to get Tailscale to fully work:
The latest DVR pre-release now will support connecting two DVRs over the integrated Tailscale support without needing to install it on the OS.
Thanks for reporting this.
1 Like
Doesn't seem to matter for me which method is used, is the any benefit for omitting the port?
@eric
I've been testing using TailScale rather than using a session cookie and seem to have some amazing results. Rather than using HLS, I am able to use direct TS over WAN (~40ms latency) without issue. The individual channels are output in this format...
http://X.X.X.X/devices/ANY/channels/XX/stream.mpg?codec=copy&format=ts
There is no transcoder activity on the sender side and the channels start much quicker. Is TailScale just that much better at routing?
Also, is "codec=copy" needed or can I omit that and only specify "fortmat=ts"
Are you using URL as source or text? I've tried both and using your below code (obviously adjuting for my remote server IP and the correct channel number) and I get the following error. Usually I'm overlooking something obvious as I only understand about 20% of the code in these things.
I am able to use it with the transcoding, but as you pointed out, takes a while to load and I don't want to overtax the remote server as it's a entry level synology NAS (j series I beleive).
You can omit both. The stream.mpg endpoint is the raw TS that Channels uses. Both codec=copy and format=ts are redundant and superfluous.
The only downside of this is any TCP packets that get dropped will cause the stream to stall for much longer than using HLS which will retry the connection internally overcoming the TCP back off algorithm.
1 Like
May have changed with the latest prerelease (haven't tried), but it didn't work previously if you tried to specify the port# when connecting to a Channels DVR server with its built-in tailscale enabled. I have 4 servers, in 4 docker containers, using 4 different ports.
Nice, so if I have a work DVR in one location and a home DVR in another, I can turn on Tailscale on both DVR’s, and be able to access the work’s OTA channels at home? I’d just need to turn on Tailscale on my clients too? But what about the (mobile) work clients, if they are only accessing the channels from the work DVR, will they need Tailscale enabled too?
Just curious before diving in, trying to understand any caveats ahead of time. What a cool feature!
Tailscale is fantastic. When you dive in I recommend using both the integrated version in the channels clients (which will assign tailscale ip addresses to them) as well as using the stand alone app on your devices if possible (which will assign them a second tailscale ip address). There is no tailscale app for the apple TV for now, so you will have to use the built in support. Apple is planning on building the vpn support into the apple tv in TVOS17, and tailscale will hopefully release an app for the apple tv soo after that.
The stand alone app method has some advantages over the built in tailscale support with the way the guide loads remote channels and remembers your last used connections.
Yes i think so. I havent tested this.
If your work DVR is behind a cgnat, you will need tailscale. Whenever you use tailscale you connect to the DVR using “At Home”. If you are on the road, you could get into the second DVR by connecting to it using the Away From Home feature if the dvr port is exposed. But you will need to check with the developers to see if there is a restriction for how many “away from home” dvrs can be alive at once. Im not sure. I only use tailscale because in my case all my DVRs are behind cgnats.
1 Like
No, in the best case Tailscale will give you the same situation you had going directly (just without having to worry about ports and authentication) but in the worst case, could have to go through a relay node that gives you worse performance. There's nothing magical about Tailscale that would make it better than going directly in regards to performance.
If we're talking specifically about using these m3u's to export channels from one DVR to another, your clients do not need to have any sort of Tailscale enabled to be able to play the channels that are exported. They just need to connect to the DVR they're connected to and all traffic is sent through the connected DVR.
Using the native Tailscale integration that your OS has on your client will give you a better experience if it is available (the discovery situation you mentioned). Our integration on the client is purely there for the cases like tvOS where it is not yet possible (as you mentioned).
Considerings how good TCP BBR is do you think it is worth it to use HLS and have the longer remux wait time? I haven't scientifically measured the difference but it seems quicker to load.
You can search for my post on the M3U Export Documentation. Here is the text format I have...
#EXTM3U
#EXTINF:-1 channel-id="NAME" tvg-id="125" tvg-chno="125" tvg-logo="https://tmsimg.fancybits.co/assets/s91096_ll_h15_ae.png?w=360&h=270" tvc-guide-stationid="91096" tvg-name="NEWSNTN" group-title="HD",NEWS NATION HD
http://x.x.x.x/devices/ANY/channels/68/stream.mpg?format=ts
Honestly I think it's going to be the sort of thing where after a year of running it this way you'll have an idea of how many times you ran into issues with the stream stalling and never recovering or had interrupted recordings.
The way the direct MPEG-TS TCP stream works is a single uninterrupted TCP connection. With HLS, it's making new HTTP requests for each segment as well as retrying the connection, so if there were 2-5 seconds of packet loss, the HLS stream would recover from it much more quickly than the single TCP connection would.
As a reminder, there are no arguments required for the stream.mpg (that ?format=ts isn't needed and doesn't do anything).
In this scenario, how do the two servers operate? Is there a buffer on each server?
To answer my own question, there is a buffer on each server. Also it works pretty well.
or after 9 months
1 Like
This isn't the scenario he was referring to, and there is no reason to believe this is related to the MPEG-TS stream. @eric and I were discussing the differences of using HLS and TS over a WAN connection (specifically with TailScale) were HLS has multiple advantages.
The discussion you are quoting is in reference to using MPEG-TS between two DVR instances on the same LAN (actually two containers on the same machine). In this case I don't see any reason why HLS would be advantageous unless there are issues with how the TS segments are being written.
Additionally, one of the only channels I use over WAN/TailScale is for baseball games that last ~3hrs, and looking at the last 10 recordings I have no interruptions when using MPEG-TS. I assume Eric is on the right track with TVE commercials affecting the segments for my local MPEGTS streams and causing the timeout.
1 Like