Here is another diagnostics when it did find the server after about 8sec
New diagnostic log submitted under 2d189a34-e1bc-409f-9fd1-e940bdf19cf5
for the record, I would count 8 seconds for just finding the server, as latent.
Only one server, both client and server are hardwired. Absolutely no other issues with the network, it's some sort of channels bug on wakeup from what I can see.
1 Like
@Rice: Yeah, you really do have something weird going on with the discovery process on your device. I'll have to continue to read through your logs in more detail to get to the bottom of why it's behaving differently than expected.
If you try logging out of your remote session that may clear things up, but I definitely would like to understand what's going wrong.
Ok will do. I wonât have access to LAN to test until tomorrow.
On a side note I donât normally have any issues when remote launching just LAN. That being said on a log out log in via the app I get this, which is similar but a different pop up message. It does eventually connect though remotely after screenshot.
New diagnostic log submitted under a17b4b55-c3f9-45a5-bfaf-09c7358eb92d
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?