Jump to content

[Win10] App not connecting to server


BorgSquared

Recommended Posts

I appreciate the help.  None of my Win10 devices are the same (tablet, PC gaming desktop, laptop, work desktop).  The only thing they share is the Emby server.  They can run Emby Theater or just open a Chrome\Edge Web browser; and, open http://xxx.xxx.xxx.xxx:8096(or connect via Emby Connect).

Link to comment
Share on other sites

Happy2Play

Right but I can't install this app on Windows 7 like I can the Theater.  This app is specific to Win 8/10 so something in that environment is causing the issue.

Link to comment
Share on other sites

Thanks!  Here are the during connecting.  This keeps happening over and over again in the metro log.  I had to change my ddns domain before post the log to, for privacy.

 

Is there a temp file or working directory on the Emby Server I can delete that may only affect incoming Modern Windows app connection?  There may be a broken component on the server that can only affect the Modern app incoming connections to the server.

60|2016-01-22T16:25:26.9509037+00:00|ERROR|5|RtLogger|Request timeout to http://192.168.1.2:8096/emby/system/info/public?format=json --> System.TimeoutException: The operation has timed out.
   at MediaBrowser.ApiInteraction.PortableHttpWebRequestFactory.<>c__DisplayClass5.<GetResponseAsync>b__4()
   at System.Threading.Tasks.Task`1.InnerInvoke()
   at System.Threading.Tasks.Task.Execute()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
   at MediaBrowser.ApiInteraction.Net.HttpWebRequestClient.<GetResponse>d__1.MoveNext()
85|2016-01-22T16:25:28.2849984+00:00|ERROR|12|RtLogger|Request timeout to http://192.168.1.2:8096/emby/system/info/public?format=json --> System.TimeoutException: The operation has timed out.
   at MediaBrowser.ApiInteraction.PortableHttpWebRequestFactory.<>c__DisplayClass5.<GetResponseAsync>b__4()
   at System.Threading.Tasks.Task`1.InnerInvoke()
   at System.Threading.Tasks.Task.Execute()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
   at MediaBrowser.ApiInteraction.Net.HttpWebRequestClient.<GetResponse>d__1.MoveNext()
102|2016-01-22T16:25:31.0651845+00:00|ERROR|18|RtLogger|Error getting response from https://MYDDNSDOMAIN.COM:8096/emby/system/info/public?format=json --> System.AggregateException: One or more errors occurred. ---> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: The handshake failed due to an unexpected packet format.
   at System.Net.TlsStream.EndWrite(IAsyncResult asyncResult)
   at System.Net.PooledStream.EndWrite(IAsyncResult asyncResult)
   at System.Net.ConnectStream.WriteHeadersCallback(IAsyncResult ar)
   --- End of inner exception stack trace ---

@@MKANET, Does the log show anything in reference to the connection failure?

 

%LocalAppData%\Packages\436337Illusions.com.MediaBrowser_77hd5e1v1hqs4\LocalState\MetroLogs

Link to comment
Share on other sites

Happy2Play

you see it tries the local address first, which times out so then it tries the external address.

But the external is via https and port 8096.

Link to comment
Share on other sites

mkanet - what is the external address that is displayed in the server dashboard? if it is not 8096 then this might be a bug in the app. but its still beside the point anyway because there's still the issue of the local address timing out.

Link to comment
Share on other sites

I think I figured out what's causing the problem... no matter what I try to do in any of my Win10 metro apps, they all try to connect to:

 

http://192.168.1.2:8096

 

if I try to specify DDNS, it will try to use https (even if https option is unchecked in the metro app when connecting).  Something seems to be messed up with SSL and the way it's handled by the metro app. Even when the modern app is configured to use http only.

Link to comment
Share on other sites

@@Luke, sorry I just saw your post.  Below is exactly what's on my server (except, I just changed the DDNS name for privacy).

  • The local address URL works fine from any Win10 device on the LAN in any web browser.. displays the Web Client very quickly.
  • The remote address URL works fine from any Win10 device on the LAN (or externally) in any web browser.. also, displays the Web Client very quickly.
Server Information

 

Version 3.0.5817.0

checkmarkgreen.png Emby Server is up to date

 

A new version of Emby Server is available!

 

Update Now

Please shutdown the server and update manually.

 

Running on http port 8096, and https port 8920.

 

Local access: http://192.168.1.2:8096

Remote access: http://MYDDNSADDRESS.COM:8096

 

mkanet - what is the external address that is displayed in the server dashboard? if it is not 8096 then this might be a bug in the app. but its still beside the point anyway because there's still the issue of the local address timing out.

Edited by Happy2Play
edited external url
Link to comment
Share on other sites

7illusions

maybe the timeout in the app needs to be increased

 

The timeout in the app is set to 20sec so that's not where it fails. It must be in the ApiClient ConnectionManager that it's timing out before trying the external url. I'll look into  it, but I don't run apiclient from code anylonger.

Link to comment
Share on other sites

The timeout in the app is set to 20sec so that's not where it fails. It must be in the ApiClient ConnectionManager that it's timing out before trying the external url. I'll look into  it, but I don't run apiclient from code anylonger.

 

The timeout for the local address is 5 seconds which is probably a little aggressive so I'm going to increase that. For all others it's 15 seconds, including the manual address screen. So Mkanet can test by manually entering his local address into the app, that will have a timeout of 15 seconds and will help tell us if that's related or not.

Link to comment
Share on other sites

I'm not sure if this matters or not... on the same Win10 device, the web client (or Emby Theater) can connect directly to the external URL (or private, if on LAN) within a second.  It's pretty much instant.  If there's any more info you guys need, please let me know. 

Link to comment
Share on other sites

So Mkanet can test by manually entering his local address into the app, that will have a timeout of 15 seconds and will help tell us if that's related or not.

Link to comment
Share on other sites

This is what I've been doing all along... (in addition to trying with Emby Connect).  It fails within just a second or so.. 

 

When clicking on the "detected servers" running on the LAN, I get the same Server Unavailable.

 

When I use that same URL in a web browser, it connects to the server directly and pretty much instantly... even via the external address\port.

 

4kcj90.jpg

 

 

So Mkanet can test by manually entering his local address into the app, that will have a timeout of 15 seconds and will help tell us if that's related or not.

 

Link to comment
Share on other sites

7illusions

Can you get me another log from that please? Feels strange that you get the unavailable after just a sec, must be something happening that we don't fully handle

Link to comment
Share on other sites

7illusions

I will submit to store asap.

The problem was in the timeout for the local address within the apiclient lib, so once the Windows Phone app is updated, it will also experience better connectivity.

I am as surprised as Luke that it was fixed, I thought we would need to add a lot more logging to figure this out, but I'm glad it was a simple fix

  • Like 2
Link to comment
Share on other sites

I have to admit, I was surprised too that the test build worked immediately.  The same test build worked great on another Win10 device, reproducing the same fix. 

 

I really appreciate everyone's help to get this resolved quickly!  Thank you, as always!

  • Like 2
Link to comment
Share on other sites

BorgSquared

I just noticed today, that it suddenly started working again. Thank you for looking into the issue and releasing a fix.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...