Why are the apps using the in-home URL when I'm not in the same network as the server?

[enqbcvqw 2]

This is driving me insane. I have Emby set up on an external dedicated server with its own static public IP. The server's fronted by a reverse proxy fronted by Cloudflare. This same configuration works fine for Plex.

 

I've added a URL in the advanced settings so external access happens via that (I've tried http/80 and https/443 and neither work) yet, for some reason unbeknownst to me, app.emby.media and the Android app (which are the only two I've tested) simply refuse to use the external hostname.

 

Dashboard says:

 

Running on http port 8096.

 

In-Home (LAN) access: http://x.x.x.x:8096

 

where x.x.x.x is the _public_ IP of the server.

 

Remote (WAN) access: http://my.custom.domain:80

 

where my.custom.domain is the hostname I put in advanced settings.

 

If I go to app.emby.media and try to play something, it ALWAYS plays it back from the LAN access URL, even when I'm in a completely different network thousands of miles away.

 

Sample URL taken from Chrome dev tools: http://x.x.x.x:8096/emby/videos/182/hls1/main/1.ts?DeviceId=TW96aWxsYS81LjAgKFg...

 

Now, if I go directly to the hostname, log in and play something from there it plays from the proper hostname.

 

This should be a very straightforward thing to do. I'm moving over from Plex, where it took me exactly 10 seconds to find where to put a custom access URL, punch in the hostname and watch it just work. So this is incredibly frustrating as you can imagine.

Edited April 19, 2019 by enqbcvqw@protonmail.com

[Luke 37025]

Hi, how is the local access url able to work in that situation?

[enqbcvqw 2]

It's a dedicated server, the IP is public and all ports are accessible (so 8096 is accessible to the outside world). This shouldn't be an impediment to Emby using the hostname and this feels like a bug.

 

Also, I'd rather not use a container as I am looking to be able to use hardware transcoding.

Edited April 19, 2019 by enqbcvqw@protonmail.com

[enqbcvqw 2]

So I was able to work around the problem. If I access httpS://app.emby.media and set the access to httpS on the advanced config I'm able to pull from the right domain. This still seems like a bug, http should pull from port 80 on the external host as well.

 

EDIT: spoke too soon. The android app is still connecting directly to publicip:8096...

 

EDIT 2: I've been able to work around this issue in a very inefficient manner. I had to force Emby to listen only on 127.0.0.1 and then add a reverse proxy on that machine to proxy anything coming in from port 80->Emby's local port. HTTPS is handled by CF. This is inefficient and unnecessary as I now have to daisy chain reverse proxies just to get this to do something that should work out of the box. Where do I file a bug report for this?

 

EDIT 3: So now that I test this after having some sleep...Binding emby to 127.0.0.1 does _NOTHING_. It still listens on the public IP? This is now officially on my nerves.

Edited April 24, 2019 by Luke

[Luke 37025]

Hi, yes there is opportunity to improve this. Currently the apps are designed to always try the local address first, and then fall back to the remote address.

 

As an aside, please refrain from profanity in our community as this is a family friendly environment.

 

Thanks !

[pir8radio 1292]

So I was able to work around the problem. If I access httpS://app.emby.media and set the access to httpS on the advanced config I'm able to pull from the right domain. This still seems like a bug, http should pull from port 80 on the external host as well.

 

EDIT: spoke too soon. The android app is still connecting directly to publicip:8096...

 

EDIT 2: I've been able to work around this issue in a very inefficient manner. I had to force Emby to listen only on 127.0.0.1 and then add a reverse proxy on that machine to proxy anything coming in from port 80->Emby's local port. HTTPS is handled by CF. This is inefficient and unnecessary as I now have to daisy chain reverse proxies just to get this to do something that should work out of the box. Where do I file a bug report for this?

 

EDIT 3: So now that I test this after having some sleep...Binding emby to 127.0.0.1 does _NOTHING_. It still listens on the public IP? This is now officially on my nerves.

 

I dont follow your issue....   loose the middle nginx,  set emby like the screenshot,  also set your domain name on that same emby/advanced settings page.   Not sure how linux will handle the 127.0.0.1  but make sure you can still hit your server via the internet IP directly first.   If that works, there is no reason it shouldn't work from CF.   Maybe talk through the whole thing one more time...    Lets figure it out.   But by telling emby 999.999.999.999 is your local network (impossible IP) everything else will automatically be considered external.  and ignore the emby logs if thats what you are looking at, they display the wrong info in this setup. 

 

Edited April 25, 2019 by pir8radio

[enqbcvqw 2]

So let's step back for a second.

 

Two simple questions:

 

1. If I set up an external domain hostname, does that have some sort of "propagation time" before apps will start connecting over that hostname?

2. Will emby apps connect to IP:8096 directly if this responds _even_ when an external domain hostname is configured in settings?

[pir8radio 1292]

So let's step back for a second.

 

Two simple questions:

 

1. If I set up an external domain hostname, does that have some sort of "propagation time" before apps will start connecting over that hostname?

2. Will emby apps connect to IP:8096 directly if this responds _even_ when an external domain hostname is configured in settings?

 

 

uh...  You have to buy and register a hostname and set it up to point to your IP (A record).   Then emby apps connect to hostname:8096  if thats what you have setup..   

[enqbcvqw 2]

uh...  You have to buy and register a hostname and set it up to point to your IP (A record).   Then emby apps connect to hostname:8096  if thats what you have setup..   

 

That was an example, a royal "hostname". I already have proper FQDN pointing to my server, I know what I'm doing. Can we go back to my two questions?

 

1. If I set up an external domain hostname, does that have some sort of "propagation time" before apps will start connecting over that hostname?

2. Will emby apps connect to IP:8096 directly if this responds _even_ when an external domain hostname is configured in settings?

[pir8radio 1292]

That was an example, a royal "hostname". I already have proper FQDN pointing to my server, I know what I'm doing. Can we go back to my two questions?

 

1. If I set up an external domain hostname, does that have some sort of "propagation time" before apps will start connecting over that hostname?

2. Will emby apps connect to IP:8096 directly if this responds _even_ when an external domain hostname is configured in settings?

Sorry.. I’m not an emby team member either, I’m an end user like you. Your questions made me think you didn’t understand how things work, it’s not dns.

 

1. No. It’s not dns it just tells emby what to present to apps.

 

2. Not if you have things setup correctly and a domain name in emby settings, that’s all emby server will present to the apps. But if you go directly to the ip manually yes it will respond. Unless you have nginx or something in front of it.

 

Go to domain.com/emby/system/info/public/

You will see what the apps see.

 

 

Sent from my iPhone using Tapatalk

Edited April 30, 2019 by pir8radio