EXPERIMENTAL: New DVR Discovery mechanism available for testing

Beta Community Apple Beta
#11

Hi @eric

To reproduce this on my apple tv

1: I went into settings and highlighted the channels DVR tab (with local ip address of 192.168.1.2)

2: selected At Home

3: chose ip address of secondary server on my tailscale network. In this case 100.x.x.88.

  1. I verified that I was connected to the new server, as the new guide appears and i can play a channel.

note: this is still not robust, as it can sometimes take several tries to sync up the guide and the secondary DVR server. I need to select the tailscale ip address a second time after closing with the app switcher, but eventually the secondary servers guide loads.

5: moving forward , after verifying im connected to the secondary server, the guide matches up, i can play a channel for the tailscale ip address of 10.x.x.88.

6: the only way i know how to test if the client “remembers” the connected server is to now manually use the app switcher and close the app.

7: open app again and get “preparing TV”. Guide loads with original server at local ip address at 192.168.1.2 when I was hoping it “remembered” the other address on the tailscale network at 100.x.x.88

8: At this point I submitted diags from the TVOS app.

Hope this helps

#12

Ah, I see what’s going on. It looks like discovery at app startup isn’t playing nicely with our built-in Tailscale support. Thanks for bringing that to my attention. I’ll look into this further.

3 Likes
#13

@eric FYI this build caused an UX issue with the playback timeline and PIP button.

When the time is viewed (Press up on remote) and go to dismiss it (Press down on remote) the focus is move to the PIP button instead of dismissing the timeline.

#14

@mrgf09 This build didn't change anything related to that, but others around that time may have. Would you be able to isolate which build it was that caused the problem?

#15

@eric 7.5.1921 It works correctly, 7.5.2139 the focus issue started.

#18

@mnwxman132 Please try the latest Testflight build and see if it behaves better for you.

#20

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.

#21

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.

#22

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…

#23

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.

#24

Let me know if this build is any better for you.

#25

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.

#26

@eric

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

#27

Can you see if you have any better experience with this one?

#28

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

#29

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.

#30

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..

#31

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
#32

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.

#33

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.

Diags/telemetry domains used