@mnwxman132 Please try the latest Testflight build and see if it behaves better for you.
Hi @eric
I updated to the latest testflight beta on both my ipad and apple tv.
On the ipad, things seem to be working much better. The new discovery system remembers the tailscale address after closing with the app switcher. It even remembered to use the tailscale address after an ipad power cycle.
On the apple tv, on the first load I did notice the connection seemed much snappier so something has shifted. However, after i exited the app by hitting the apple home button, and going back into the app, I noticed a “loading” spinning wheel for a few moments, but then the channels app went back to the local server at 192.168.1.2.
When I tried to connect to the second server, I get an error message “Channels DVR Server was not found at 100.x.x.88”
If i use the app switcher and close the app i get the usual “preparing tv” and then if I go into settings I can connect “At Home” to the built in tailscale server at 100.x.x.88. However, the guide does not always reflect the guide from the remote server.
I also did notice that I can bypass having to use the app switcher and closing the app in order to connect to the built in tailscale server when i get the error message. I can accomplish this by toggling the built in tailscale service in the debug menu.
I submitted another diagnostic dump from my apple tv after the app jumped back to using the local server at 192.168.1.2. In this case I had exited the app by using the home button while it was connected to the secondary tailscale server at 100.x.x.88
Please let me know if there is anything else i can do to lend a hand.
edit: the ipad seems to be more robust, however i just observed similar behavior with the app loading the wrong server after a period of idle time, and then the error message connecting to the tailscale server.
Ah this is interesting. Maybe something funny is going on related to this idle situation. I’ll try to replicate this and see what I can dig up as well as checking out your logs.
Another piece of info @eric
Im running another experiment on ipados with tailscale.
Ive got my secondary channels dvr on a media server box that has its own tailscale address.
Somfar, when I disable the built in channels tailscale support, and manually enable my tailscale connection using the ipados tailscale app, channels DVR behaves much more stable.
The guid loads quicker and so far i havent seen any strange guide refresh issues either, not idle time drop of the server.
Im going to leave my tailscale connected for an extended period with channels idling on my ipad, and report back later today if the connection “sticks” like it should.
I suspect there is either a race condition using the built in tailscale support, or even a dropout of the tailscale connection when channels isnt doing anything.
Of course, for now until TVOS 17 comes out with vpn support and hopefully tailscale along with it, we have to use the built in tailscale support for the apple tv, but hopefully the ipad testing can lead to more insight for the apple tv software.
Edit: This has been pretty stable for hours. As long as I dont use the built in tailscale integration…
Yes, using the native iOS support for Tailscale will be much more reliable than our internal support. I would definitely suggest using that for an iPhone/iPad and only use our Tailscale integration for the Apple TV.
I'm still working on improving the internal integration and will let you know when there's an updated build.
Let me know if this build is any better for you.
Thank you @eric
So far , this is much much more stable!
Ive been playing around on the apple tv so far.
I can close the app with app switcher and it “remembers” the previous connection. I played around with my transcode settings on the remote server and closed and opened the client a ton of times and it always jumps back to the correct guide. Before I couldnt do this at all without losing the connection to the secondary server.
Ive seen a couple of times a “loading” message, and the client does bump back to the local dvr server.
Ill keep testing and see if I can find a repeatable pattern to make that particular case happen. I havent tested on the ipad yet. Its been all on the apple tv which is leagues better than previous builds.
ive confirmed that on ipados after idle time the app still looses the connection to the secondary tailscale server.
I sent a diagnostic from the Ipad after opening the app and observing it jump back to the local ip address at 192.168.1.2
Ill continue testing on the apple tv and look for issues after a long idle there.
Like on the apple tv, the connection process is much improved as the guide is behaving much better
Can you see if you have any better experience with this one?
This one was worse. After relatively short idle with tailscale server connected, when I opened the ipados app i got a very long spinning wheel. When the app finally opened, it had the wrong guide (my channels collections were from the tailscale server, but the rest of the guide was from the primary server)
The discovery mechanism had switched back to the local server.
Overnight. Observed long delays upon start up of both apple tv and ipados.
Last version seems more stable amd much snappier response. More usable, so for now Im switching back to the previous build unless you need more debugging, etc.
let me know.
I also submitted diags from apple tv after crash with latest testflight.
Got the crash on apple TV to occur by:
1: go into channels and select secondary tailscale server at 100.x.x.88
2: observe everything looks ok. Guide perfect
3: leave app and go into netflix and stream a show.
4: close netflix
5: go back into channels
6: observed long spinning wheel, the crash out of app. Upon next opening of app, back to local server at 192.168.1.2
7: submitted diags from this point
I was able to track down this crash. It's related to the new discovery mechanism but unrelated to the Tailscale stuff itself.
Regarding the latest build vs the previous one, there was no change in how the system behaved during initial startup, only how it behaved when coming back from the background.
There's not anything we can do at the moment to speed up the time it takes for Tailscale to reconnect — it's doing what it does and sometimes it's fast, sometimes it's slow.
I think we may have reached the end of what we can achieve with this integration (which is a lot better than it was a week ago), but in the end the tvOS 17 support for VPNs will be a lot better solution when it comes out and it supported natively by Tailscale.
One thing I did notice when i went to my tailscale admin panel, is the apple tv and ipad channels integrations are behind in revision levels. 1.42.0-dev20230706 Vs 1.44 on other devices..
Thank you for all you folks do!
I stress tested the latest version over the weekend, and .it is looking very good. It is very usable now.
1 Like
Is this now default in the Apple TV beta? Cause nearly every time i open the app, after it is not used for a while, i get the, Your DVD could not be discovered", with the connect button. It is up for a few secs, then goes to the guide. Quite annoying. Never had this come up before.
My server was manually inputted the ip address and not using the Bonjour discovery, as my other server, that my mother uses has that enabled.
Yes.
Thanks for the diagnostics. I'm looking into the logs to see if I can understand what is causing this to happen. I haven't been able to replicate it myself, but hopefully will have enough detail from the diagnostics to resolve this.
I deleted and reinstalled the app. To remove all the past server history. I had saved several ips that no longer work.
Will see if this fresh install of the app affects that issue.
To clarify my setup, i have 2 servers. One that has bonjour enabled, and one that does not.
The 1st server that does not have bonjour enabled, is the one i use, with Apple devices, and manual input ip address into app to connect.
The 2nd server, has bonjour enabled, my mother uses that one with Android Tv devices, and the apps auto discover her server.
Just want to mention this as I don't want my client apps to auto discover her server and auto connect to it, instead of mine.
There's a new build being created right now that should fix the issue you saw with the screen showing no DVR found before connecting. Thanks for reporting the issue and for the diagnostics.
The main reason for the DVR Discovery change was to be able to accommodate situations like the one you describe. The Apple platforms should now always connect to your manually discovered DVR and only fall back to bonjour discovery if the manually discovered DVR is unreachable.
Hi @eric
Just noticed something different with the new discovery method. It still works. However up until very recently, if the last used address was on your home local ip address , i.e 192.x.x.x, not the tailscale address, the app would open up with no delay. If the last used was on tailscale there was an expected delay as we discussed.
Ive been traveling for a week, and now Im back home, and ive noticed that now there is a long spinning wheel (much like the tailscale negotiation) even though the last connect is local. Can be up to 6-7 seconds.
Please send diagnostics from the app after you see this.
Done. Submitted.