[SamsungTV] Samsung TV Binding can cause thread lockups. #7978
Comments
|
@J-N-K : could you have a look ? I think it could be a similar problem you fixed for the Amazon Echo Control binding in your PR #7919 . Looking at the code of the SamsungTV binding, the changes you applied to the Amazon Echo Control binding are not applied to the SamsungTV binding, like checking if the websocket client is started before closing it, or your change about closing the session. Your are the expert ;) |
|
@J-N-K , this bounty was originally tied to the jupnp binding but after @lolodomo identify it's really the Samsung binding causing all the issues - I rolled back to SamsungTV binding v2.4 and everything resolved itself. I'd really like to get the Samsung binding up to par since I have different ages of Samsung TV's which the newer binding v2.5.x addresses these differences but as we know the SamsungTV binding itself causes massive issues after time. I'd be glad to award you this bounty if you can fix the issues with the SamsungTV binding. https://www.bountysource.com/issues/80365719-jupnp-failing-causing-devices-to-go-offline Best, Jay |
|
Please try PR with changes has been merged. Use latest 2.5.7-SNAPSHOT |
It's in. I stopped/uninstalled 2.4 RC1 and dropped in yours. It took about 5 minutes for the status of each TV to come online from the unknown state. Here's my thing config of the TV's. Some older models using 55000 and newer models using 8002. The true test is to see if it takes down the Sonos after some time. https://community.openhab.org/t/help-samsung-tv-bindings-with-2016-samsung-tv/67053/58
I'm running OH 2.4 so I don't have some of the new stuff in 2.5.x so this may need to be addressed. Here's the dump after installing it. --> Caused by: java.lang.ClassNotFoundException: org.eclipse.smarthome.io.net.http.TrustAllTrustMananger <--
Best, Jay |
|
Thats intesting. Because the class TrustAllTrustManager was already present in ESH days (so 2.4 should have it, too). Please check if |
Is PID 118 the correct one or am I missing it because it's NOT ending with .http ? `openhab> list -s -t 0 | grep io.net 118 │ Active │ 80 │ 0.10.0.oh240 │ org.eclipse.smarthome.io.net Best, Jay |
|
The http extension is missing. Please install that ( |
Tried install and feature:install and both didn't work. Maybe you can point me to where I can just download/drop in?
Best, Jay |
|
I think the binding your talking about is this one? This one is missing the .net. portion of it. openhab> list -s | grep io.http Best, Jay |
|
No, that’s another one. Unfortunately I‘m on a phone right now and browsing code there is not easy. I‘ll try to look for the correct feature tomorrow. It could be that you need to install a upnp feature, e.g. |
Here's what I have for upnp. openhab> list -s | grep upnp Best, Jay |
|
My fault. |
|
I just rolled it back to SamsungTV 2.4 RC1, I'm seeing the Sonos and WeMo devices going offline/online more than normal again because of the SamsungTV binding. When I rolled it back; all my TV's showed their correct status's immediately. Best, Jay |
It's NOT in the dump below --> TrustAllTrustManager openhab> classes 118 | grep smarthome Best, Jay |
|
You are right. This class exists since ESH 0.11.0, OH 2.4 is based on ESH 0.10.0. So you might run into bigger problems trying to update that bundle only. I'm sorry. Why don't you use 2.5? |
|
My 2.4 is incredibly stable. I'm also running on a Synology HA platform which makes it a little more difficult to upgrade. I've seen so many issues with 2.5.x being posted over the last year which scares me to even try. I started on OH 2.3 two years ago. I have a very large OH setup which consists of 30+ WeMo's, 40+ HUE Lights, 30+ zWave devices, 15 Echo's, 14 Sonos's, 2 Ecobee's, MQTT tied to a Roomba, 8 Samsung TVs, etc. I have 2500 lines in one master .item file and 28,000 lines in one master .rules file. Is there anyway to just drop a specific .JAR into my OH 2.4 to get those classes? 85% of my bindings I'm running are dropped in with v2.5.x levels. Best, Jay |
|
So - to report back from my side - we're about 10 hours in with the new JAR. So far - no lockups. I have two TVs - an older 2010 C650 and a newer NU8000. Both are being detected online/offline. The NU8000 isn't providing any further information - e.g. no channel/source (but I'm not convinced it ever did). I haven't done a proper check on the C650 yet. |
|
@MPH80 is ten hours an improvement? If it is, we should merge that, even if it is not a final fix for everything. It may well be that there is more than one issue that look the same. |
|
@jaywiseman1971 understood. You could try exchanging the bundle, I can look up what the correct one is, bit you may run into difficulties. |
|
Yes, please. I will give it a try. Best, Jay |
|
You‘ll probably need to restart after that. But do not clean cache, it would revert the updated bundle. |
|
Dropped in thinking it would go from Installed to Active. I even did a fresh restart of OH but it didn't. I'm still running the SamsungTV 2.4 RC1 version. openhab> list -s | grep io.net If I drop in the new Samsung binding above in; will that activate the org.openhab.core.io.net binding? EDIT: 2020-06-27 19:33:16.754 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/volume1/homes/openhab/addons/org.openhab.core.io.net-2.5.0.jar Best, Jay |
|
That‘s what I meant. You‘ll draw in a bunch of other dependencies, I guess if you install that bundle another dependency is missing. I don‘t think this makes any sense. And probably it won’t work to have the 2.4 and 2.5 version co-exist. You would need to |
Yes - it's massive - and we're almost at 24 hours, which, in the last 2 weeks, was unheard of. |
|
@MPH80, since I assume that the connection is still closed very often (and I only made that clean), I would like to see what happens. Could you set |
|
Tried to find a way to email you @J-N-K - must be being stupid as I can't see it. Anyway - have added the trace and turned off/on both TVs several times. Pretty sure it's the NU8000 (as the new one) that's the interesting one. Log attached to post here. Note: At some point overnight - the bundle was reverted back to the 2.5.6 thanks to that auto-updating service. So I reloaded it back to the 2.5.7 snapshot again at the 11.55 point. |
That's the intersting part. As you can see, the session Depending on the state it was in, it may lead to out-of-memory errors or maybe exhaustion of the thread pool. Maybe because the amazonechoontrol did use it's own thread pool, it lead to the OOM where here the thread pool is exhausted with blocked threads. You can uninstall the binding and drop the .jar in the addons folder, then it can't be reverted. P.S.: There is no special button to email someone. My email address is in the first post of the attached PR. |
|
Just to throw a comment on here about the JuPnP note. I also moved to the 2.4.0-SNAPSHOT Samsung binding due to the thread issues and it did NOT stop my thread exhaustion issues. After about 8 days my Sonos speakers start to fall offline and refuse to come back. I'm a firm believer there is a race condition happening in the thread pool. It looks like the majority of my failures happen when the system loads up. Specifically when I either have a significant burst of item updates or a bunch of complex rules fire at once. |
|
Try 2.4 RC1 Samsung binding. It has kept my system stable. My sonos devices (15) randomly drop off but come back online within less than 5 minutes. I have a rule watching all my Sonos things which alerts me when it happens. Best, Jay |
|
Happy to test. Got a specific link for the jar file to make sure we're all on the same version? |
|
https://openhab.jfrog.io/openhab/webapp/#/home Case sensitive on Quick Search --> samsungtv-2.4.0.RC1 You need to put an asterisk (*) in front and behind of the search criteria above. GitHub is stripping my asterisks off. EDIT: Here's my upnp libraries I'm running also. openhab> list -s | grep upnp Best, Jay |
|
@MPH80, can we close here? |
|
Yes - been stable since the new jar went in. Thanks @J-N-K for your hard work on this. |
Following on from an issue where I believed by RFXCom was causing problems - I ran a thread capture when the system locked up. I found that the root cause of the lockup was a thread coming from the SamsungTV binding.
Current Behavior
So - seemly at random, but now (I believe) related to one of my TV's being turned off - the RFXCom binding would appear to stop responding. The root cause of this appears to be a lock on the device discovery functions in OpenHab - which in turn are caused by a thread attempting to handle an exception in the SamsungTV Binding.
Possible Solution
The only solution was to restart Openhab (although I'll admit I didn't try reloading the samsungtv binding).
Steps to Reproduce (for Bugs)
Reproduction is very tricky - the situation is apparently random and might be timing related.
Your Environment
##Thread traces:
Lots of threads all blocked awaiting a lock on org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl@1c74af8 - owned by upnp-main-504.
upnp-main-504 - is blocked on java.lang.Object@87d58f owned by ESH-httpClient-samtungtv-3825
ESH-httpClient-samtungtv-3825 is waiting on a countdownlatch which, for some reason, isn't completing.
File holding the thread traces:
shellthread.txt
Stack trace for that thread:
The text was updated successfully, but these errors were encountered: