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.
That worked.
Okay, so that rules that one out.
I think this might explain the situation:
No, the AT&T Gateways do not fully support NAT loopback (or hairpin as it is sometimes called). Sometimes it will appear to function, albeit very slowly.
This is really the worst situation possible for us: It acts like it works the first time we try it, but then fails right after it. I'm not really sure what it is that we could do with this kind of defective router.
"or acquire and use another router with the Gateway in IP Passthrough mode."
Put the AT&T gateway in IP Passthrough (bridge) mode
Unfortunately this is not feasible. The way att implements ip pass through it causes a double NAT which is not acceptable for my use. Att further complicates it by only allowing fiber authentication with their gateway routers. How I miss my old edge router.
The app worked fine with this router for over 2 years. I guess I need to request a different router and hope they have switched to a better gateway.
With no other alternative routers available from AT&T, I decided to spin up a pi-hole and block my ://ff9xxxxxxxx.u.channelsdvr.net hostname. This has fixed the problem.
It looks like it is possible though... basically one device connected to the router gets the public address. So setup a pfsense box or something similar and connect it to your router...