Emby across different Subnets

[lulzyatlas 20]

My Emby server currently runs in what is likely one of the rarer configurations, this thread will serve as some insight, a feature request, and some observations from it.

 

My server exists on the 192.168.2.x subnet and serves clients on this subnet as well as 192.168.1.x, this was accomplished my configuring the host machine to allow outer subnet communication for Emby and SMB shares and the setting the router for port forwarding (DMZ was used to save time).

 

The network topology itself is accomplished by a repeater bridge in which my router appears as 192.168.1.250 on the "distant" network. And 192.168.2.1 locally (where Emby is 192.168.2.148).

 

Clients on the distant network connect using the IP port combination for their side (auto connect doesn't work as multicast forwarding doesn't work/is hell) and are able to resolve the path substitution names via a host file entry (as the DNS on their side has no idea my 192.168.2.x network exists since its behind my router at 192.168.1.250). This works well enough (aside from server discovery being broken, which appears to break auto-login. Even though it remembers the last IP and can auto connect to the point of the login screen, yet can't auto login). A fun thing to note is Emby can see the 192.168.1.x devices by their 192.168.1.x IPs, no big difference, just cool.

 

The Achilles here is the path substitution doesn't work on the 192.168.1.x network as the host name doesn't resolve. And the hosts file entry is only a viable solution for PC systems (works on Android, but Android hosts mods require root).

 

This is where the feature request comes in as it would make running Emby across multiple subnets far easier. Either an option in the server dashboard to have the server offer up different path substitutions based on the subnet of the client's returned IP. Or an option in the settings menus of the clients to allow it to substitute its own \\hostOrIPname in place of the one offered by the server.

 

Either one of these would allow outer subnet yet non-internet clients to access the share from their portion of the network while leaving the default functionality in place. I feel the former of the two options would be smoother and harder to break "If you're on this subnet, reach the file with this path. If you're on this subnet, you use this path". And would allow all apps to seamlessly find SMB shares from their section of the network without delving into system configurations to modify the hosts file. A server option to serve different path substitutions based on client locations/IPs/Subnets would make a useful feature a powerful one as well. A seamless implantation of this would be a simple checkbox named Advanced Substitution or something which would say if Clients IP falls in this group (10.1.0.x, 192.168.12.x, etc) then replace \\HostName in General Path Substitution with \\192.168.12.35 etc etc (Localized IP or DNS for that portion of the network). This would help streamline and maximize compatibility for various network types.

 

Aside from the path substitution 'bug' (it's clear from the use of multicasting that Emby isn't designed with multi subnet networks in mind (also evidenced by its tendency to attach to the wrong subnet in certain DualNIC configurations)), and the auto connect 'bug' (again, multicasting), playing across different subnets works just as well as playing from the same subnet once the networking rules are worked out and configured.

 

For anyone looking to run Emby over a bridge, that's how I accomplished it. Non-Bridged repeaters likely won't pertain to this as their networks tend to exist on the same subnet. But if you're looking to achieve play across subnets, that's the only set of configurations I pulled off. (And per subnet path substitution/auto connect&auto login to last known IP instead of discovery IP would only make it easier)

 

Oh and, I omitted version info because everything I've touched on in this post has applied to every version I've used with this setup for the past year or so, and unless there's already a major change to path substitution coming, for the foreseeable future as well.

Edited June 10, 2015 by lulzyatlas