When using rclone cache / mount with Plex integration, I’m getting the following error spamming my logs every 1-3 seconds:
2018/04/01 13:36:02 INFO : GoogleCache: Connected to Plex server: https://10.10.10.11:32400
2018/04/01 13:36:02 ERROR : plex: websocket.Dial ws://10.10.10.11:32400/:/websockets/notifications?X-Plex-Token=---redacted---: unexpected EOF
Some things that may be relevant:
Plex itself is running in an LXC container at the IP address indicated above. The IP address is accessible and port 32400 is available with SSL-only enabled (http access fails). The rclone mount service is on the host (10.10.10.254) and passed through to the container.
My rclone.conf has “Google” connected to my Google Drive, “GoogleCache” caching “Google” and “GoogleCrypt” being used as the mount of “GoogleCache.” IE: Google --> GoogleCache --> GoogleCrypt
Plex is otherwise working and so is playback. Does this error mean that something is incorrectly configured or to be expected with the current beta release of post-1.40?
No, the only way to Plex’s service is via the LAN at 10.10.10.11:32400 -or- via the Internet via https://publicip:8443 (which the firewall points to 32400 on 10.10.10.11). Obviously, on the Plex server itself, 127.0.0.1 also works.
@CyberCrime - That was a good suggestion. I checked and the token had changed. However, even with the now-corrected token, I’m still getting the same error message (with a different token shown in the logs, of course). Even after stopping/starting a few times (and the token has remained constant), I’m still seeing the “unexpected EOF” messages.
Well, it looks to be a bug (or undocumented feature).
http://10.10.10.11:32400 works if I set Plex to “secured connections: preferred”. If “secured connections: required” is set, https must be used and is apparently unsupported for this feature.
If I had to guess, it’s probably related to the fact the https certificate is the plex.tv autogenerated domain for your server, and the ip address isn’t valid for that.
I had the same issue with tautulli connections, you can’t enable https connections unless you have your own reverse proxy sitting infront of plex.
Correct. Serving an HTTPS page requires you to have a certificate with it, typically issued by a trusted party for your service and installed with your web server (or in this case, Plex server). Your most common clients (browsers, cli, rclone too) will not connect to a HTTPS page without one (browsers for example will panic a lot about this): https://8.8.8.8 (google page).
There is probably a way to disable this check but I’m inclined to not do it simply cause it’s not a good and secure practice.
@remus.bunduc - That’s probably exactly what’s happening. My setup is a bit more complex than most in that the SSL between the client and the Plex server is handled by CloudFlare and CloudFlare is pulling from Plex over HTTPS but doesn’t care whether the certificate is self-signed or not (or even matches the name). The key here is encryption, not authentication of source/target data.
I could always install a certificate on the server as well, but Letsencrypt isn’t going to let you get a local/non-public domain. This can be tricked using creative DNS or host entries, but I’ll keep it on http for now since this seems to work and doesn’t add a ton of complexity.
A suitable alternative is to simply add a flag that will allow the Plex listener (standard http client) to connect to an invalid https end point (with a default “no”)
If you want, add an issue about it or a PR but I personally will have time for it a bit later.