Do you get the new bandwidth graphs updated?

[gdob]

It seems mine just sits flat. Not of an issue, but more of a question if it’s due to my nginx configuration.

[zmike808]

Well, sure it could be nginx. Or it could be Plex just pulling a classic Plex, and offering some shiney new plex pass feature which only actually functions for maybe a few days. Obviously I hope that isn't the case but I wouldn't be surprised at all if it were actually true. They have a nice and shiny track record of pulling this shit. /Cough/ Cloud Sync /cough/

[gdob]

@zmike808 Do you get your graphs updated? It may be Plex, it may be my nginx configuration.

nginx.conf

# This nginx config and mime.types consulted with
# https://github.com/h5bp/server-configs-nginx

user www-data;
worker_processes auto;
pid /var/run/nginx.pid;
error_log /var/log/nginx/error.log;

events {
    worker_connections 512;
}

http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 300s;
    include mime.types;
    default_type application/octet-stream;
    index index.php index.htm index.html;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
    ssl_ciphers ECDHE+AES128:RSA+AES128:ECDHE+AES256:RSA+AES256:ECDHE+3DES:RSA+3DES;
    ssl_ecdh_curve P-256;
    ssl_session_timeout 24h;
    ssl_session_cache shared:SSL:10m;
    ssl_buffer_size 4k;
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 213.133.98.98 213.133.99.99 valid=300s;
    resolver_timeout 5s;
    client_max_body_size 10m;
    server_tokens off;
    access_log off;

    charset utf-8;
    charset_types
        text/css
        text/plain
        text/vnd.wap.wml
        application/javascript
        application/json
        application/rss+xml
        application/xml;

    gzip on;
    gzip_vary on;
    gzip_min_length 256;
    gzip_proxied any;
    gzip_comp_level 5;
    gzip_types
        application/atom+xml
        application/javascript
        application/json
        application/ld+json
        application/manifest+json
        application/rss+xml
        application/vnd.geo+json
        application/vnd.ms-fontobject
        application/x-font-ttf
        application/x-web-app-manifest+json
        application/xhtml+xml
        application/xml
        font/opentype
        image/bmp
        image/svg+xml
        image/x-icon
        text/cache-manifest
        text/css
        text/plain
        text/vcard
        text/vnd.rim.location.xloc
        text/vtt
        text/x-component
        text/x-cross-domain-policy;

    include sites-enabled/*;
}

plex.conf

server {
    listen 144.76.xx.xxx:80;
    listen 144.76.xx.xxx:443 ssl;
    server_name plex.example.com;
    send_timeout 2h;
    ssl_buffer_size 16k;

    location / {
        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 X-Robots-Tag none;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection upgrade;
        proxy_http_version 1.1;
        proxy_buffering off;
        proxy_pass http://127.0.0.1:32400;
    }
}

[sander1]

Flat graph for me too :( For other options e.g. "Last 24 Hours" it doesn't even show a line at zero:

[zmike808]

The issue is due to cloudflare, not nginx. I disabled CF recently since it was actually degrading my performance, and the graph suddenly started functioning.

[sander1]

The issue is due to cloudflare, not nginx. I disabled CF recently since it was actually degrading my performance, and the graph suddenly started functioning.

My Plex server is behind an Nginx proxy, but I've never used it with Cloudflare. Still the graph doesn't work.

[toomuchio]

I'm pretty sure the last commit would have fixed it, I've got no idea otherwise the requests go through fine. Just return 0.

I use PlexPy, so I wont be investing any time into debugging this myself personally.

[zmike808]

The issue is due to cloudflare, not nginx. I disabled CF recently since it was actually degrading my performance, and the graph suddenly started functioning.

My Plex server is behind an Nginx proxy, but I've never used it with Cloudflare. Still the graph doesn't work.

I also have port 32400 open (not blocked via iptables/ufw) and I have remote access enabled.

I've found that plex will usually try to use my custom URLs first, then fall back to remote access if those don't work. Or rather, if you check https://plex.tv/api/resources?includeHttps=1&includeRelay=1&X-Plex-Token= it seems to follow the order of URLs/IPs listed there. So as long as you have your custom URLs listed before the remote access and relay, you should never really have anyone connecting to anything but your reverse proxy.

Oh and I'm running the experimental plex build (version 1.15.0.573) which can be found on the forums. I doubt that is the reason why, but you could give it a shot if you want.

[gdob]

Are you sure your clients are accessing Plex through your reverse proxy? When I tried opening port 32400 with nginx reverse proxy being set up it bypassed the proxy straight away and went to direct connecting to 32400. Maybe they made some changes in the experimental builds that fixed something, as you’re saying.

[sander1]

Opening port 32400 and enabling remote access in Plex (besides your Nginx reverse proxy) will list multiple access URLs in the Plex API. Those URLs are not accessed in the order they are listed. All URLs are tested and the one responding first is being used.

[gdob]

I'm pretty sure the last commit would have fixed it, I've got no idea otherwise the requests go through fine. Just return 0.

I use PlexPy, so I wont be investing any time into debugging this myself personally.

@toomuchio, @leonekmi Could you please explain why were the following three lines added to the config? It was never explained what these accomplish and for me it was working just fine before. I’m truly interested if I’m missing something out.

proxy_set_header Sec-WebSocket-Extensions $http_sec_websocket_extensions;
proxy_set_header Sec-WebSocket-Key $http_sec_websocket_key;
proxy_set_header Sec-WebSocket-Version $http_sec_websocket_version;

developer.mozilla.org says:

The following headers are involved in the WebSocket upgrade process. Other than the Upgrade and Connection headers, the rest are generally optional or handled for you by the browser and server when they're talking to each other.

[toomuchio]

All I can think is when things are played through a reverse proxy Plex can't track the bandwidth usage.

There's no errors in any requests or responses, so the issue isn't here. The request for bandwidth data actually returns a valid json payload with 0.

The check the commit for that header, I didn't notice issues either but the other person did.

I'm closing this.

[hjone72]

I was able to resolve this by setting my upstream server ip to my LAN IP instead of 127.0.0.1.

I think it's related to how Plex is actually monitoring the traffic.

See here

Note: The bandwidth only measures data that actually leaves the server device, whether going out over the local network or remotely. This means that if you use a client/player app on the same machine as the Plex Media Server, that playback won’t generate bandwidth data (since the streaming is local on the same device).

[toomuchio]

I added a note in the last commit so people know about this fix nice work. I didn't notice this until now.

Although this is really an issue with how Plex works, must be ignoring the X-Forwarded-For header.