Make sure you are running the latest version of Home Assistant before reporting an issue.
You should only file an issue if you found a bug. Feature and enhancement requests should go in the Feature Requests section of our community forum:
Home Assistant release (hass --version
): 39.1
Python release (python3 --version
): 3.4.2
Component/platform: media_player.samsungtv
Description of problem:
Log spam from samsungtv component. Below is a small excerpt, I am getting 5-10 of these every hour.
Expected:
No warnings
Problem-relevant configuration.yaml
entries and steps to reproduce:
Traceback (if applicable):
17-03-03 10:19:42 WARNING (MainThread) [homeassistant.components.media_player] Updating samsungtv media_player took longer than the scheduled update interval 0:00:10
17-03-03 10:19:53 WARNING (MainThread) [homeassistant.components.media_player] Updating samsungtv media_player took longer than the scheduled update interval 0:00:10
17-03-03 10:20:04 WARNING (MainThread) [homeassistant.components.media_player] Updating samsungtv media_player took longer than the scheduled update interval 0:00:10
17-03-03 12:08:55 WARNING (MainThread) [homeassistant.components.media_player] Updating samsungtv media_player took longer than the scheduled update interval 0:00:10
17-03-03 12:09:06 WARNING (MainThread) [homeassistant.components.media_player] Updating samsungtv media_player took longer than the scheduled update interval 0:00:10
17-03-03 12:57:50 WARNING (MainThread) [homeassistant.components.media_player] Updating samsungtv media_player took longer than the scheduled update interval 0:00:10
17-03-03 12:58:01 WARNING (MainThread) [homeassistant.components.media_player] Updating samsungtv media_player took longer than the scheduled update interval 0:00:10
17-03-03 12:58:12 WARNING (MainThread) [homeassistant.components.media_player] Updating samsungtv media_player took longer than the scheduled update interval 0:00:10
Additional info:
use on platfrom config scan_interval: 15
or if 15 seconds to low you can also move it to ie. 20
until the message is gone.
Thanks, will give it a try
On 3 Mar 2017 1:45 pm, "Pascal Vizeli" notifications@github.com wrote:
use on platfrom config scan_interval: 15 or if 15 seconds to ow you can
also move it to ie. 20 until the message is gone.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/6375#issuecomment-283956409,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGg15jZLxhLyQ-FDHk8UEVMP_hXYc5vWks5riBl1gaJpZM4MSPx6
.
I think the larger issue is the way these devices work. (I have a UN55KU6600) When TV is powered off, tizen OS is offline and hence not responding to queries. The library should be written in a way that an offline device does not log as a warning since this is normal behavior.
I bumped the scan interval to 30 seconds but am still getting the occasion warning. For the record my TV is an e-series:
09:24:32 WARNING (MainThread) [homeassistant.components.media_player] Updating samsungtv media_player took longer than the scheduled update interval 0:00:30#033[0m
Mar 12 09:25:03 pi2 hass[17126]: #033[33m17-03-12 09:25:03 WARNING (MainThread) [homeassistant.components.media_player] Updating samsungtv media_player took longer than the scheduled update interval 0:00:30#033[0m
This issue is persisting in 0.41.0 as well. When the TV is off, it generates a flood of messages in the logs. :(
+1
+1
I'm also seeing this with Sonos, although all my Sonos speakers are continuously ON, for some reason they're also generating a flood of messages in my logs.
Even set to 30 seconds it doesn't work for me either.
Could we just set a timeout in the samsung_tv function that if it doesn't respond in 5 seconds we consider it offline? 5 seconds on a lan or even a connection to the other side of the globe should be long enough for a ping.
I'd tak a way to just filter it from the running logs. right now I would have to hide [homeassistant.components.media_player]
which would hide too much.
+1 have the same warning in the log every 10 sec....
17-04-17 23:23:53 WARNING (Thread-5) [netdisco.ssdp] Found malformed XML at http://192.168.1.106:9080: status=ok
17-04-17 23:24:18 WARNING (MainThread) [homeassistant.helpers.entity] Update of media_player._samsung_ue46f7000 is taking over 10 seconds.
17-04-17 23:24:19 WARNING (MainThread) [homeassistant.components.media_player] Updating samsungtv media_player took longer than the scheduled update interval 0:00:10
timeout in the config did not help to solve the issue.
HASS version 0.42.3
I am having the same issues with both Sonos and other media like by Amazon stick. They are switched off but HA keeps polling them and filling up the logs. Perhaps we need to look at the system backing off after a set number of failures to poll to a longer time frame? Seems to have got worse under 0.4x than earlier releases, or it is being reported now.
Dave
Just thought you ought to know ... still having this issue under 0.46.1
ie.
2017-06-21 21:11:30 WARNING (MainThread) [homeassistant.components.media_player] Updating samsungtv media_player took longer than the scheduled update interval 0:00:10
I'm faced with the same problem :(
A large list of the same warning....
WARNING (MainThread) [homeassistant.components.media_player] Updating samsungtv media_player took longer than the scheduled update interval 0:00:10
+1
But I doubt the issue is as simple as devices being unable to respond a ping when turned off. In fact, our TV was turned on several times a day and HA has never recorded any "On" states in history.
Same issue here. TV is off, get lots of these messages.
Also having the same excessive logging issue under version 0.48.1
I have a similar issue, but with the Vizio media_player component - issue #8651
I'm facing the same issue and had a quick look.
It seems this issue only occurs if you start HASS while the TV is off (still powered, but off).
My guess is that the exception handling misses out on something and can't set the state to either on or off.
As the initial state is UNKNOWN, this causes issues.
Personally, I'd just except Exception:
right here.
Not 100% sure if this is the issue and as I'm at work I can't properly test it.
Will do when I'm back home though.
I have the same issue with frontier_silicon media_player, but it also effects all other components, since the whole system freezes (even ssh) when hass
is struggelig with this bug.
Seeing the exact same spam with my samsung TV. It would be nice to be able to supress these warnings.
This will supress them:
Logger:
Logs:
homeassistant.components.media_player: error
On 28 Sep 2017 8:20 pm, "Thomas Juberg" notifications@github.com wrote:
Seeing the exact same spam with my samsung TV. It would be nice to be able
to supress these warnings.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/6375#issuecomment-332937722,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGg15sv8ZOiEhR8vjXNGFvGDWheZbR1Pks5sm_GUgaJpZM4MSPx6
.
Similar issue here, but it doesn't freeze HASS. Instead, what happens is HASS takes about 15 minutes to detect that the TV is off and it almost immediately detects when it is turned on - no matter what settings for timeout are set... anyone having similar issues?
I'm having this issue still and when it happens the unit cant be controlled at all. Has anyone succeeded in fixing it?
I get this error Error doing job: Task exception was never retrieved
9:05 PM components/media_player/frontier_silicon.py (ERROR)
Thanks for the suggestion @timstanley1985.
Some style changes has to be made to make the config valid, like so:
logger:
logs:
homeassistant.components.media_player: error
However, I hope a more permanent fix will be available soon.
Most helpful comment
I think the larger issue is the way these devices work. (I have a UN55KU6600) When TV is powered off, tizen OS is offline and hence not responding to queries. The library should be written in a way that an offline device does not log as a warning since this is normal behavior.