Jump to content

Chromecast not connecting from external network


Chorca

Recommended Posts

Having an issue using my chromecast from outside my home network.

 

I have the latest Emby beta (3.1.254.0) set up on a server on my internal network, using a reverse-proxy through Nginx, which also handles SSL termination.

 

I'm able to playback files from my server both locally and outside the network just fine, and Emby shows the correct local and external addresses. Accessing emby from both my subdomain and through emby connect allows me to play files from external networks correctly. I can also use a chromecast on my internal network without issue, however, attempting to use it on an external network is not working.

The Emby app will load on the chromecast, but pressing play does nothing.

 

I've attached the server log server-63617340434.txt, however, i enabled chromecast debugging within the js file loaded into the browser, and it seems that even while using the webapp or android app from an external address, Emby is defining serverAddress as the internal network IP:port, not the defined external network address, and sending that in the message to the chromecast:

chromecast.js?v=3.1.254.0:378 {"options":{},"command":"Identify","userId":"69c8a8134877492d9f4b1cec6c2f316f","deviceId":"d19e1c653e6dd88c3acb259d9cb0de59","accessToken":"5cf8d98c37a1454682483a53ea9a68ab","serverAddress":"http://192.168.1.120:8096","receiverName":"SoftwareNgineern","maxBitrate":4000002}
chromecast.js?v=3.1.254.0:385 Message was sent to receiver ok.

chromecast.js?v=3.1.254.0:378 {"options":{"ids":["6a025b0f6e038c0edec356717bdf2ac2"],"startPositionTicks":0,"serverId":"c602b41c9c304dbe9e53ff91ba9c058f","items":[{"Id":"6a025b0f6e038c0edec356717bdf2ac2","Name":"Encounter at Farpoint (1), Encounter at Farpoint (2)","Type":"Episode","MediaType":"Video","IsFolder":false}]},"command":"PlayNow","userId":"69c8a8134877492d9f4b1cec6c2f316f","deviceId":"d19e1c653e6dd88c3acb259d9cb0de59","accessToken":"5cf8d98c37a1454682483a53ea9a68ab","serverAddress":"http://192.168.1.120:8096","receiverName":"SoftwareNgineern","maxBitrate":4000002}
chromecast.js?v=3.1.254.0:385 Message was sent to receiver ok.

I'm not sure if this is due to the request technically coming from an in-network IP (Nginx server) or some other issue, but that is what appears to be preventing the chromecast from being able to connect to the address/stream. I have "Report https as external address" enabled and 443 set for the external port, and the external address is set correctly in the server settings.

Link to comment
Share on other sites

Hi @@Chorca, when you connect away from home are you using a domain name or ip address? what's if using a domain name, try with ip address. thanks.

Link to comment
Share on other sites

I'm using a domain name (subdomain), which is routed through Nginx as a reverse proxy to handle directing the various subdomains to the appropriate internal services.

 

This morning I did a bit of experimenting with my reverse proxy setup and found that indeed, the request coming from the local proxy address to the Emby server is what's keeping it from sending the right address to external players.

 

Adding the following to my location statement in my Nginx config fixed the issue:

proxy_set_header        X-Real-IP       $remote_addr;
proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;

Now emby is reporting the external domain (specified in advanced config) to the chromecast and it is able to connect.

Link to comment
Share on other sites

Here is the problem. Chromecast cannot resolved local computer names, so if you connect from the app to the server using something that is not an IP address (domain name), AND if the connected is detected to be coming from inside your LAN, then we have to convert to an IP. So the problem is that the proxy is fooling the server into thinking that all connections are inside your network.

 

Since an IP address will always work, that is really the best approach. I would love to find better ways to handle this automatically, it's just a little tricky because the server always sees a LAN address as the remote IP from where the request came from.

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...