Plex and Vera LuaUPnP restarts

Community Playground General Discussions
#1

All,

I just wanted to give a heads up that if you have Plex installed on your network and you are experiencing frequent but random restarts of Vera’s Lua engine, it may be due to Plex. For the past couple of weeks, I have been fighting with my Vera unit randomly restarting the LuaUPnP engine and experiencing higher cpu load. I have had my Vera 3 for several years and it’s been pretty rock solid with uptimes in the months. I have many devices and plugins running and my typical cpu load is around 0.10 to .25 with free memory around 70MB+.

Banging my head and being frustrated with the issue, I did solutions like restoring from several different known good backups, disabling plugins and scenes, etc. Nothing solved the issue. On a complete different issue I was experiencing (Configuring OpenHAB), I was having issues with the OpenHAB instance connecting to my Vera. I logged into vera via ssh and issued “netstat -tuapn” to see what active connections are running on my unit. I wanted to see if the OpenHAB instance was attempting any connection to my Vera unit. To my surprise, I noticed that I had several dozen connections in TIME_WAIT from my one windows box running Blue Iris software connecting on port 49451. All of my home automation and security cameras are on a separate VLAN for security and network reasons.

The windows box has no reason to be connecting to my Vera unit (I originally had the blue iris plugin installed, but removed it to see if that was causing my restarts). I logged into my windows box and issued a netstat at the windows command line and noticed dozens (100+) connections in a TIME_WAIT from vera, localhost and other hosts on the VLAN network. Many of the connections are to and from localhost on different ports in the 6000’s. I immediately started stopping services on the windows box one by one seeing which one was causing the flooding of the network. When I finally got to the Plex server service, the current connections started to clear up and no new connections started.

I logged back into my Vera and noticed the connections from the windows box disappeared and my cpu load dropped. It appears that Plex Server was scanning the network via upnp and when it hit Vera, it would time out scanning the services and open a new connection. This would repeat and effectively opening dozens on port 49451 on Vera. This most likely caused LuaUPnP to freak out as the connections maxed out and issued a restart on the service. It also caused the cpu load on Vera to double. It has been over 12 hours and my Vera unit has not restarted the LuaUPnP service. The load on the unit is hovering around 0.20 and memory around 77MB free (96MB including cache). Requests to Vera have also been instant where previously it could be delayed by a few seconds.

To sum it all up, if you are running Plex on the same network as Vera and you are experiencing similar issues to me, this may be the cause. Even if you are not running Plex, but the symptoms are similar, I suggest you log into Vera and issue a netstat to see if something on the network is flooding your Vera unit. Software similar to Plex that scans the UPnP service. If it were not for having issues with OpenHAB (which was a configuration error on my part), I would have not looked at the network connections on Vera and notice that it was being flooded with UPnP requests from the Plex Software and I would still be fighting an unstable Vera unit.

  • Garrett

p.s. some things noticed in the Vera debug logs:

Large amount of requests like the following:

[code]
10 10/26/14 3:29:59.865 luvd_get_info /etc/cmh-ludl/S_SwitchPower1.xml conn (nil) <0x2f414680>
10 10/26/14 3:29:59.866 luvd_open /etc/cmh-ludl/S_SwitchPower1.xml <0x2f414680>
10 10/26/14 3:29:59.881 luvd_get_info /etc/cmh-ludl/S_HaDevice1.xml conn (nil) <0x2f214680>
10 10/26/14 3:29:59.882 luvd_open /etc/cmh-ludl/S_HaDevice1.xml <0x2f214680>

…

UPnPCallbackEventHandler 4 start PIDLOG2 8637 <0x2e8b8680>
10 10/26/14 3:28:26.109 JobHandler_LuaUPnP::HandleUPnPDiscovery1 start device id uuid:2c65274a-51d8-4bfd-9914-dbd229640b02 location http://192.168.22.200:2869/upnphost/udhisapi.dll?content=uuid:2c65274a-51d8-4bfd-9914-dbd229640b02 devtype servtype ptr 0x933060/uuid:2c65274a-51d8-4bfd-9914-dbd229640b02 pMem 0x14b0000/21692416 diff: 13500416 <0x2e8b8680>
10 10/26/14 3:28:26.109 JobHandler_LuaUPnP::HandleUPnPDiscovery1-end recently processed 447 seconds ago <0x2e8b8680>
10 10/26/14 3:28:26.110 UPnPCallbackEventHandler 4 start PIDLOG2 8637 <0x2e8b8680>
10 10/26/14 3:28:26.110 JobHandler_LuaUPnP::HandleUPnPDiscovery1 start device id uuid:2c65274a-51d8-4bfd-9914-dbd229640b02 location http://192.168.22.200:2869/upnphost/udhisapi.dll?content=uuid:2c65274a-51d8-4bfd-9914-dbd229640b02 devtype urn:schemas-upnp-org:device:MediaServer:1 servtype ptr 0x933060/uuid:2c65274a-51d8-4bfd-9914-dbd229640b02 pMem 0x14b0000/21692416 diff: 13500416 <0x2e8b8680>
10 10/26/14 3:28:26.111 JobHandler_LuaUPnP::HandleUPnPDiscovery1-end recently processed 447 seconds ago <0x2e8b8680>[/code]

#2

Interesting, I have Plex running on the same subnet (no fancy VLANs here :stuck_out_tongue: ) and I’ve had no issues. I’ll run a netstat and see if I find something similar.

I did have a similar issue about a year ago with Plex causing my LG smart TV to reboot. Plex acknowledged the problem and eventfully released a patch to fix it. I would submit a ticket with Plex.

#3

Very interesting, I have been experiencing restarts of LUA for many, many months. I had (still have) a support ticket open with Vera and they did much of what you mentioned, however, the problem kept occurring. I’ve been running Plex for many years as it’s my main way to consume my media when I travel (XBMC/Kodi when I’m at home). Anyway… I SSH’d over to my Vera unit and sure enough, I was getting flooded exactly as you said. I shut down both my BlueIris service and Plex and the requests stopped. Next, I re-enabled Plex and blam, flooded again. It appears by by disabling the DLNA server on Plex that I’m no longer getting flooded. I’m a PlexPass member so I’m not sure if this option is available to everyone but it’s under Settings | Server | DLNA → Enable the DLNA server. I also unchecked Enable local network discovery (GDM) but that did not seem to do anything.

I re-enabled my BlueIris service and so far, no flood. I’ll be interested to see how stable my Vera unit is now. Last night, there were 20 restarts of LUA. I may just owe you a number of beverages of your choice :smiley:

#4

The DLNA option is not just for PlexPass members. Seems odd that I’m not having the issue. I’m running version 0.9.9.14 if that helps. Could it be related to the Blue Iris plugin you were both running?

#5

The blue iris plugin was removed from my system a week ago. So that was not the issue. It’s plex dlna flooding the network.

  • Garrett
#6

I’m running 0.9.10.3 – I’ll post tomorrow but I’m not expecting any restarts now
I owe you big @garrettwp making my system reliable again

#7

thanks for the heads up. It explains a few odd things that has been happening recently.

#8

Very nice find!.

While troubleshooting the same instability you were seeing , I actually saw this symptom a couple of months ago when poking around in the Vera. Tons of TIME_WAIT connections to my iMac. I spent a bit of time trying to figure out why my iMac had so many connections to vera , but never tied it back to the Plex server being the cause of the connections and maybe the instability. I have now turned off DLNA on Plex and am confident that this will help.

DLNA interactions with other devices has been a real pain for me and Vera. Last year, realized after almost a year of frustration that the reason my Onkyo receiver had severe network connectivity and stability issues was because of Vera DLNA , now it seems to be Plex was destabilizing Vera.

After all these years, I have yet to see a quality implementation and user experience from DLNA. Just lots of bugs and security vulnerabilities.

#9

My Vera 2 has been restarting every few days for many months. I also run Plex server and am going to go check it out right now.

Will report back…

Edit:

As soon as I turn on the DLNA server in PMS, I get a massive number of connections from my Plex server.

Thank you very much for your post.

#10

Approaching almost 5 days of uptime on my VL… almost a record. I think this nailed my current stability problem. Wish I had followed up months ago when I first saw those connections from my mac running Plex.

#11

Keeping the DLNA server on Plex off has prevented the flood of connections, but my Vera continues to lock-up/reset regularly. I think my next step will be to reset completely to factory defaults and add my devices back minus any customizations I’ve done.

#12

I run a PLEX server don’t have any restart issues, but Do have to restart to fix the issue with my Alarm panel (caddx vis USB to Serial) stopping communication with VERA.

#13

I was still having occasional restarts after shutting off Plex DLNA server. Support indicated it was:

-NetAtmo plugin
-Denon plugin

I asked if there was some feedback I could give to the plugin authors but have not heard back from support yet

I also find that the XBMCstate plugin occasionally causes a restart as well.

It’s too bad we can’t get Vera support actively involved in the forums and to help with the plugins. It’s really one of the huge reasons why I stay with Vera, such a vibrant and helpful community

#14

I’m at my wits end. Going to see about isolating Vera on my Guest Wifi to see how that goes…

#15

My Vera had been rock solid since disabling Plex. No luup restarts since this post.

  • Garrett
#16

I was just looking thru my hard drive trying to figure out what is taking up space and I stumbled on 6GB worth of Plex DLNA Server Neptune logs in %LOCALAPPDATA%\Plex Media Server\Logs. I wondered what could Plex log that much and discovered it all had to do with alarm. So I search for plex and vera and here I am.

Following is in there over and over:

[code]

2
0


<!-- The High Level State of the Partition, representing whether it’s Armed or Disarmed.

     Partition implementations are only required to implement the "Armed" and "Disarmed" states
     since not every Panel provides the ability to "see" the other statuses and reflect
     them to the UPnP consumer.

     Disarmed - The Partition is in an un-armed state, and ready to be Armed.
     Armed - The Partition is currently armed, or in an "away" state.
-->
<stateVariable sendEvents="yes">
  <name>ArmMode</name>
  <dataType>string</dataType>
  <shortCode>armmode</shortCode>
  <defaultValue>Disarmed</defaultValue>
  <allowedValueList>
    <allowedValue>Disarmed</allowedValue>
    <allowedValue>Armed</allowedValue>
  </allowedValueList>
</stateVariable>


<!-- The Detailed state of the Partition, representing whether it's Armed, Disarmed or one
     of the common intermediary states.

     Partition implementations are required to implement the "Armed" and "Disarmed" states,
     corresponding to the State variable above.  Not every Panel provides the required API
     to "see" the other statuses and reflect them to the UPnP consumer.

     Note that some implementations may consider the "ExitDelay" state to be "Armed"
     whilst others may consider them to be "Disarmed".  No association between DetailedArmMode
     and State variables should be assumed by UPnP clients, due to this potential difference.

     Some of the states may be transitional, and no guarantees are provided that the Panel
     will complete any subsequent transition to a corresponding permanent state.  
     UPnP clients should make no assumptions about the "next state" from what is
     immediately presented, since this may be Vendor and/or Implementation specific.

     Some of the states, like Night/NightInstant and Vacation, are included for specific Panel
     vendors like the Elk and may not be present on other Panels.  Control Point authors should
     be prepared to display these DetailedArmMode using an CP-specific visualization (an Icon,
     Translated Text and so-on)

     Disarmed - The Partition is disarmed.
     Armed - The Partition is currently armed, or in an "away" state.
     ArmedInstant - The Partition is currently armed, or in an "away" state, Entry triggers Alarm immediately.
     Stay - The Partition is in an "at-home" state, delays are permitted on Entry doors.
     StayInstant - The Partition is in an "at-home" state, Entry doors trigger Alarm immediately.
     Night - The Partition is in an "at-home, at-night" state, delays are permitted on Entry doors.
     NightInstant - The Partition is in an "at-home, at-night" state, Entry doors trigger Alarm immediately.
     Force - The Partition is in an "away" state, but one or more Zones are open.
     Ready - The Partition is in an un-armed state, and ready to be Armed.
     Vacation - The Partition is currently armed, or in an "away" state.
     NotReady - The Partition is in an un-armed state, but one or more Zones are open.
     FailedToArm - The Partition is in an un-armed state, and an arming attempt just failed.
     EntryDelay - The Partition is currently moving towards the Disarmed state.
     ExitDelay - The Partition is currently moving towards the Armed state.
-->
<stateVariable sendEvents="yes">
  <name>DetailedArmMode</name>
  <dataType>string</dataType>
  <shortCode>detailedarmmode</shortCode>
  <defaultValue>Ready</defaultValue>
  <allowedValueList>
    <allowedValue>Disarmed</allowedValue>
    <allowedValue>Armed</allowedValue>
    <allowedValue>ArmedInstant</allowedValue>
    <allowedValue>Stay</allowedValue>
    <allowedValue>StayInstant</allowedValue>
    <allowedValue>Night</allowedValue>
    <allowedValue>NightInstant</allowedValue>
    <allowedValue>Force</allowedValue>
    <allowedValue>Ready</allowedValue>
    <allowedValue>Vacation</allowedValue>
    <allowedValue>NotReady</allowedValue>
    <allowedValue>FailedToArm</allowedValue>
    <allowedValue>EntryDelay</allowedValue>
    <allowedValue>ExitDelay</allowedValue>
  </allowedValueList>
</stateVariable>


<!-- An indicator of whether the Partition is in Alarm state or not.

  Partition implementations are only required to implement the "None" and "Active"
  states.

  Many alarm systems will "automatically" clear a Alarm state after some, often legally
  mandated, period of time.  If this happens, the Partition should move to the "None"
  state, but also has the option of setting the "AlarmMemory" state.

  None - The Partition is not currently in Alarm, and no prior record of Alarm.
  Active - The Partition is currently showing as an Alarm actively going off.
-->
<stateVariable sendEvents="yes">
  <name>Alarm</name>
  <dataType>string</dataType>
  <shortCode>alarm</shortCode>
  <defaultValue>None</defaultValue>
  <allowedValueList>
    <allowedValue>None</allowedValue>
    <allowedValue>Active</allowedValue>
  </allowedValueList>
</stateVariable>


<!-- An indicator of whether the Partition has Chime mode enabled.

  Some Alarm Systems (DSC, Paradox, GE Caddx) can run in a mode where each Zone
  that's opened will trigger a Chime, or Bell, to ring for a short period of
  time.  This setting is independant of any Armed or Disarmed state of the 
  Partition.

  If the Panel supports intraspection of this property, then the value should
  be brought forward.  Some panels (Paradox) support the setting, but don't
  support the intraspection of the setting.  In these cases, the Partition
  implementation must return "false" for this attribute.

  true - The Partition is in Chime mode, and will ring a Bell when Zones are opened.
  false - Chimes are disabled.  No chime/sound will occur when a Zone is opened.
-->
<stateVariable sendEvents="yes">
  <name>ChimeEnabled</name>
  <dataType>boolean</dataType>
  <shortCode>chimeenabled</shortCode>
  <defaultValue>false</defaultValue>
</stateVariable>


<!-- An indicator of whether the Partition has previously been in an Alarm state.

  Each Panel, has a Panel-specific mechanism through which it will transition/clear
  it's "AlarmMemory" state.

  true - A prior Alarm state occurred, but it has since cleared
  false - No prior Alarm state is known, or the Prior Alarm condition has been cleared.
-->
<stateVariable sendEvents="yes" allowRepeats="yes">
  <name>AlarmMemory</name>
  <dataType>boolean</dataType>
  <shortCode>alarmmemory</shortCode>
</stateVariable>


<!-- An indicator of when the Partition last entered "Active" state.

  Not all Alarm systems support the information necessary to know that a Alarm has been
  "reset" distinctly from it being "cleared" by some automated means.

  If any implementation returns "Memory", for Alarm, then it must supply a non-Zero
  value for this StateVariable.

  0 - Default value if "Memory" is not supported, or if no prior record of Alarm.
  TODO: represented as seconds past epoch???
-->
<stateVariable sendEvents="yes">
  <name>LastAlarmActive</name>
  <dataType>ui4</dataType>
  <shortCode>lastalarmactive</shortCode>
  <defaultValue>0</defaultValue>
</stateVariable>


<!-- The Last User to initiate an event against the Partition.

  An Alarm-specific string representing the "User" who last initiated a command against
  the Partition (typically, but not necessarily) via a Keypad input to the Panel.

  Partitions that don't support the notion of "Users" should leave this blank.

  A Partition implementation may choose to blank-out the value of this stateVariable,
  after any time period that seems reasonable, to meet local security requirements.
-->
<stateVariable sendEvents="yes" allowRepeats="yes">
  <name>LastUser</name>
  <dataType>string</dataType>
  <shortCode>lastuser</shortCode>
  <defaultValue></defaultValue> 
</stateVariable>


<!-- The Vendor Status (label) indicated by the Partition.

  An Alarm/Vendor-specific string representing the Human readable "Status" last indicated
  by the Partition.

  This string may also show the Last status (label) of the Alarm Panel, and can be used
  by UPnP Clients to display "progress" or current state.

  eg. "Password not valid", "George's home is Arming", "Zones in Bypass 003, 004"

  A Partition implementation may choose to blank-out the value of this stateVariable,
  after any time period that seems reasonable, to meet local security requirements.

  The string value is intended to be Human readable, as it may be presented within
  a UPnP client's native display.
-->
<stateVariable sendEvents="yes" allowRepeats="yes">
  <name>VendorStatus</name>
  <dataType>string</dataType>
  <shortCode>vendorstatus</shortCode>
  <defaultValue></defaultValue>
</stateVariable>


<!-- The Vendor Status Code indicated by the Partition.

  An Alarm/Vendor-specific string representing the internal Status "code" last
  indicated by the Partition.

  This string may also show the Last status (label) of the Alarm Panel, and can be used
  by UPnP Clients to display "progress" or current state.

  These can also be used by "events" to provide Partition-specific mechanisms to
  trigger things like "Fail to Arm" events and the like.

  eg. "1378" (Elk) - "Rule Triggered Voice Telephone Dial"
  eg. "658" (DSC) - "Keypad Lock-out"
  eg. "040" (Paradox) - "Fail to Communicate on telephone Number"

  A Partition implementation may choose to blank-out the value of this stateVariable,
  after any time period that seems reasonable, to meet local security requirements.

  The string value is intended to be used for Vendor specific scripting purposes.  Consult
  your specific Vendor for the set of Valid Vendor Status codes.
-->
<stateVariable sendEvents="yes" allowRepeats="yes">
  <name>VendorStatusCode</name>
  <dataType>string</dataType>
  <shortCode>vendorstatuscode</shortCode>
</stateVariable>


<!-- The Vendor Status Data for the Vendor Status Code.

  An Alarm/Vendor-specific string representing the internal state "data", associated with
  the Vendor Status Code above.

  The string value is intended to be used for Vendor specific scripting purposes.  Consult
  your specific Vendor for the set of Valid Vendor Status data.
-->
<stateVariable sendEvents="yes" allowRepeats="yes">
  <name>VendorStatusData</name>
  <dataType>string</dataType>
  <shortCode>vendorstatusdata</shortCode>
</stateVariable>
#17

Same thing happened to me - 5GB log file. Several Vera items repeating throughout. I just disabled DLNA on my Plex Media Server and deleted the huge log file. I’ll keep an eye on it to see if it grows again!

#18

I’m having the same problem, even with DLNA disabled on the Plex server, and it seems it’s not just Plex, eg.

http://forum.micasaverde.com/index.php/topic,33382.msg249184.html#msg249184

I’m not getting restarts, just timeouts, and slow running scenes from the browser / web page. Did anyone find any other solution to running them both?

#19

For the last few years I have run my Vera on a separate network/vlan off my router. Thus it has no UPNP/DLNA broadcast to deal with . Since I have done this, my Vera has been quite stable. Minimal restarts, performance has been consistent, and overall made me almost forget about my vera. I would highly recommend giving this a try.

#20

Do I need extra hardware for that? My router doesn’t seem to have any vlan settings. Would it easier to chuck in another cheap router just for the Vera, or would I need to have a better one with vlan support?