The KEX Protocol Error 7 is something I’ve seen appear since 1.17, and it never rose to the top of a topic as the major problem. It tends to appear in complex networking issues, and the time or two that an employee stopped by the threads, they commented that they had noted that error but were focused on something else.
So I don’t know what exactly is wrong with the exchange of keys, nor why that causes the PlexRelay to die and not restart. I would think if the relay died that it can’t create a working Remote Access, but the fact you attached via WAN and downloaded logs is proof that something works.
When you did that WAN connections, did you use app.plex.tv or did you specify your IP address in the url?
Right? I’ve thus far still been unable to figure out why the Synology is responding when I see no configuration present that would speak to it being a default behavior or allow me to adjust it.
My current solution path has been to manually (working on automation) restarting PMS every 24 hours. That clears up the funk, but it’s a bummer to me that it’s even something I have to think about now after years of the beast just running solid in the background.
Let’s hope we get some attention on the kex protocol error or that a new PMS beta comes out. We can then bug report against that effectively. At least for now you have a reboot every day workaround
Annnnnd after a lot of frustration I think I’ve got it. Prevent computer from sleeping automatically when the display is off was unchecked.
On my prior MacMini there was a companion slider for the time interval in which to put the system to sleep (not just the display), and I believe I had that set to Never.
I put too much confidence in the Wake for network access setting thinking that once PMS receives a call remote, or locally, that all services will wake and work as expected. But instead, what appeared to be occurring is that the server was functionally only partly awake and functioning similarly to how I do during the work-week and before my second cup of coffee. The end result being some/all/and not exclusive to time-outs, loss of remote connectivity, and other playback quirks whether local or remote.
From additional investigation, perhaps this could be remedied by updating the codebase to include more definitive assertions, but that’s just a general guess and way outside of my scope of knowledge. If there’s some meat to that, perhaps it might be something worth opening an issue about for the Plex team to review.
tl;dr: Power consumption on my 2018 MacMini is low enough that it need not go to sleep ever, beyond allowing the display output to sleep since the system is not actively monitored outside of remote connectivity. After enabling the Prevent computer from sleeping automatically when the display is off setting PMS has been super snappy both remotely and locally.
The aforementioned curious verbose logging messages earlier in the thread are almost certainly a red-herring and not directly related to my core issue.
I’m not 100% but Enable Power Nap appears conditional upon how one might be using their Mac system if its scope is beyond dedicated PMS. I’ve had it unchecked and things have been working great for over a week of consistent uptime. No need to restart PMS or the Mini itself.
For sure! After taking some time away from it, I got back to researching and found similar symptoms in threads where folks were talking about how their PMS systems were not waking from sleep in the manner they expected.
Since I wasn’t making much progress digging into the networking side of things I shifted gears and visited a premise that I’d previously excluded due to having too much trust that it would “just work”.
It does seem like that there could be some opportunities for wake assertion handling in the PMS software, but in the interim preventing my server from going to sleep is thankfully a very tolerable solution.
Any time I connect outside of my local network I use the plex.tv sign in.
