Unable to remote control other users playback

[sscheib 11]

@@Luke

I completely opened my firewall to see if that helps - no it doesnt.

Any ideas?

[Luke 42077]

For simplicity's sake, can you test this over http and offer comparison results? 

[sscheib 11]

Hello @@Luke,

 

I just wanted to try out the new emby google home app and it turns out that won't work as well.

When trying to select a default player (which happens when starting the app the first time) it will tell me:

I could not find any Emby player available. Make sure the player you want to use is logged in with or available to your Emby account.

 

Still: I am guessing this is something buggy on your end when using custom (valid! - LetsEncrypt) SSL certificates

Have you ever tried to reproduce this error on your end? I am absolutly not willing to transfer any content over HTTP.

 

Thank you very much.

 

Regards,

Steffen

[Luke 42077]

Yes I've test remote control over https constantly and haven't seen any problems.

 

@@pir8radio would you concur?

[pir8radio 1312]

Yes I've test remote control over https constantly and haven't seen any problems.

 

@@pir8radio would you concur?

 

Dunno, I run https, through two reverse proxies, and remote control works for me.     In this demo, my server is in a data center, the screen on the left is my office desktop, and the screen on the right is my home theater PC through teamviewer (three different locations between remote, server, and client).   You can see that remote control works with FireTv (image below might take a second to load up)

 

 

@@sscheib , add this to your nginx config and see if anything changes:

    proxy_connect_timeout 1h;
    proxy_send_timeout 1h;
    proxy_read_timeout 1h;

Edited May 22, 2018 by pir8radio

[pir8radio 1312]

Hello @@Luke,

 

I just wanted to try out the new emby google home app and it turns out that won't work as well.

When trying to select a default player (which happens when starting the app the first time) it will tell me:

I could not find any Emby player available. Make sure the player you want to use is logged in with or available to your Emby account.

 

Still: I am guessing this is something buggy on your end when using custom (valid! - LetsEncrypt) SSL certificates

Have you ever tried to reproduce this error on your end? I am absolutly not willing to transfer any content over HTTP.

 

Thank you very much.

 

Regards,

Steffen

 

See this post: https://emby.media/community/index.php?/topic/59498-34110-web-socket/?p=583364

Do you still have the remote control issue when using this beta?

[sscheib 11]

@pir8radio:

I havent tried this beta, however tried the release 3.5.1.0 - is this fixing the issue as well? (@Luke)

[Luke 42077]

To be fair I was never considering it an issue, rather something in your setup causing it to drop. But yes please try it. Thanks.

[sscheib 11]

Alright, I finally found the issue (in case anybody ever has the same problem).

Appearently ICMP needs to be enabled on the server for this feature to work - dropping ICMP packets via iptables will result in the function not working (besides using a Chromecast).

[Luke 42077]

Thanks for the feedback.

[pir8radio 1312]

Alright, I finally found the issue (in case anybody ever has the same problem).

Appearently ICMP needs to be enabled on the server for this feature to work - dropping ICMP packets via iptables will result in the function not working (besides using a Chromecast).

 

Humm  I block ICMP and it works for me..   Strange.

Edited August 2, 2018 by pir8radio

[sscheib 11]

... or it was the last version fixing this issue. Let me quickly try blocking ICMP.

 

//EDIT

Alright, seems to be the last version fixing this issue. Dropping ICMP works just fine.

Edited August 2, 2018 by sscheib

[pir8radio 1312]

... or it was the last version fixing this issue. Let me quickly try blocking ICMP.

 

//EDIT

Alright, seems to be the last version fixing this issue. Dropping ICMP works just fine.

 

Cool, thanks for the update!