Plugin polling server every 6 seconds?

[graphixmaker 2]

I currently have emby 3.0.64 installed on a remote ubuntu server that is behind a reverse proxy using nginx. I've noticed a lot of traffic coming from my house and when I checked the nginx access log it appears the kodi plugin is hitting the server every six seconds with the same request. This seems to run 24 hours a day as long as kodi is left on. My reverse proxy is using the location /emby after the web address in line with what I read here on the forum about the plugin adding that to the end of its requests.

 

I'm assuming this is the plugin attempting to sync, but I can't tell. I have noticed that since I switched to SSL, when I delete a movie or episode it successfully deletes it on the server, but does not refresh it in kodi until I do a manual sync. I assumed that this was because I was using a self signed certificate but now I'm using a certificate from letsencrypt and it still does it. The library does not sync in the background any longer, only a restart of kodi, or a manual sync works. This is the case whether I have fast syncing turned on or not.

 

You'll notice in the access log the constant polling begins with /?api_key and not /emby?api_key so I thought that may be an issue. I'm using kodi 16.1 and my embassy plugin is 2.2.19. 

 

Is this normal behavior? My host is seeing the traffic and flagging it like its a bot or malware so i need to find a way to stop it, or slow it down at least.

 

access.log

kodi.log

[pir8radio 1292]

If it is a websocket issue, make sure your nginx config contains:

        proxy_http_version 1.1;

        proxy_set_header Upgrade $http_upgrade;

        proxy_set_header Connection "upgrade";

 

On a side note, how do you like OVH?

Edited September 5, 2016 by pir8radio

[Angelblue05 4130]

You'll notice in the access log the constant polling begins with /?api_key and not /emby?api_key so I thought that may be an issue. I'm using kodi 16.1 and my embassy plugin is 2.2.19. 

There is no such thing as /emby?api_key

 

We have either ?api_key or /embywebsocket?api_key

Edited September 5, 2016 by Angelblue05

[pir8radio 1292]

There is no such thing as /emby?api_key

 

We have either ?api_key or /embywebsocket?api_key

 

"My reverse proxy is using the location /emby"

 

OP may want to reverse proxy the root then..  lose the /emby

[graphixmaker 2]

 

If it is a websocket issue, make sure your nginx config contains:

        proxy_http_version 1.1;

        proxy_set_header Upgrade $http_upgrade;

        proxy_set_header Connection "upgrade";

 

On a side note, how do you like OVH?

 

 

I had the issue with the playback not functioning when I first used nginx, however a bit of research did lead me to this solution. My config currently looks like this.

location /emby {
                # Send traffic to the backend
                proxy_pass http://***.***.***.***:8096/emby;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-for $proxy_add_x_forwarded_for;
                proxy_set_header Host $host;
                proxy_set_header X-Forwarded-Proto $remote_addr;
                proxy_set_header X-Forwarded-Protocol $scheme;
                proxy_redirect off;

                # Send websocket data to the backend as well
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";

There is no such thing as /emby?api_key

 

We have either ?api_key or /embywebsocket?api_key

 

 

I don't see any /embywebsocket?api_key anywhere in the nginx log, I only see /?api_key and /emby?api_key so is there a configuration issue I'm not aware of? I have the settings for the plugin set to:

 

www.************.org

port 443

enable https  checked

verify host certificate  yes (I have a valid cert)

[Angelblue05 4130]

Yeah, because we don't use /embywebsocket?api_key. I was just letting you know there's no /emby?api_key - it doesn't exist and therefore is not an issue.

 

We do ping the server every 10 seconds, to keep the connection alive - as previously, when we didn't it would terminate the connection and you'd stop receiving updates for your client.

[graphixmaker 2]

 

On a side note, how do you like OVH?

 

 

 

I'm using online.net with one of their dediboxes. It's been great up until the point I've experienced some traffic issues which I'm starting to believe is associated with this constant request. It has a 2.5Gbps backbone and I'm using it for emby, couch potato, sick rage, nzbget and headphones. All media is consumed through two mac mini's running kodi and a bunch of iOS devices with the iOS app. All in all its an amazing setup for cheap. But this traffic issue has me stumped.

[graphixmaker 2]

Yeah, because we don't use /embywebsocket?api_key. I was just letting you know there's no /emby?api_key - it doesn't exist and therefore is not an issue.

 

We do ping the server every 10 seconds, to keep the connection alive - as previously, when we didn't it would terminate the connection and you'd stop receiving updates for your client.

 

When I switched to SSL I stopped receiving the regular updates to the media. I initially thought it was because of my self-signed cert not being able to validate. I wasn't able to use ssl with the iOS apps until I switched to a letsencrypt cert which is working flawlessly.

 

Do you suggest I switch from using the /emby location in nginx? I could use emby.************.org instead I guess. I set it up with multiple /*** locations originally because I was just using an IP.

[pir8radio 1292]

 Yea, I would reverse proxy to the root and loose the /emby that the apps may not be using..    Here is my config if it helps you out at all...    Post if it helps or not, I'm always curious about other peoples nginx setups...  

 

 

     location / {

        proxy_pass http://127.0.0.1:8080;                               # Backend Server

 

        proxy_hide_header X-Powered-By;                            #  hide nginx version

        proxy_set_header Range $http_range;                      #  fix mp4 playback issues

        proxy_set_header If-Range $http_if_range;               #  fix mp4 playback issues

        proxy_set_header X-Real-IP $remote_addr;

        proxy_set_header Host $host;

        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        add_header X-Proxy-Cache $upstream_cache_status;          # you wont need this line

        proxy_http_version 1.1;

        proxy_set_header Upgrade $http_upgrade;

        proxy_set_header Connection "upgrade";

        proxy_set_header Host $host;

    }

[graphixmaker 2]

 

 Yea, I would reverse proxy to the root and loose the /emby that the apps may not be using..    Here is my config if it helps you out at all...    Post if it helps or not, I'm always curious about other peoples nginx setups...  

 

 

     location / {

        proxy_pass http://127.0.0.1:8080;                               # Backend Server

 

        proxy_hide_header X-Powered-By;                            #  hide nginx version

        proxy_set_header Range $http_range;                      #  fix mp4 playback issues

        proxy_set_header If-Range $http_if_range;               #  fix mp4 playback issues

        proxy_set_header X-Real-IP $remote_addr;

        proxy_set_header Host $host;

        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        add_header X-Proxy-Cache $upstream_cache_status;          # you wont need this line

        proxy_http_version 1.1;

        proxy_set_header Upgrade $http_upgrade;

        proxy_set_header Connection "upgrade";

        proxy_set_header Host $host;

    }

 

 

 

I'll check out some of your changes and switch to a subdomain location in the server block. How did you come to use the two lines you reference to "fix mp4 playback."

[pir8radio 1292]

nginx was stripping the range header when passing to/from the backend server..   MP4 playback would act like it wanted to start but just sit there on the client side, downloading the full file...

Edited September 6, 2016 by pir8radio

[graphixmaker 2]

nginx was stripping the range header when passing to/from the backend server.. MP4 playback would act like it wanted to start but just sit there on the client side, downloading the full file...

Ok, switched the server block to use a sub domain and realized I hadn't used that sub domain when my SSL certificate was issued. Reissued the cert, forwarding the root to the backend is working fine.

 

The constant polling in nginx's access log has completely gone away, which tells me the thought on the persistent websocket was correct. I do however have new errors in nginx's error log that weren't there before. A few that seem to show the iOS client searching for "apple-touch-icon.png" in the webroot of nginx, which of course doesn't exist there.

 

Additionally I have a couple "alerts" about open sockets:

 

[alert] 2333#2333 *59 open socket #27 left in connection 10

 

The socket numbers and connection numbers are different bet there are a few.

 

On the plus side the immediate syncing of deleted files and watched states are back.

 

Lastly I added the MP4 playback proxy header lines you use. They actually had the opposite effect of what you described, and for me left the file just hanging at 0% buffer in Kodi. I used to have some issues with mkv files wanting to download instead of stream, but I now use mkclean in a custom script in nzbget post processing to optimize them all for streaming. Since I started that the issues went away.

Edited September 6, 2016 by graphixmaker