Unable to remote control other users playback

[sscheib 11]

Hello everybody,

 

I used to be able to remote control other users devices, when they are playing any movie/series from my emby.

Since I moved to the .NET Core version this does not seem possible anymore.

 

See the following screenshot from the dashboard, where two people (I removed the names) are actually watching some series:

 

But actually I can only see my Chromecast:

 

 

I used to see my FireTV, which is also currently running .. 

[Luke 36992]

Hi, check the remote control permissions for your emby user.

[sscheib 11]

Sorry, forgot to mention:

I did this before i posted and both Allow remote control of other users and Allow remote control of shared devices are ticked.

[Luke 36992]

In order to remote control, those devices need to have a web socket connection established with the server. it sounds like they may not have that. is this inside your network or outside?

[sscheib 11]

outside

[Luke 36992]

Https or http?

[sscheib 11]

https

[Luke 36992]

Ok, so you'll want to ensure that the wss:// protocol is able to get through your external domain.

 

You can test internally on devices in your home network to prove that there isn't actually an emby server issue. It's just a matter that something is blocking that traffic and that's why you can't remote control.

[sscheib 11]

This makes no sense to me at all.

Why would the chromecast still appear (even when I am not home), but all other devices don't?

My server is in a datacenter by the way, so I don't have it my LAN.

 

Also I am specifically adressing websockets with these lines in my nginx.conf:

               # Send websocket data to the backend aswell

                proxy_http_version 1.1;

                proxy_set_header Upgrade $http_upgrade;

                proxy_set_header Connection "upgrade";

                proxy_redirect off;

 

So as long as the requests are send on 443 - which they clearly should - I can't see any issue.

 

... or do you send traffic on different ports aswell?! But then again it would make no sense to me, that my chromecast appears in any circumstances .. 

[Luke 36992]

Chromecast is separate and does things differently from other apps. It can only be controlled from the casting apps anyway.

[Luke 36992]

And yes all same port. @@pir8radio may have dinner nginx tips.

[pir8radio 1292]

@sscheib   what does your proxy config look like, I didn't see it posted above?   My server is also in a datacenter and works.

 

 

This is most likely not your issue, but i like using these settings for websocket:

 

     ## WEBSOCKET SETTINGS ##

        proxy_http_version 1.1;

        proxy_set_header Upgrade $http_upgrade;

        proxy_set_header Connection $http_connection;

    }

Edited February 9, 2018 by pir8radio

[sscheib 11]

hello @pir8radio

root@name:~# cat /etc/nginx/nginx.conf
user www-data;
worker_processes 4;
pid /run/nginx.pid;

events {
        worker_connections 768;
        # multi_accept on;
}

http {

        ##
        # Basic Settings
        ##

        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        keepalive_timeout 65;
        types_hash_max_size 2048;
        server_tokens off;

        # server_names_hash_bucket_size 64;
        # server_name_in_redirect off;

        include /etc/nginx/mime.types;
        default_type application/octet-stream;

        ##
        # SSL Settings
        ##

        ssl_protocols TLSv1.2; # Dropping SSLv3, ref: POODLE
        ssl_prefer_server_ciphers on;

        ##
        # Logging Settings
        ##

        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;

        ##
        # Gzip Settings
        ##

        gzip on;
        gzip_disable "msie6";

        gzip_vary on;
        gzip_proxied any;
        gzip_comp_level 6;
        gzip_buffers 16 8k;
        gzip_min_length 1100;
        gzip_http_version 1.1;
        gzip_types text/plain text/css application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml application/json application/x-javascript text/js;

        ##
        # Virtual Host Configs
        ##

        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;
}

root@name:~# cat /etc/nginx/sites-enabled/emby 
server {
        server_name emby.name.com;
        listen 80;

        rewrite ^ https://emby.name.com$request_uri? permanent;
}

server {
        server_name emby.name.com;
        listen 443 ssl http2;
        ssl_certificate                 /etc/letsencrypt/live/emby.name.com/fullchain.pem; # managed by Certbot
        ssl_certificate_key             /etc/letsencrypt/live/emby.name.com/privkey.pem; # managed by Certbot
        ssl_trusted_certificate         /etc/letsencrypt/live/emby.name.com/cert.pem;
        ssl_prefer_server_ciphers       On;
        ssl_protocols                   TLSv1.2;
        ssl_ciphers                     'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
        ssl_session_cache               shared:SSL:10m;
        ssl_dhparam                     /etc/ssl/certs/dhparam.pem;
        ssl_stapling                    on;
        ssl_stapling_verify             on;
        resolver                        8.8.8.8 8.8.4.4 valid=300s;
        resolver_timeout                5s;
        keepalive_timeout               180;
        proxy_hide_header X-Powered-By;
        add_header X-Xss-Protection "1; mode=block";
        add_header X-Content-Type-Options "nosniff";
        add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
        add_header X-Frame-Options "DENY";
        add_header 'Referrer-Policy' 'no-referrer';
        add_header Content-Security-Policy "frame-ancestors name.com emby.name.com;";

        client_max_body_size 1024M;

        location / {
                # Send traffic to the backend
                proxy_pass http://127.0.0.1:8096;
                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;

                # Send websocket data to the backend aswell
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
                proxy_redirect off;
        }
}

Edited February 9, 2018 by sscheib

[Luke 36992]

Thanks @@pir8radio !

[sscheib 11]

erm, well .. still not solved @@Luke

[pir8radio 1292]

erm, well .. still not solved @@Luke

 

comment out your two security policies and see if it works then.  If so you will need to modify to allow www.gstatic.com

 

add_header 'Referrer-Policy' 'no-referrer';

add_header Content-Security-Policy "frame-ancestors name.com emby.name.com;";

[sscheib 11]

comment out your two security policies and see if it works then.  If so you will need to modify to allow www.gstatic.com

 

add_header 'Referrer-Policy' 'no-referrer';

add_header Content-Security-Policy "frame-ancestors name.com emby.name.com;";

Thank you for trying to help!

 

Even if I completely remove all security-related stuff, which is not absolutly necessary it won't work ..

server {
        server_name emby.name.com;
        listen 80;

        rewrite ^ https://emby.name.com$request_uri? permanent;
}

server {
        server_name emby.name.com;
        listen 443 ssl http2;
    ssl_certificate /etc/letsencrypt/live/emby.name.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/emby.name.com/privkey.pem; # managed by Certbot
        ssl_trusted_certificate         /etc/letsencrypt/live/emby.name.com/cert.pem;
        ssl_prefer_server_ciphers       On;
        ssl_protocols                   TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers                     'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
        ssl_session_cache               shared:SSL:10m;
        ssl_dhparam                     /etc/ssl/certs/dhparam.pem;
#       ssl_stapling                    on;
#       ssl_stapling_verify             on;
        resolver                        8.8.8.8 8.8.4.4 valid=300s;
        resolver_timeout                5s;
        keepalive_timeout               180;
#       proxy_hide_header X-Powered-By;
#       add_header X-Xss-Protection "1; mode=block";
#       add_header X-Content-Type-Options "nosniff";
#       add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
#       add_header X-Frame-Options "DENY";
#       add_header 'Referrer-Policy' 'no-referrer';
#       add_header Content-Security-Policy "frame-ancestors name.com emby.name.com;";

        client_max_body_size 1024M;

        location / {
                # Send traffic to the backend
                proxy_pass http://127.0.0.1:8096;
                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;

                # Send websocket data to the backend aswell
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
#               proxy_redirect off;
        }




}

@@pir8radio

Are you absolutly sure, that you can control remote control FireTV sticks?

Because controlling my Chromecast works perfectly fine ..

Also I just started the emby app on my phone and even that is perfectly fine controlable from the webapp ..

 

//EDIT:

Just tested it with all my security settings set again and also that works perfectly fine for the Emby app on my phone.

Edited February 10, 2018 by sscheib

[pir8radio 1292]

We can do some offline testing if you like. Ok me I’ll send u a login to my server, you can create one for me?

Can you include some more screenshots of it working on something vs firetv, not sure I fully understand your issue now.

[sscheib 11]

click on the most left button:

 

 

devices should appear:

 

 

How the **** can this not be a bug, when it is clearly not working for FireTV!

 

Obviously it has nothing to do with my configuration, as all devices - besides FireTV - are working as expected

Edited February 11, 2018 by ebr
Modified for content policy

[Luke 36992]

Hi there, please try to refrain from profanity our family-friendly community.

 

Given how important this feature is, if there were a defect there'd be widespread issue reports here. As I said I think the traffic is just not getting through.

 

What you can try to do is open the browser console debugger, then connect to the emby wep app and monitor the console for wss:// connection failures.

[pir8radio 1292]

Cromecast's will show up for whatever local network you are on, the chromecast portion has nothing really to do with the server.   So if you login to the browser emby at your buddy's house his chromecasts will show up in that dropdown, not the ones at your house.    That list is populated using a local javascript application on the client side.   As to why you do not see FireTv's in your list of "Play On" when one is connected to your server remotely, I cant speak to that, It doesn't appear to be your NGINX config. 

[ebr 14898]

Just to confirm the general feature is functioning:

 

[pir8radio 1292]

Just to confirm the general feature is functioning:

 

 

Do those android devices need to be on the same local network as the remote controller?    Or can I connect to your server and you be able to control my firetv?    I know chromecast is local only.

[ebr 14898]

Ok, so you'll want to ensure that the wss:// protocol is able to get through your external domain.

 

You can test internally on devices in your home network to prove that there isn't actually an emby server issue. It's just a matter that something is blocking that traffic and that's why you can't remote control.

[sscheib 11]

Hi there, please try to refrain from profanity our family-friendly community.

 

Given how important this feature is, if there were a defect there'd be widespread issue reports here. As I said I think the traffic is just not getting through.

 

What you can try to do is open the browser console debugger, then connect to the emby wep app and monitor the console for wss:// connection failures.

I checked that. See the following screenshot: