KarmaPolice 16 Posted July 16, 2017 Share Posted July 16, 2017 (edited) 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 July 16, 2017 by KarmaPolice Link to comment Share on other sites More sharing options...
KarmaPolice 16 Posted July 18, 2017 Author Share Posted July 18, 2017 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 More sharing options...
Angelblue05 4130 Posted July 18, 2017 Share Posted July 18, 2017 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 More sharing options...
pir8radio 1292 Posted July 18, 2017 Share Posted July 18, 2017 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"; 1 Link to comment Share on other sites More sharing options...
KarmaPolice 16 Posted July 21, 2017 Author Share Posted July 21, 2017 (edited) 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 July 21, 2017 by KarmaPolice Link to comment Share on other sites More sharing options...
Angelblue05 4130 Posted July 21, 2017 Share Posted July 21, 2017 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 More sharing options...
pir8radio 1292 Posted July 21, 2017 Share Posted July 21, 2017 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. 1 Link to comment Share on other sites More sharing options...
KarmaPolice 16 Posted July 22, 2017 Author Share Posted July 22, 2017 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? 1 Link to comment Share on other sites More sharing options...
KarmaPolice 16 Posted July 22, 2017 Author Share Posted July 22, 2017 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 More sharing options...
pir8radio 1292 Posted July 22, 2017 Share Posted July 22, 2017 (edited) 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 July 22, 2017 by pir8radio Link to comment Share on other sites More sharing options...
Angelblue05 4130 Posted July 22, 2017 Share Posted July 22, 2017 (edited) Can you move the thread to that forum? Done. Are you able to edit your thread title? Edited July 22, 2017 by Angelblue05 Link to comment Share on other sites More sharing options...
KarmaPolice 16 Posted July 22, 2017 Author Share Posted July 22, 2017 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 1 Link to comment Share on other sites More sharing options...
Angelblue05 4130 Posted July 22, 2017 Share Posted July 22, 2017 Doh! @@Happy2Play can you move the thread? Sent from my iPhone using Tapatalk Link to comment Share on other sites More sharing options...
KarmaPolice 16 Posted July 22, 2017 Author Share Posted July 22, 2017 (edited) 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 July 22, 2017 by KarmaPolice 1 Link to comment Share on other sites More sharing options...
Angelblue05 4130 Posted July 22, 2017 Share Posted July 22, 2017 (edited) 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 July 22, 2017 by Angelblue05 Link to comment Share on other sites More sharing options...
pir8radio 1292 Posted July 22, 2017 Share Posted July 22, 2017 (edited) 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 July 22, 2017 by pir8radio Link to comment Share on other sites More sharing options...
KarmaPolice 16 Posted July 22, 2017 Author Share Posted July 22, 2017 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: Requires configuration of server directives for everything instead of location directives (more nginx config) 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 Requires configuration of DNS entries (something location directives don't)... 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. 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 More sharing options...
pir8radio 1292 Posted July 22, 2017 Share Posted July 22, 2017 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 More sharing options...
KarmaPolice 16 Posted July 22, 2017 Author Share Posted July 22, 2017 (edited) 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 July 22, 2017 by KarmaPolice 1 Link to comment Share on other sites More sharing options...
Angelblue05 4130 Posted July 22, 2017 Share Posted July 22, 2017 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 More sharing options...
Angelblue05 4130 Posted July 22, 2017 Share Posted July 22, 2017 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 More sharing options...
KarmaPolice 16 Posted July 22, 2017 Author Share Posted July 22, 2017 (edited) 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 July 22, 2017 by KarmaPolice 1 Link to comment Share on other sites More sharing options...
KarmaPolice 16 Posted July 22, 2017 Author Share Posted July 22, 2017 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 2 Link to comment Share on other sites More sharing options...
Angelblue05 4130 Posted July 22, 2017 Share Posted July 22, 2017 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 More sharing options...
pir8radio 1292 Posted July 23, 2017 Share Posted July 23, 2017 (edited) 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 July 23, 2017 by pir8radio 1 Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now