Could you turn Tailscale off on your phone and see if that makes any difference? I'm trying to understand why you're seeing a different experience from me when I try to do the same thing.
Tailscale has been off on my phone on all these attempts and diagnostics submissions.
I’ll turn Tailscale off in the dvr settings in the web ui. It will still be enabled at an OS level though and see if that helps.
It also does the same thing on my daughters iPhone and that device doesn’t have Tailscale installed or registered.
My home LAN(where the issue is experienced) is 192.168.1.169 if the logs are showing it’s trying to connect to a 100.xxx tailnet that’s probably the issue as my phone doesn’t have Tailscale enabled most of the time. I use the normal remote port forwarding method not Tailscale to reach my home server while remote. I don’t use the app to access my other two servers via tailnet very often but they are in the app to choose from with tailnet ip’s.
This does not help.
I don’t know if this latest prerelease is to remedy this problem but this is the first time it didn’t have the issue on a cold app start in a long while. It is much quicker to find the server now. Will test more through out the day but looks promising.
Looking at the code change, I don't see how it could have impacted you, so it may have just been a fluke... The code involved is only invoked when the IPs of interfaces on the DVR change.
Yep I spoke to soon. Issue is back. May be the act of a server update cleared something and allowed proper functioning on first connection. I guess I’ll report back if the next prerelease acts the same.
Bump. This bug is wearing on me. Happens just on iOS. My Apple TV and Shield don’t have the issue.
New diagnostic log submitted under efc95292-970f-4623-ad03-85e7c10d3836
There's just something funny about your network or your setup.
As soon as the app boots, it tries to connect remotely and locally and the remote request responds successfully first. It then starts to go through the process of downloading all of the data that it needs and during that time, gets timeouts while fetching the data. That's when you see the display of the server not being found.
Once that has failed, it tries again and finds the server locally and connects to it successfully.
There shouldn't be a normal situation where one request succeeds to the remote hostname and the next one fails a second later.
If by remote hostname you mean my server at the
https://ff9xxxxxxxx.u.channelsdvr.net:8089/ I don’t see how it is possible to succeed in the first place. My router doesn’t support hairpin nat so trying to go to that url fails.
Interestingly I did setup a short cut in iOS to view dvr activity that points to this url https://ff9xxxxxx.u.channelsdvr.net:8089/dvr and it will return the proper status of the dvr even when attached to WiFi lan. This URL should fail while on lan but work on a remote connection but it works on both.
Just now to test, I have disabled remote streaming in the web ui. Same fail launching the app. Same success viewing my dvr activity shortcut. Deleting this iOS shortcut did not fix loading on the app.
Here is diagnostics with remote streaming disabled in web ui
39340429-17b8-4530-a918-df5b25aeca3b
Yup. That’s a very strange situation. I wonder if it’s Wi-Fi Assist kicking in on the phone.
Sure sounds like this is indicating something like Wi-Fi Assist kicking in.
If you disable WiFi does the shortcut work? It would indicate your port forwarding is still happening.
1 Like
Ok remote was still enabled on that test above even though it was toggled off. I have toggled remote back on and off and restarted the server machine. Verified remote was disabled by attempting to hit my server while on mobile connection. The server page will not load. Now rejoining lan attempt to connect with app, it takes 5-10 sec to load the app but it doesn’t fail. Yay!! connected but slow. Sent diagnostics to see if you can tell why it’s slow. ef2c80e9-5e6b-47db-a338-9822f195d304
I use remote a lot so this is not a solution but maybe you can see something in the logs to fix it.
For the brain burner, the activity shortcut works while remote disabled on both cell data and lan.
Toggling remote back on and the app issue is back on home lan.
Wondering if this has something to do with it.
Read from this post to end
I can reach my server on my lan (192.168.1.4:8190) from locally on my lan with remote access disabled using https://192-168-1-4.xxxxxxxxxxxx.u.channelsdvr.net:8190/dvr
What would cause this prerelease tvOS/iOS Beta Notes - #796 by fancybot to fix the issue on the first cold launch after beta update. I’m talking just the iOS beta, I haven’t updated the server. In the past some but not all iOS prereleases fix it and then it returns at the next start up. The first time opening on this prerelease it is lightning fast to load the app. Sub 2 seconds. I do not have a large library. If a new diagnostics will help here is one after the successful launch. 8501fc9a-de93-4d51-b7ae-2ba5039498d1 Unfortunately it doesn’t stay fixed on launches after the first. Perhaps you can make the app do whatever happens on the beta update happen at every launch of the app?
@Rice Sounds like a fluke. If it really is the case that your NAT doesn't do hairpin, the only explanation that makes sense is Wi-Fi Assist.
I bet you wouldn't be able to replicate the issue if you turn on Airplane Mode...
That can be turned off in Settings to test.
Settings > Cellular and scroll down past the list of apps
video link here of same issue in airplane mode. Note the airplane at the top. My router is a AT&T fiber BGW320 with a unifi u6 long range access point. It doesn’t support hairpin/loop back NAT.
WiFi assist is and always has been OFF on my iPhone.
