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.
If you go to Settings -> Connect -> At Home and re-select the local IP, it will fix the issue.
The problem is the last time you selected an IP you had selected the Tailscale one, so it was still waiting to establish that connection. Once it was established, it checked if it could connect directly and started doing so, but still wanted to make sure that it could connect over Tailscale if it was needed.
Yep. Tried the fix and it worked. Thank you eric.
Thats an interesting user interface quirk. I kept checking the channels dvr block in settings and saw the local ip address, and just assumed the “next time” it would try connecting to the last used and not try to tailscale in. Its easy to forget when traveling back and forth
I wonder if there is another set of user interface enhancements in the discovery mechanism to make it clearer what is going on?
Thank you for clarifying this!
We anticipate removing the built-in Tailscale support from iOS/tvOS in the fall when the new tvOS is released with proper support for VPNs.