Jump to content
fogpuppy

Transcoding when using the Web App on iPad

Recommended Posts

cayars

Couple observations. I'd not use Emby Server connected via WIFI.  Put at least the server on Ethernet to 1/2 the bandwidth needed by clients when using the server.

On an inside LAN there is ZERO need for IP6 as you are behind a NAT/Firewall so your IP6 is of no use.  You can turn off IP6 on every device that's inside the LAN as it's not needed. But for now go to the Emby Server machine and remove IP6.  Also make sure there is only 1 IP4 address on that machine.

If using a domain inside your LAN only this can be tricky if it's also part of a real domain due to caching.  You wouldn't want emby.company.ext to point to an outside IP and also an inside IP depending on where the machine is located.

But it sounds like you get to the machine fine but have trouble with transcoding.  That COULD be the client/server getting tripped up on addresses.  What you can try putting 192.168.0.0/24 (substitute your actual inside IP here) in the field on the Emby Server network menu called LAN Networks (first option on page).

Uncheck the option "Allow remote connections to this server" since it's an inside server only.

Chances are this might not change anything as it could still be the client AUTO settings getting in the way but this removes a lot of guessing of configuration since the server is IP 4 only and we've set the IP address space on the server as well as told it not to allow remote connections.  You won't connect now if the server thinks the connection is remote.

Share this post


Link to post
Share on other sites
fogpuppy

OK I have a "workaround" solution for now but the ultimate result points to issues with the defaults for local addresses by Emby.  To cut to the chase, Emby needs to update the default value for the "LAN networks" setting to:

10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 169.254.0.0/16, fc00::/7, fe80::/10

Here are the details for why I think this is a bug and why I think this is the right default:

Just turning off IP6 did not fix my problem.  I was still getting detected as "remote" even though it's not and IP6 was off.  I was able to trace this to the fact that the DNS server was still returning an IP6 address even though it was told NOT to give out IP6 addresses.  This was tracked to the Linux server setting an IP6 "link-local" address for itself (for a bunch of obscure internal reasons) and then like a good citizen reporting this address to the DNS server.  The DNS server then triggered the problem by returning this IP6 address instead of the IP4 address it gave out previously.  Why?  My guess is "because it can" and it is a valid and reachable address for the server.  But at least this pointed me in the right direction to get to a solution.  the iPhone & iPad used this IP address and made Emby detect it as non local...  But why was Emby declaring a link-local address as non-local.  After all it has local right in it's name ....

Thanks to hints from cayars, Luke, Happy2Play,  I went into the network setting and added the following to the LAN Networks field "fe80::/8".  This made the original problem go away but it broke all the cases that used  IP4 addresses.  So I surmised that the field was not additive so I set it to: "fe80::/10, fc00::/7, 192.168.0.0/16" which allows the ip6 link-local addresses, the IP6 ULA range (IP6's version of private address ranges) and the 192.168.0.0 private address range.  The made the IP6 and IP4 addresses both work as local and transcoding has stopped.  My work around is complete ....  Whew!!!!!

For completeness I think the Emby product default needs to be as stated above because that includes all IP4 and IP6 private and link-local ranges. Mine is a subset for my use.

Thoughts/comments?

Share this post


Link to post
Share on other sites
cayars
Posted (edited)

I'm really glad you got this sorted out and working.

Yes inputting that list of IPs should work but you really only need to include the LANS that actually are in use and local.

 

 

Edited by cayars

Share this post


Link to post
Share on other sites
fogpuppy

I don't follow why you would disagree with the default I propose.  All I'm proposing is that Emby deliver a complete implementation of what it already claims to do.  Specifically you say:

Quote

You're making an assumption that everything on those IPs are going to be local but there is no guarantee of that.  Many business use  VPN and interconnected LANs or WANs on the IPs you mentioned, but the connection still goes through the Internet or worse and of course the connection is anything but local.

But I'm not the one making that assumption Emby is already making that assumption. In the Emby Network settings for LAN networks it says:

Quote

If left blank, only the server's subnet and common private IP subnets (10.0.0.0/8, 192.168.0.0/24, etc.) are considered to be on the local network

So Emby is automatically considering the server's own subnet and the 10.x.x.x and 192.168.x.x networks local. So what am I proposing beyond this is simply adding the rest of the local address ranges as specified by RFC-1918 (172.16.0.0/12) and  RF-4193 (fc00::/7 ) standards to complete the set.  It's possible the other two private ranges 172.16.x.x and the fc00::/7 are already in there but just not mentioned.  if they are NOT in there, what would be the specific argument for argument for doing two current the local address ranges in the standards but not doing the two others?

So that leaves the link-local addresses ranges which we know at least the IP6 one is missing.  These are by their very definition "local" according to the standards.  I'm not even sure you are even able to route those address even if you want to but the standard clearly warns against doing that.  So adding the 169.254.0.0/16,  fe80::/10 should be "safe" as well per the standards.  Why wouldn't these be included in the defaults?

For the record I acknowledge your point that a business might have routing for some of these address ranges (most likely in the 10.x.x.x range) but then it would be up to them to control access via firewalls or change Emby to support their nonstandard network config.  You can't use that to argue for including some of the local ranges but not others ....

Share this post


Link to post
Share on other sites
cayars
Posted (edited)

Removed/edited because it was confusing.

If you enter info in this field, that is what Emby will use overriding it's defaults.

If blank Emby will use the current network as well as common private IP subnets as local.

It doesn't mention anything about IP6 addresses so no comment on them.

Edited by cayars

Share this post


Link to post
Share on other sites
fogpuppy

I understand your scenario and it's a valid one that 10.0.1.x in your case in NOT local.  But it begs the question is Emby doing what you say or is the documentation wrong.   I'm going to assume your correct in describing the behavior that Emby will only consider 10.0.0.x local and will assume 10.0.1.x is non-local.  So the text/documentation is frankly just plain wrong.   The second part of the statement starting with the  "and common subnets" should be removed because it's not an "and".  It should just say "if left blank, only the server's subnet is considered to be local" .  If on the other hand it really is an "and" and both 10.0.0.x and 10.0.0.1 are considered local if left blank then my argument applies.  Why restrict one subnet and not the other.?  so bluntly which is it ... a fix to the defaults or a fix to the documentation ......

Af far as the second part (link local addresses) there's almost no argument for not including those.  Only an insane person would use link-local addresses for non-local traffic.  Also, I'm pretty sure most routers wouldn't even let you route them ...

Share this post


Link to post
Share on other sites
cayars

Actually it does include the common reserved subnets as stated. I haven't looked at the wording in a while. :)

"Comma separated list of IP addresses or IP/netmask entries for networks that will be considered on local network when enforcing bandwidth restrictions. If set, all other IP addresses will be considered to be on the external network and will be subject to the external bandwidth restrictions. If left blank, only the server's subnet and common private IP subnets (10.0.0.0/8, 192.168.0.0/24, etc.) are considered to be on the local network."

So if you enter info in this field, that is what Emby will use.

If blank Emby will use the current network as well as common private IP subnets as local.

It doesn't mention anything about IP6 addresses and that was sort of my point from the beginning with DNS issuing IP6 addresses.  What I've found is that when local/remote clients get mixed up it's something to do with networking and if you know what the local is and input it into that field, poof, things work correctly.

I'm going to edit message above to reflect this and not to confuse anyone who reads this in the future.

Share this post


Link to post
Share on other sites
fogpuppy

Ok so given that it behaves as described (and as I thought), I'm going to stand by my assertion that it should include all common reserved subnets as local.  Don't you agree?

I can understand why you brought up IP6 but seriously is IP 6 supported or not? 

Share this post


Link to post
Share on other sites
cayars

I believe it does for IP4.  I do not know about IP6 to be honest.

But what I'll say is when you get out of a typical same subnet type environment you are better off customizing the network field so there is no ambiguity as to what is local or remote.

I was actually confusing this software with another that does it the other way I started to explain before I cought myself thanks to you posting the copy of the field description.

I personally don't care if it's all reserved or strictly just the network the server is on.  Either way is going to work 99%+ out of the box for most people.  It's only when you have something odd in your network that you'll need to adjust and my feeling is to just put in what you know to be your network in those cases and not "guess" or speculate how it will work.  In your case you can control and put in all reserved for both IP4 and 6 so you can cover yourself.  It's kind of like a "which came first the chicken or the egg" as it doesn't matter, we can have both!

Share this post


Link to post
Share on other sites
Happy2Play

There may need to be additional notes on this setting or a Wiki/Support page.

Share this post


Link to post
Share on other sites
fogpuppy

Basically I can see this going one of two ways .... Either make just it the server's subnet as defined by it's IP and netmask or make it all reserved private netowrks.    Anything else is confusing when some private networks work automatically and some don't .....  I'm my case the link local IP6 address was NOT working even though I had an IP6 address.

So if the server IP is 10.0.0.10 and the netmask is 255.255.0.0. then anything in 10.0.x.x is local anything else not.  BTW if IP6 is supported then the equiv IP6 subnets are needed because you can have both a IP4 and IP6 address at the same time (on one adapter).

Or use my defaults if you're going to open up beyond the server IP To all local. BTW one possible reason to open it up to all private networks is that a server could have more than one network adapter and they could be in different subnets. 

Share this post


Link to post
Share on other sites
cayars

Is it not ok with the way it's doing it now using the reserved IP blocks?

Share this post


Link to post
Share on other sites
fogpuppy

If it was using ALL the reserved blocks I’d say yes.  Clearly it’s NOT using at least one of them (the IP6 link-local block) or I would never have had this issue.  So ... my vote would be “Yes leave it like it is” but fix the “bug” for the IP6 LL block and any other missing blocks.  I think my list is complete but .... I only play a network engineer on TV.  

Share this post


Link to post
Share on other sites
Luke

The in-network detection is just a little bit trickier with ipv6.

Share this post


Link to post
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...