AFTV and Android TV Vanishing Users.

[trentmsteel 1]

I have been using the Ebmy AFTV and  Android TV apps for months and I have notice a recurring bug over and over again. But have been ignoring it up until now. The bug / behavior plays out like this.

Starting from a fresh install of Emby for Android TV & Emby for AFTV, I start the app and enter server address (mydomain.com) and port number and click enter. Then I am presented with a list of users, I then select my username and then input my password to login, and I am able to browser and play my media just fine. 

 

 

 

Now if I exit the app and return to the AFTV or Nexus home screen and return to the Emby app the list of users under "select a user" has no users listed. I then try to enter my user name and password manually, but after hitting enter nothing happens. 

The only way I have found to get around this is to clear both the cache and data in the Emby app settings and relaunch the Emby app and manually enter server address and port. Then and only then will the list of users to select from once again appear. But of course if I leave the app the cycle starts all over. 

 

 

I have tried several ideas trying to fix this, such as New hardware players, new server installs, using different internet connections. and using Emby connect to login. Any ideas what maybe causing this? 

Edited September 21, 2015 by trentmsteel

[CBers 6770]

You may want to post a server log for EBR/Luke to look at, as I believe that timeout message means it's not getting info back from the server.

[ebr 14910]

I don't think the server log is going to help but thanks.

 

That timeout must be attempting to contact your server as it was saved by the connection manager.  Is this a remote access situation?  Because it should find your server(s) automatically if on a LAN.

[trentmsteel 1]

I don't think the server log is going to help but thanks.

 

That timeout must be attempting to contact your server as it was saved by the connection manager.  Is this a remote access situation?  Because it should find your server(s) automatically if on a LAN.

 

Yes it is a remote access situation. I have been running Emby Server from Europe, and the U.S during testing of my setup, while I myself live in the U.S.

Given that you think it maybe a remote access issue, here is a little bit about my setup, in the hopes someone will be able to point out a flaw that may be behind this issue.

.

• Emby server running on Windows Server 2012 R2 in a EXSI virtualization environment
• Emby Server sits in DMZ mode behind a virtual dd-wrt router. (I have tired both DMZ and port forward to Emby Server)
• Emby Server traffic is routed using CloudFlare. (I have also tried Emby Server without using CloudFlare)
• Emby media is stored and streamed from local drives as well as Cloud storage providers.
• On a Server using 1Gbps unshared connection. 
• No firewalls enabled on the OS or on the Router, during troubleshooting for the Vanishing Users issue on Aftv and Nexus.

 

Using this setup seems to work perfectly, of course excluding the user list not loading.

By the way since the implantation on the Exoplayer's Auto settings and various other changes the Emby team have made, I and the users I share my libary with on different continents have been able to stream videos of all sorts of bit rates ranging from 314 kbps to 9677 kbps without the issues of constant buffering and stuttering I have had in the past. Even a user of mine with an ISP connection speed of 2 Mbps Down and over 7,247 km away from the Emby Server is able to stream a 9677 kbps bit rate video without issues. I also ran the latest Plex on the same EXSI host under the same setup, and my users are not getting the same smooth playback, I commend you guys on the what you guys have been able to achieve. 

Edited September 21, 2015 by trentmsteel

[ebr 14910]

My best guess is that the rather complex network configuration you have is confusing something in our connection manager.

 

If you look at the server dashboard page, does the remote address that is reported there match what you are entering as the server address in the app?

[trentmsteel 1]

My best guess is that the rather complex network configuration you have is confusing something in our connection manager.

 

If you look at the server dashboard page, does the remote address that is reported there match what you are entering as the server address in the app?

 

 

Problem Solved!!

 

So it would seem, that the remote address in the Server Admin section has to match EXACTLY the address entered into the Emby AFTV and Android TV App.

Previously I was entering the following to access the Emby Server

 

• (mydomain.com:port)
• (ip address- ##.##.###.###:port)
• (http://mydomain.com:port) 

The server dashboard shows the remote access location as ip (http://##.##.###.###:port), and only after entering the access url EXACTLY as shown into the AFTV and Nexus Aps, which in this case has to contain "http://" and not just the ip address and port like I was previously entering.

Has solved the issue, now the AFTV and Nexus Apps are consistently showing the list of users even after rebooting the AFTV and Nexus players and returning to the app. 

 

Thanks with helping guide me in the right direction. 

Edited September 21, 2015 by trentmsteel

[ebr 14910]

All of that should have been transparent - especially if using Emby Connect.

 

Luke - is it more likely that this is an issue in the Connection Manager or, somehow, something in the app.  I'm not sure what it could be in the app as, if it isn't configured to automatically log in to a specific user, it doesn't use any saved connection information - other than what Connection Manager does.

[Luke 37050]

I don't know, we have to catch it when it happens and learn why. the manual url he's entering shouldn't matter. that is more likely a coincidence, unless the previous manual url would have certain situations in which it is unreachable.

[ebr 14910]

Yeah, what I was actually thinking was that it wasn't so much a not  matching situation as maybe a dns not able to resolve the address type thing.  That seems much more likely as I don't think we do anything that tries to match up the addresses to anything.