What's reasonable to expect 'off' the local network

[jmangan 11]

I've just finished setting up an nginx reverse proxy so that I can access emby outside my local network but I'm not sure what I should expect.

 

I have fibre-to-the-cabinet at home which gives me just short of 20Mb/s upload. Today I tried out my new toy from work where, separate from the organisation's network, we have a Virgin fibre link (which I think is 10Mb/s duplex) which I connected to wirelessly. I was within 10 metres of the router in an open room with an excellent signal.

 

On an android phone I was able to select and stream music successfully. I then tried to watch a 'Blackadder' special but it just kept stopping, pausing for ~5 seconds and then playing a clip. The file is around 900MB for a 15 minute item. It was ripped using MakeMKV from a standard DVD (not Blu-Ray) and shows as 

 

on the Emby server.

 

I assumed that the server would recognise the off-network nature and transcode on the fly to something suitable for the phone. I've got a quad-core Phenom in the server with little else going on at the time so processing shouldn't be an issue.

 

I don't know whether this is the server, the reverse proxy (Raspberry Pi), the broadband at work or me being too ambitious and I should have just downloaded it.

 

I've attached a log with IPs obfuscated (hopefully not unhelpfully) in case there is an issue I can address. The downloaded started around 7:52am on 2nd June..

 

TIA.

Emby Log.rtf

[Luke 37345]

Hi, was there an ffmpeg log, if so, can you please attach that as well? thanks !

[jmangan 11]

Luke, strangely, no. The only ffmpeg log I've got finishes at 7:30 when I was playing around inside the network.

 

I've attached it in case there is some error or message that might shed light.

 

Thanks.

 

ffmpeg.rtf

[Guest plexman]

I might suggest that the rpi is not powerfull enough for the reverser proxy scenario. I had a reverse proxy in a low end system (celeron), emby in another pc and it was very very slow to the point that things didn't charge in the web app. Now I have the reverse proxy and emby on the same computer and it works perfectly. Maybe this could solve your issue, give it a try.

 

EDIT: The Emby pc is a Skylake i5-6600

Edited June 3, 2017 by plexman

[jmangan 11]

@@plexman. Thanks for the suggestion but that wouldn't really fit in with my environment.

 

I would be interested to know why the RPi wouldn't be able to do the job. I was also under the impression from other posts that the RPi isn't an unusual choice for this role.

 

To the best of my knowledge (although I'm always happy to expand it) there's not a huge amount of CPU processing for the reverse proxy (and 'top' seems to bear this out) and even though the RPi's network connection is limited to USB speeds the real bandwidth bottleneck is the broadband.

 

I'm not using the RPi for any 'local' traffic either so there's unlikely to ever be more than one or two streams in use but if I can't get any other solution I will look at something a little beefier as a test.

 

Thanks again for the suggestion.

[pir8radio 1294]

post your nginx config.   Also what HW version of pi is it?

Edited June 3, 2017 by pir8radio

[jmangan 11]

If it will help.

 

It's not finished yet. I've got a couple of articles on hardening that I need to go through checking for relevance.

 

And Pi 1. 

nginx.conf.txt

nginx.site-conf.txt

Edited June 3, 2017 by jmangan

[pir8radio 1294]

ahh, wow that's a basic nginx config lol..   Try this for your location section, you can remove the "security settings" add them in later if you want.  Your config will present nginx as the end user to emby..  So emby sees this connection as local, disabling transcodeing.  You need to pass the client info on to emby through nginx. Plus you are disabling websockets by not having the websockets section.

     location / {
        proxy_pass http://127.0.0.1:8080;

	proxy_hide_header X-Powered-By;
	proxy_set_header Range $http_range;
	proxy_set_header If-Range $http_if_range;
	proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

     ## SECURITY SETTINGS ##
	add_header 'Referrer-Policy' 'origin-when-cross-origin';
	add_header Strict-Transport-Security "max-age=15552000; includeSubDomains; preload" always;
	add_header X-Frame-Options "SAMEORIGIN" always;
	add_header X-Content-Type-Options "nosniff" always;
	add_header X-XSS-Protection "1; mode=block" always;
	#add_header Content-Security-Policy "default-src 'self'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; object-src 'none'";

     ## WEBSOCKET SETTINGS ##
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }

[pir8radio 1294]

actually dont add the security section until you are happy with your server setup, especially the line below.

 

add_header Strict-Transport-Security "max-age=15552000; includeSubDomains; preload" always;

 

It will force you to stick with https and the cert you are currently using if added.

 

@@jmangan let us know how it goes.

Edited June 3, 2017 by pir8radio

[jmangan 11]

pir8radio, okay more information there than I am ready for.

 

Do I want emby to see this as a local connection? Wouldn't that cause the problem I'm (possibly) seeing of emby not transcoding for the remote client?

 

Also, the 'proxy_pass' seems to be going to a local machine. The nginx and the emby-server are on physically separate machines on different sides of a firewall.

 

Currently i am using https (8920/tcp) to nginx and then nginx falls back to the http (8096/tcp) for the communication to the emby server.

 

Clients within my network go directly to the emby server on 8096.

 

Or have I completely misunderstood?

[pir8radio 1294]

pir8radio, okay more information there than I am ready for.

 

Do I want emby to see this as a local connection? Wouldn't that cause the problem I'm (possibly) seeing of emby not transcoding for the remote client?

 

Also, the 'proxy_pass' seems to be going to a local machine. The nginx and the emby-server are on physically separate machines on different sides of a firewall.

 

Currently i am using https (8920/tcp) to nginx and then nginx falls back to the http (8096/tcp) for the communication to the emby server.

 

Clients within my network go directly to the emby server on 8096.

 

Or have I completely misunderstood?

 

1. I was saying your existing config shows all users as local.  My config suggestion wont do that.

2.  that was an example you should use your server ip and port instead of my 127.0.0.1

3.  same as above.  Though there is no issue with nginx/proxy pass always using http 8096 its on your local network, no need to secure it, unless you live with hackers.. that will be sniffing the traffic..    :-)

[tdiguy 96]

Transcoding on a RPI for me so far has sucked. If possible try to use directplay on the pi. I have been trying to find ways to get hardware acceleration working with the pi and ffmpeg and not had any luck getting it to work yet. I think in theory especially for mp2 format it should be possible ( even bought a 2$ key for it ) but transcoding at all on a pi sucks. For me for  a while it was a source of instability, i had my pi trying to convert tv shows while recording them.

 

You might be able to completely avoid transcoding though. I imagine if you store files as mp4's it will help.

[pir8radio 1294]

Transcoding on a RPI for me so far has sucked. If possible try to use directplay on the pi. I have been trying to find ways to get hardware acceleration working with the pi and ffmpeg and not had any luck getting it to work yet. I think in theory especially for mp2 format it should be possible ( even bought a 2$ key for it ) but transcoding at all on a pi sucks. For me for  a while it was a source of instability, i had my pi trying to convert tv shows while recording them.

 

You might be able to completely avoid transcoding though. I imagine if you store files as mp4's it will help.

 

He is just using the Pi for nginx reverse proxy, emby is running on an actual PC for him.  His issue seems to be within the nginx config.

[Luke 37345]

In the first post, what Emby app were you playing from?

[jmangan 11]

pi8radio, well I've run a quick test over 4G with your additions and it looks very promising. No pausing or stuttering on a relatively weak signal.

 

There's an ffmpeg log for the session so transcoding is definitely now happening.

 

Of course, I now have some more reading to do to understand the stuff I've mindlessly added    but it's much appreciated. I've marked your answer  above as the best.

 

Many thanks.

[jmangan 11]

Luke, it was the Emby app on an android phone, V. 2.9.01, but it looks like pir8radio has identified the issue on my reverse proxy.

 

This is my first experience with nginx so I am very much in learning mode.

[pir8radio 1294]

Of course, I now have some more reading to do to understand the stuff I've mindlessly added 

 

    proxy_hide_header X-Powered-By;     ## This line hides the version of nginx you are running, so potential hackers dont know the exact release of nginx, incase there was a vulnerability in your specific release version, they wouldn't know what specific attack to attempt first. No other function.

 

    proxy_set_header Range $http_range;    ##  Used for request/return a specific chunk of a file or document

    proxy_set_header If-Range $http_if_range;   ## ##  Used for request/return a specific chunk of a file or document

    proxy_set_header X-Real-IP $remote_addr;   ## tells backend server (emby) the real client IP

    proxy_set_header Host $host;   ##  if you typed http://embyserver.com:999  in the browser this info would be placed into this header and carried over to the backend so that server knows what site you requested.   

    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;   ## tells backend server that you are going through a reverse proxy, and adds the client IP that was forwarded for to this header.   This is most likely the line that fixed your issues, but the others are needed for a good emby experience.

 

 

## WEBSOCKET SETTINGS ##    ## these settings allow for websockets to function correctly through a reverse proxy.

proxy_http_version 1.1;

proxy_set_header Upgrade $http_upgrade;

proxy_set_header Connection "upgrade";

Edited June 4, 2017 by pir8radio

[jmangan 11]

pir8radio, I can't thank you enough or 'like' your posts enough.

 

You've probably saved me days (or weeks) trying to work this out because I didn't even know these options existed.

 

I do have one more question though (no good deed goes unpunished).

 

My reading of the documentation on this line:

 

add_header Strict-Transport-Security "max-age=15552000; includeSubDomains; preload" always;

 

seems to suggest that the policy will now actively prevent non-HTTPS connections to this server.

 

But I still need certbot to be able to connect on port 80 to renew certificates. Have I missed something?

Edited June 4, 2017 by jmangan

[pir8radio 1294]

pir8radio, I can't thank you enough or 'like' your posts enough.

 

You've probably saved me days (or weeks) trying to work this out because I didn't even know these options existed.

 

I do have one more question though (no good deed goes unpunished).

 

My reading of the documentation on this line:

 

add_header Strict-Transport-Security "max-age=15552000; includeSubDomains; preload" always;

 

seems to suggest that the policy will now actively prevent non-HTTPS connections to this server.

 

But I still need certbot to be able to connect on port 80 to renew certificates. Have I missed something?

 

 

Yea that's why I said to add that line only after you are happy with your setup, and I guess if you want your clients to connect 100% https.  If you need something to connect to any part of your domain name  using http leave that line out.    What it does is allows an http connection but then forces the client to switch to https and converts any http links to https.  Here is some more detailed info..  Here is some more detailed info oh HSTS:  https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

 

cert bot may still work, but I don't use it and cant be 100% sure.

Edited June 4, 2017 by pir8radio