Apple TV 4K How to connect Server by URI

[jedd 0]

Hi.

 

my emby server uri is 'https://[myaddress]/emby' 

When entering new server information, if https://[myaddress]/emby is used in the URL input field, a connection failure appears.

 

I am using Android TV, web browser, iPhone app with the same contents.
It's only a problem with the Apple TV.

The https://[myaddress] url is being used for other content, so /emby path must be included.

Please let me know how I can solve this. 

[Luke 37019]

Hi, if you try adding the port into the url, how does that compare?

[jedd 0]

Hi, The URL I entered is as follows

 

http://[mydomain]:443/emby

http://[mydomain]/emby:443

Result is 'connection failed'

 

In the iPhone app, you can connect by entering the Host information https://[mydomain]/emby and leaving the Port input field blank.

[Luke 37019]

But port 443 should be https not http, right?

[jedd 0]

write mistake.

 

https://[mydomain]:443/emby

https://[mydomain]/emby:443

Result is 'connection failed'

[Luke 37019]

Can you try just https://[mydomain]:443 ?

[Happy2Play 8250]

Will have to look but there are several topics on https://{mydomain}/emby having issues.

2 minutes ago, Luke said:

Can you try just https://[mydomain]:443 ?

OP has other services on https://{mydomain}

@cayarscan you comment as you have a couple write-ups on this issue.

[Carlo 4330]

Thanks @Happy2Play.

@jedd it sounds like you have a reverse proxy inline which is fine to use to distribute apps sharing the same ports but the way you're doing this isn't going to work for Emby.

There are two styles of setting up the URL for reverse proxy identification and redirection which are:
domain.ext/service
service.domain.ext

Service of course being the key to know what this is.  So for you it would be either https://domain.ext/emby or https://emby.domain.ext.

For web browsers either will almost always work and doing the service as part of the path requires no DNS entries or changes so it's the easy method.
Using the subdomain.domain.ext method typically requires a CNAME record to be added to to your domain for each new entry.  However it doesn't have to be like this.  Instead you can setup one time a wild card entry so anything like xyz.domain.ext or 123.domain.ext will get forwarded to your reverse proxy.  That also allows you to use a wild card cert for your whole domain vs having to renew all the individual certs. So once setup this way it can actually be cleaner and easier to use as well.  Just add a 404 response page in your reverse proxy for any subdomain that doesn't match or forward it to your main site, whichever fits.

The reason you need to use the subdomain.domain.ext format is that you have application on hardware devices that you have no control over using the host name.  They don't speak "web" but instead use an API and possibly web hooks to communicate with Emby.  They except the to take the host name and port variables and use those with a hardcoded API string.

As a quick example, let's assume the API is going to use "https:// + hostname + /web/index.html#!/startup/manuallogin.html?serverId=GUID + port" to assemble the API call.  Here is what both would look like using the following for the host entry of "great-media.com" with a port of 8920.

https://emby.great-media.com/web/index.html#!/startup/manuallogin.html?serverId=GUID:8920
https://great-media.com/emby/web/index.html#!/startup/manuallogin.html?serverId=GUID:8920

If you try and get creative with the hostname entry doing something like "domain.ext/emby:8920" it gets even uglier.

Does that make sense?

So while doing testing with a reverse proxy seems to work ok in a browser it will be broke for most apps because at best there is an extra "/emby" in the URL that it isn't expecting.

So switch to the subdomain.domain.ext method and these problems go away.

 

[Luke 37019]

@jedd has this helped?