Jump to content

Not auto-syncing: Cloud Emby, Home Kodi


KarmaPolice

Recommended Posts

KarmaPolice

Help! :)

 

I'm fairly certain this is some kind of network routing issue but i'm not totally sure... here's the situation:

 

Problem: The "auto-syncing" that emby does to the kodi library isn't working. 

 

Things to understand:

 

1)  Connecting to emby from kodi works fine, and i can playback any media

 

2)  Manual sync FROM kodi works... if i do a manual sync through the add-on from kodi, it connects out to emby and gets the most up to date info

 

3)  My cloud based emby is behind an nginx reverse proxy (for everything) so the only way in to the server for emby is through port 443... anything on the server should be able to initiate an outbound connection on whatever port it wants.

 

All of this was working fine when i had emby inside my local network, but since moving it to a cloud dedicated server (which also meant moving it behind the nginx reverse proxy) the syncing hasn't been working... which leads me to...

 

My suspicion: The notification from emby to kodi when there is new content is getting lost at my home router (i've not setup any specific port forwarding rules, so i suspect it doesn't know where to route this traffic to get it to the kodi box in my house)... 

 

Any thoughts or info would be helpful... i've attached the kodi log showing successful syncs and a few errors at other points in time (doubtful they are related to this issue though)... you will see several manual syncs that i initiated from the kodi box to be sure it was connecting at all... 

 

Edit: Cleaned log file

kodi.log

Edited by KarmaPolice
Link to comment
Share on other sites

KarmaPolice

As a temporary workaround i've set a screensaver up and set the setting in my kodi to auto-library-sync on resume from screensaver, this works (though requires the user to wait a few seconds while the sync happens)... Would much rather understand how the communication pathway from emby to the emby-for-kodi sync works though, then maybe i could figure out the firewall/port-forwarding rules to allow it.

Link to comment
Share on other sites

Angelblue05

You could also run a manual sync to get the same result.  Sorry I'm not able to help. It might be worth asking in the server section about enabling the websocket through your firewall. This is how the addon gets updates from the server.

Link to comment
Share on other sites

pir8radio

make sure your nginx config for emby contains the websockets section

     ## WEBSOCKET SETTINGS ## Used to pass two way real time info to and from emby and the client.
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
  • Like 1
Link to comment
Share on other sites

KarmaPolice

 

make sure your nginx config for emby contains the websockets section

     ## WEBSOCKET SETTINGS ## Used to pass two way real time info to and from emby and the client.
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

 

Here's my location block from nginx... and the below isn't allowing it to work... so I don't think that's the issue

    location /emby {
      proxy_pass http://127.0.0.1:8096/emby;
      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 X-Forwarded-By $server_addr:$server_port;
      proxy_redirect off;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
    }

Edited by KarmaPolice
Link to comment
Share on other sites

Angelblue05

I still think you should post in the server forums so the right people can see your post and help you sort this out.

 

 

Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

pir8radio

 

Here's my location block from nginx... and the below isn't allowing it to work... so I don't think that's the issue

    location /emby {
      proxy_pass http://127.0.0.1:8096/emby;
      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 X-Forwarded-By $server_addr:$server_port;
      proxy_redirect off;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
    }

 

 

Oh you are using a /emby      just for a test does it work when you loose the /emby and use a sub domain vs a sub directory?   like emby.yoursite.com/  then change your proxy_pass to http://127.0.0.1:8096      some of the apps do not like the /emby sub directory.  

  • Like 1
Link to comment
Share on other sites

KarmaPolice

I still think you should post in the server forums so the right people can see your post and help you sort this out.

 

 

Sent from my iPhone using Tapatalk

 

Can you move the thread to that forum?

  • Like 1
Link to comment
Share on other sites

KarmaPolice

Oh you are using a /emby      just for a test does it work when you loose the /emby and use a sub domain vs a sub directory?   like emby.yoursite.com/  then change your proxy_pass to http://127.0.0.1:8096      some of the apps do not like the /emby sub directory.  

 

I'll give it a try... never setup a subdomain in nginx though, so will have to research that a bit... 

Link to comment
Share on other sites

pir8radio

I'll give it a try... never setup a subdomain in nginx though, so will have to research that a bit... 

 

its the same in nginx as a sub directory..  Depending on who supplies your domain name you may have to add it there too..  

 

just for server name in nginx you put   emby.myserver.com instead of myserver.com    then your location will be "/"   instead of "/emby"   then your proxy pass will loose the "/emby"   see this post: https://emby.media/community/index.php?/topic/48236-setting-up-emby-behind-a-reverse-proxy-nginx/?p=457670

Edited by pir8radio
Link to comment
Share on other sites

Angelblue05

Can you move the thread to that forum?

Done. Are you able to edit your thread title?

Edited by Angelblue05
Link to comment
Share on other sites

KarmaPolice

Done. Are you able to edit your thread title?

 

Nope... also, this is a linux server, so think you got the wrong server forum... not that it should really make a difference in my opinion, but maybe it will :)

  • Like 1
Link to comment
Share on other sites

KarmaPolice

Ok! now we're getting somewhere @@Angelblue05 (and it looks like this does indeed belong back in the emby-kodi section of the forum)...

 

I opted to install kodi + emby.kodi on my desktop instead of debugging it on the tv-attached chromebox... for whatever reason, i'm now getting a lot more debug info out of the log this way (not sure why, have debug logging turned on in both locations)... 

 

Anyway... now I'm seeing what could be a couple problems in the log file... 

 

Let's start with: 

21:39:35.632 T:14164  NOTICE: EMBY.librarysync -> ---===### Starting LibrarySync ###===---
21:39:35.636 T:9260  NOTICE: EMBY.websocket_client -> websocket url: wss://www.myhost.com:443?api_key=XXXXXXXXX&deviceId=XXXXXXXXXX
21:39:35.636 T:9260  NOTICE: EMBY.websocket_client -> ----===## Starting WebSocketClient ##===----

That seems like a quite incorrect url... i would have expected a /emby in there, maybe even a /websocket?

 

Then later in the log i see a lot of these errors repeated indicating that it is hitting nginx, getting a response, but not the one the plugin is expecting.:

22:29:39.872 T:9260  NOTICE: EMBY.websocket_client -> DEBUG:: Error: Handshake Status 200
22:29:39.872 T:9260  NOTICE: EMBY.websocket_client -> DEBUG:: closed
22:29:45.322 T:9260  NOTICE: EMBY.websocket_client -> DEBUG:: Error: Handshake Status 200
22:29:45.322 T:9260  NOTICE: EMBY.websocket_client -> DEBUG:: closed

Going through the code on github i came across this in resources/lib/websocket_client.py (note the bold, underlined line in particular):

def run(self):

        # websocket.enableTrace(True)
        user_id = window('emby_currUser')
        server = window('emby_server%s' % user_id)
        token = window('emby_accessToken%s' % user_id)
        # Get the appropriate prefix for the websocket
        if "https" in server:
            server = server.replace('https', "wss")
        else:
            server = server.replace('http', "ws")

        websocket_url = "%s?api_key=%s&deviceId=%s" % (server, token, self.device_id)
        log.info("websocket url: %s", websocket_url)

        self._client = websocket.WebSocketApp(websocket_url,
                                              on_message=self.on_message,
                                              on_error=self.on_error,
                                              on_close=self.on_close)
        self._client.on_open = self.on_open
        log.warn("----===## Starting WebSocketClient ##===----")

Looking at some other places in the code... it looks like the /emby/ is pretty much always explictly included, why would it not have been in the websocket url?

url = "{server}/emby/Plugins?format=json"
url = "{server}/emby/Items/%s/Ancestors?UserId={UserId}&format=json" % item_id
return "%s/emby/Users/%s/Images/%s?Format=original" % (self.server, item_id, item_type)

This would seem to indicate that @@pir8radio 's idea of running emby at the domain level would indeed work and it is the /emby directive in nginx reverse proxy that is throwing this all out of whack... however that strikes me as a "hack"/"workaround" and instead it would seem that this one inconsistency should really be fixed in the code to have it build url schemes similar to all the other function calls... 

Edited by KarmaPolice
  • Like 1
Link to comment
Share on other sites

Angelblue05

I don't see how it's a kodi issue. That's how the websocket is. The call is correct. There is no /emby or /websocket.

Edited by Angelblue05
Link to comment
Share on other sites

pir8radio

That seems like a quite incorrect url... i would have expected a /emby in there, maybe even a /websocket?

Then later in the log i see a lot of these errors repeated indicating that it is hitting nginx, getting a response, but not the one the plugin is expecting.:

 

Going through the code on github i came across this in resources/lib/websocket_client.py (note the bold, underlined line in particular):

Looking at some other places in the code... it looks like the /emby/ is pretty much always explictly included, why would it not have been in the websocket url?

 

 

This would seem to indicate that @@pir8radio 's idea of running emby at the domain level would indeed work and it is the /emby directive in nginx reverse proxy that is throwing this all out of whack... however that strikes me as a "hack"/"workaround" and instead it would seem that this one inconsistency should really be fixed in the code to have it build url schemes similar to all the other function calls... 

 

 

I don't see how it's a kodi issue. That's how the websocket is. The call is correct. There is no /emby or /websocket.

 

 

Angelblue is correct, emby is designed to be ran without a reverse proxy and everything works WITHOUT a reverse proxy.   The /emby was added to emby server as a hack to fix incorrectly configured reverse proxies.  I don't necessarily agree with the addition, it causes confusion when things like this come up, I personally think people should fix their reverse proxies.   The best way is to use a sub domain, that way you feed a url to the server and applications that they expect to see when not running a reverse proxy.  A reverse proxy should be transparent to the clients and applications running behind it. 

 

BUT if you must use a sub directory you can use rules to add /emby to the clients request which could cause some issues.

 

Do you have other services running behind nginx?    You can use rewrite rules, or sub_filter rules to get away with this, but its going to cause you headaches. 

Edited by pir8radio
Link to comment
Share on other sites

KarmaPolice

The issue is the inconsistency, not the fact that there is no /emby in the wss url... applications with web-services should strive for consistency in their URL schema for exactly reasons like being behind reverse proxies (which by the way, any web-service/web-app DESIGNED to be run without a reverse proxy are not well designed in 2017, and I would strongly challenge that assertion anyway considering the amount of code clearly put in specifically to allow for location based proxying in all other areas of the application) ...

 

I have a slew of other services running behind the same reverse proxy and while admittedly, none of them leverage websockets, they also all have configurations in their settings to allow for configuration of a base-path or don't need one at all, (which is really something emby should implement anyway):

- Sonarr

- Radarr

- Netdata

- SABnzbd

- Jackett

- Deluge

 

On the topic of a subdomain method... supporting such a method is the lowest common denominator for proxying, and works just fine clearly, however with multiple applications on the system you run into a lot of additional configuration by not supporting location based directives:

  1. Requires configuration of server directives for everything instead of location directives (more nginx config)
  2. In the case of emby-for-kodi it apparently also requires re-write rules (something i've gotten away without needing for all those other apps above), which is again more configuration
  3. Requires configuration of DNS entries (something location directives don't)...
  4. Let's Encrypt (free/simplest/easiest provider of SSL certs) doesn't (yet?) support wild-card certificates meaning that too must be re-configured every time you add an application.
  5. SEO (though probably not relevant for these use-cases) treats subdomains as different locations, so you would lose any SEO advantage if you were interested in such things (which admittedly I am not in this case :) )

I hope you're seeing my point that server directives, while definitely a feasible method of reverse proxying, are not the optimal method... 

 

Sufficed to say, as is the case with arguing on the internet, I'm not really expecting anything to change... so I will go about figuring out the appropriate rewrite rules to get it working as it stands and HOPE that someone will hear my call to update the actual source code that knows more about programming and the emby-for-kodi code base than I do.

Link to comment
Share on other sites

pir8radio

It will probably be easier to add a second location block that looks for query strings in the url, then redirects those requests to you emby backend.  Post if you need a hand.

Link to comment
Share on other sites

KarmaPolice

So i ended up just redirecting / to /emby since i didn't have anything at the root location anyway... not an ideal solution, but if i ever want to host something at / then i'll revisit it at that point... 

 

for anyone looking for the answer, I ended up copying the /emby directive from its location to the / location in my nginx server config... so now both /emby and / go to the emby service and this fixes the websocket not connecting... 

 

I still maintain that this is a bug that should be resolved in the "emby for kodi" plugin code (considering everything else in it has a hardcoded /emby uri)... but if the maintainers don't want to go there, at least you have one workaround now... and some idea as to why it's happening if you read this thread.

Edited by KarmaPolice
  • Like 1
Link to comment
Share on other sites

Angelblue05

Let me ask you, are you able to remote control any other apps?

 

Emby for Kodi is the only app that uses the websocket to update the Emby content as a main function. The websocket for other apps is mostly used for remote control purposes (no primary functions).

 

In the Emby webclient, you can select the app to control (top right, square icon). Try sending content to play or pausing or stopping playback. My guess is it won't work, but let me know if it does, and what you tried.

 

 

Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

Angelblue05

The websocket call is what the server requests. I can't fix that :) It's not a bug. If I type /emby then it will never resolve. I hope you understand that this is out of my control, but glad you got it working.

 

 

Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

KarmaPolice

Let me ask you, are you able to remote control any other apps?

 

Emby for Kodi is the only app that uses the websocket to update the Emby content as a main function. The websocket for other apps is mostly used for remote control purposes (no primary functions).

 

In the Emby webclient, you can select the app to control (top right, square icon). Try sending content to play or pausing or stopping playback. My guess is it won't work, but let me know if it does, and what you tried.

 

 

Sent from my iPhone using Tapatalk

 

The "apps" I use:

- Emby for Kodi - everything was playing fine, controlling fine, etc.

- Emby for Android - was able to cast to a chromecast or play on the android phone directly without issue.

- Emby web-browser player - was able to play anything

 

I honestly never tried the workflow you are talking about other than casting to a chromecast which is similar, but i never used the emby functionality of "play to" so i don't know if it was broken or not.

 

The websocket call is what the server requests. I can't fix that :) It's not a bug. If I type /emby then it will never resolve. I hope you understand that this is out of my control, but glad you got it working.

 

 

Sent from my iPhone using Tapatalk

I see, i didn't know it was emby server that was setting that url, though that makes sense now that you mention it since emby-for-kodi is just calling the emby service... my bad there... that said, this just means the issue should really be fixed in emby to allow for a "base-path" setting that changes all services (web-socket or otherwise) to work with a configured location.

Edited by KarmaPolice
  • Like 1
Link to comment
Share on other sites

KarmaPolice

Oh, and just an aside/by-the-way... thank you to both you and pir8radio for being so responsive on the forum... it reaffirms my choice in the community :)

  • Like 2
Link to comment
Share on other sites

Angelblue05

You are not the first to request this for the websocket. If it is ever changed server-side, I will change it in the add-on. :)

 

 

Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

pir8radio

looking at the web gui, emby websockets are requested using the below url.    

using /embywebsocket     which would mean using nginx you could create a /embywebsocket location and direct it directly to the backend ip.   But i guess the add-on does not add this "/embywebsocket" to the request correct?

wss://mywebsite.com/embywebsocket?api_key=xxxxxxxxxxxxxxxxxxxxxxx&deviceId=xxxxxxxxxxxxxxxxxxxxx
Edited by pir8radio
  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...