After switching to Plex Pass PMS is constantly utilizing one core (version 1.14.1.5488)

Hi @ChuckPa, also running OpenWRT (custom build based on 18.06) with miniupnpd - 2.1.20180706-1 on a Linksys WRT32X here. NAT-PMP is enabled and UPnP is now disabled. Minupnpd is the standard UPnP daemon across all openwrt builds and has been for many years. There are a lot of commercial router firmwares based on OpenWRT so many users will be running it and perhaps not realising.

This behaviour in PMS when miniupnd is active on the LAN with UPnP enabled (not NAT-PMP) only appeared with the 1.14.1.5488 and 1.15.x builds. It’s reproducible on those builds and goes away when 1.14.5470 is installed instead.

As I have stated, I have submitted the issue to Engineering.
Until such time as I am looped into the discussion, there’s nothing more I can add here

Last bit of additional info from me for a while, hopefully: feedback from the OpenWrt forums indicate that at least the Turris Omnia and Gl-Inet commercial routers are also based on OpenWrt (in addition to a number of Linkysys and Ubiquiti devices and all the derivative firmwares such as Gargoyle, Tomato, DD-WRT, etc.).

The current package maintainer of miniupnpd in the OpenWrt project is Kevin ā€˜ldir’ Darbyshire-Bryant ldir@darbyshire-bryant.me.uk as per the makefile at: https://github.com/openwrt/packages/blob/openwrt-18.06/net/miniupnpd/Makefile

As before, I’m more than happy to carry out testing or provide more info if engineering want it. I’m keen to see this get fixed as I’ve since discovered that disabling UPnP broke Remote Play on my PS4 (ports now manually forwarded).

Here’s another user suffering the same issue but with miniupnpd running on a debian router: 1.14.1.5488 is maxing out my MacBook Pro's CPU 24/7

Interesting to see that it’s not limited to the OpenWrt build of miniupnpd, and also affecting non-OpenWrt installs. miniupnpd is, obviously, the common factor here.

I’m really curious to know what PMS started doing differently to get so upset by this particular UPnP implementation in it’s most recent releases as it’s worked flawlessly with miniupnpd for years now.

I can confirm this behaviour is still present in the beta release 1.15.0.647 (and so see no reason it’ll be fixed in the production release):

  • upgrade to 1.15.0.647
  • turned on UPnP
  • saw Plex Media Server process go to 100% CPU within a second or two
  • turned off UPnP, no change in CPU usage
  • restarted Plex, CPU usage returned to normal

Plex 1.15.0.647 running on XPEnology server (based on Synology DSM 6.2-23739 Update 2) with a Linksys WRT32X running davidc502’s custom OpenWrt build (r9028). LAN is NAT’d IPv4 and routed IPv6 /64.

I’ve hit this in 1.14.1.5488 and 1.15.0.647. I’ve been keeping old self-built 1.14.0.5470 packages around to work around this for a long time now. It’s an Arch Linux host acting as a router and server, running miniupnpd v2.1.20180706. I can confirm the same behavior @gary_parker mentions above.

1 Like

Clarification please?

This is on Arch Linux?

what are the versions of libssdp please?

[chuck@lizum /.240]$ ls /lib*/*ssdp*
/lib64/libgssdp-1.0.so.3@  /lib64/libgssdp-1.0.so.3.0.1*
[chuck@lizum /.241]$ 


I think it’s sorted in 1.15.0.659 beta!!!

I’ve restarted minupnpd a number of times now, with UPnP turned on and off and also restarted the Plex service and, beyond the first time after upgrade, it’s never gone 100% CPU. I think this may be the fix! :sunglasses:

  • edit

Gah, spoke too soon. Rebooted my router and PMS is back to its old tricks. Sorry :pensive:

I have requested system info.

Lib file versions and distro/version please.

it’s helpful to @ the user in question. Hopefully @neunon will reply then.

The question is applicable to all seeing this issue.

@ChuckPa Up to date ArchLinux, running the latest Plex 1.15 server. Here are my libgssdp versions

[urbenlegend@server01 ~]$ ls /lib*/*ssdp*
/lib64/libgssdp-1.0.so        /lib/libgssdp-1.0.so
/lib64/libgssdp-1.0.so.3      /lib/libgssdp-1.0.so.3
/lib64/libgssdp-1.0.so.3.0.1  /lib/libgssdp-1.0.so.3.0.1

Thanks.

Now for the bad news. We’ve never tested on, packaged for, nor support Arch.

I can only suggest you contact whomever did.

Sorry to take this posture right now but I have much bigger issues to deal with than a non-offcially supported distro.

@ChuckPa
I have that issue on linuxserver.io docker image as well as on my Nvidia SHIELD TV. I haven’t tried the latest beta build.

running ls /lib*/*ssdp* on my SHIELD yields no results, so I have tried ls /system/lib*/*ssdp*

foster:/ $ ls /system/lib*/*ssdp*
ls: /system/lib*/*ssdp*: No such file or directory

And same results on Docker.

root@DiskStation:/# ls /lib*/*ssdp*                                                                                                                                                                                
ls: cannot access '/lib*/*ssdp*': No such file or directory

No Arch Linux here. Im using linuxserver.io docker on Unraid 6.6.6. running your ls command on either the server or docker both result in ā€˜No such file or directory’.

However judging by the posts on this page the system that Plex is running on is completely unrelated, if your router is running miniupnpd you will run into this issue.

1 Like

That’s correct. Miniupnpd is a primary cause just as out-of-rev SSDP libraries from all I can gather.

As stated previously, I have submitted to Engineering for further investigation and resolution.

Apologies, I thought you were requesting Lib file versions and distro/versions from all seeing the issue.

Sorry @ChuckPa, I thought you were specifically requesting the data from @neunon regarding his Arch Linux installation, as opposed to everyone reading the thread and experiencing the problem. You weren’t clear on that.

I’m seeing nothing matching ā€˜*ssdp*’ in the specified folders on my XPEnology machine running Synology firmware ā€˜DSM 6.2-23739 Update 2’.

A little further digging shows that Synology uses minissdpd which, interestingly, is coded by the same person who wrote and maintains miniupnpd. The packages are complementary and designed to operate one with the other.

I appreciate you can’t fix this Plex bug yourself, and have much bigger issues to deal with, but thanks for continuing to act as a conduit between those of us on disparate platforms (not just Arch) encountering this issue, and engineering.

As always, I’m happy to respond to any and all requests for further information and testing. Thanks for all your help thus far.

Another commercial router platform to add to the list: http://evenroute.com uses a re-skinned OpenWrt for their IQrouter product.

@ChuckPa

Sorry to take this posture right now but I have much bigger issues to deal with than a non-offcially supported distro.

I understand completely from a support perspective and I’d like to first of all thank you for helping us with this issue.

However, this got me thinking about whether this happened on supported distros as well, so I spun up a Fedora 29 machine I had lying around and installed a new Plex server with zero libraries and configuration whatsoever. I didn’t even claim it and make it publicly accessible. I then re-enabled UPnP on my OpenWRT router and sure enough the issue is still present even in Fedora. Plex Media Server is hitting a single core at 100%.

This issue seems to be hitting a wide variety of platforms including supported ones.

For reference, on my Fedora machine the output of ls /lib*/*ssdp* is:

/lib64/libgssdp-1.0.so.3  /lib64/libgssdp-1.0.so.3.0.1
1 Like