EXPERIMENTAL: New DVR Discovery mechanism available for testing

Beta Community Apple Beta
#1

The latest Testflight beta contains a new DVR discovery subsystem that will try harder to reconnect to the last connected DVR when coming back to the app. There have been substantial internal changes to the discovery code for this but should be no user-facing impacts beyond the one described above.

Because this is such a fundamental part of the app, we are rolling out the change behind a setting called "Test New Discovery" in Settings -> Debug to allow for people to help us test this before we roll it out for everyone.

Please try it out if you are interested and let us know if you see anything weird when it is on. In general you should see no impact on having this enabled.

3 Likes
#2
#3

Great news.
Does this apply to both Connect at Home and Remote IP addresses?

1 Like
#4

Yes

#5

Sadly, i only use the discovery feature (Bonjour) with my mothers DVR, and she uses the Shield's. So once it comes to Android side, i can test this.
She occasionally gets the Your dvr is not setup screen and it asks to connect to a dvr etc.
Closing the app and re-opening fixes it.

I have never had that happen on the Apple TV side, though, my client the ip is entered it and never changes.

#6

Hi @eric

I was excited to try this.

Does the new subsystem also account for remembering the last connected dvr when using tailscale?

I noticed several crashes this morning - sent diags via the app.

The subsystem didnt always remember the last connected server. It sometimes worked.

The crash may be something else. Ive seen the same crash with and without the new subsystem option enabled. Happens when watching a channel the app crashes.

#7

Just looked into your crash and it is unrelated to this change. We're looking into fixing it.

#8

Just tested latest test flight. It is more stable without the crash when using tailscale.

I noticed that if i close the app using the app switcher, the last used server was not always remembered.

Please let me know if there is anything you need to help troubleshoot.

Happens on both IPADOS and TVOS

#9

I'll test that out and see if I can replicate this. Thanks for reporting it.

#10

@mnwxman132 Looking at your last Diagnostics, I can't see any issues with connecting to the wrong server. I also was unable to reproduce the issue you're describing. Could you reproduce it again and submit diagnostics and let me know what IP address you were expecting it to connect to and which one it did?

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