I’m running OSMC on a RPI 2 with the lastest April update.
After the most recent update, I am unable to keep my TV from turning itself on due to CEC. I’ll turn the TV off with the remote and approximately 3 - 5 minutes later, the TV will turn itself back on.
I’ve tried replacing the HDMI cable, messing with the CEC settings to include setting “hdmi_ignore_cec_init=1.”
I’m at a loss on where to go from here. Here’s my log:
http://paste.osmc.io/raw/evifuzojez
Last event was at 0738…I turned my TV off at 0753 and it turned itself back on at 0756. No additional log lines created.
Probably an addon, when it happened to me it was vasued by library updates
kyub
6 April 2016 09:13
3
I’m having this same issue on the Vero2 after the latest update. I’ll try to get logs later this evening.
Have a look in CEC settings in Settings->System->Input->Peripherals->CEC.
Check that the option that sends active source when the screen saver is cancelled is turned off, otherwise anything that wakes Kodi when the screen saver is active will turn your TV back on.
1 Like
Thanks for the reply. Checked and it’s already off:
And if you disable CEC completely does it stop happening ?
what addons do you have or theme you are using?
I ended up freshly installing and it still occurs with no non stock addons
ntim
26 May 2016 11:25
10
Happens to me too, started today out of the blue.
ntim
28 May 2016 10:13
11
Ok, done a bit of debugging with the cec-client (option “-m” for monitoring)
DEBUG: [ 54812] GetPhysicalAddress - physical address = 1100
It seems the TV is confused by some traffic coming over the HDMI. Is there anyway to look up what the traffic means?
My Sony TV is connected to a Yamaha receiver which in turn is connected to a Bluray player, a FireTV and the rpi3.
Didn’t even know that command existed…thanks!
I’m going to see whats going on with mine.
The log below is what happens when I turn my TV off and it turns itself back on:
TRAFFIC: [ 96708] >> 5f:72:01
DEBUG: [ 96709] >> Audio (5) -> Broadcast (F): set system audio mode (72)
TRAFFIC: [ 96921] >> 5f:a0:08:00:46:00:0a:00
DEBUG: [ 96921] >> Audio (5) -> Broadcast (F): vendor command with id (A0)
WARNING: [ 97809] unhandled response received: opcode=4 initiator=e destination=0 response=0
TRAFFIC: [ 98132] >> 0f:36
DEBUG: [ 98132] >> TV (0) -> Broadcast (F): standby (36)
DEBUG: [ 98132] TV (0): power status changed from 'on' to 'standby'
TRAFFIC: [ 98269] >> 5f:72:00
DEBUG: [ 98270] >> Audio (5) -> Broadcast (F): set system audio mode (72)
DEBUG: [ 98270] >> Audio (5): system audio mode status changed from on to off
TRAFFIC: [ 98425] >> 5f:72:00
DEBUG: [ 98425] >> Audio (5) -> Broadcast (F): set system audio mode (72)
WARNING: [ 99400] unhandled response received: opcode=4 initiator=e destination=0 response=0
TRAFFIC: [ 99487] >> 5f:72:01
DEBUG: [ 99487] >> Audio (5) -> Broadcast (F): set system audio mode (72)
DEBUG: [ 99487] >> Audio (5): system audio mode status changed from off to on
TRAFFIC: [ 99702] >> 5f:a0:08:00:46:00:0a:00
DEBUG: [ 99703] >> Audio (5) -> Broadcast (F): vendor command with id (A0)
TRAFFIC: [ 99955] >> 0f:85
DEBUG: [ 99956] >> TV (0) -> Broadcast (F): request active source (85)
DEBUG: [ 99956] >> 0 requests active source
DEBUG: [ 99956] TV (0): power status changed from 'standby' to 'on'
WARNING: [ 100871] unhandled response received: opcode=82 initiator=e destination=f response=0
WARNING: [ 102371] unhandled response received: opcode=82 initiator=e destination=f response=0
WARNING: [ 103872] unhandled response received: opcode=82 initiator=e destination=f response=0
WARNING: [ 105313] unhandled response received: opcode=4 initiator=e destination=0 response=0
WARNING: [ 106814] unhandled response received: opcode=4 initiator=e destination=0 response=0
WARNING: [ 108374] unhandled response received: opcode=82 initiator=e destination=f response=0
WARNING: [ 109875] unhandled response received: opcode=82 initiator=e destination=f response=0
WARNING: [ 111376] unhandled response received: opcode=82 initiator=e destination=f response=0
WARNING: [ 112817] unhandled response received: opcode=4 initiator=e destination=0 response=0
DEBUG: [ 113159] GetPhysicalAddress - physical address = 3000
NOTICE: [ 113159] physical address changed to 3000
WARNING: [ 114317] unhandled response received: opcode=4 initiator=e destination=0 response=0
TRAFFIC: [ 115511] >> 0f:84:00:00:00
DEBUG: [ 115512] >> TV (0) -> Broadcast (F): report physical address (84)
TRAFFIC: [ 115711] >> 0f:87:6b:74:6d
DEBUG: [ 115712] >> TV (0) -> Broadcast (F): device vendor id (87)
WARNING: [ 115878] unhandled response received: opcode=82 initiator=e destination=f response=0
ntim
28 May 2016 12:38
13
Do you also have a FireTv? I saw that mine updated yesterday.
Nope, running on a Raspberry Pi 3.
ntim
29 May 2016 07:16
15
I found related topics
opened 08:11PM - 08 Apr 15 UTC
closed 06:42AM - 08 Feb 16 UTC
invalid
It seems to be a long standing issue - i've had the issue in OpenElec 4.x on RPi… Model B, same with 5.x on RPi2.
All revelant wake up / stand by related settings are disabled in Kodi settings, the only thing I need CEC for is to use TV remote to control Kodi.
TV keeps waking up when left overnight. RPi does not support sleep hence it's turned on all the time on kodi main menu screen.
opened 10:53AM - 12 Mar 16 UTC
closed 12:50AM - 25 Oct 16 UTC
Here is a log where I have two problems, my main issue is #2 though!
1. Sometime… s AVR powers off instead of being selected when switching to the RPi2/Kodi on the TV
**2. The RPi2/Kodi goes nuts when I turn off the TV+AVR. it constantly sends some signals that turn on the AVR, turn off the AVR and the Standby LED from my TV goes crazy, like it is turning on and then immediately off again. There is some fighting going on over something.**
Setup: Philips TV connected to Sony AVR that has Chromecast as HDMI1 and RPi2 running latest stable OpenELEC connected to HDMI2. CEC is enabled in Kodi with everything on OFF or IGNORE (like auto power on/off).
http://pastebin.com/di8vB7sQ
Problem started a week ago or so. I had the OSMC Jarvis build running when it came out without a problem and suddenly problem 2 it started happening (I had problem 1 before). It's the same with the latest OpenELEC now.
Edit1: funny thing is, if I disconnect the Chromecast this "CEC fire" from Kodi stops. I had this setup running now for 6+ month and it worked without major problems.
Edit2: doesn't seem to be related to the Chromecast. If I connect a CEC enabled device to the AVR in addition to the RPi2 then problem #2 starts.
In the meantime, I enabled debug logging in the kodi settings to have cec debug output enabled by default.
ntim
29 May 2016 07:46
16
You can put the following in your advancedsettings.xml to enable full cec debug output to ~/.kodi/temp/kodi.log
<advancedsettings>
<loglevel>2</loglevel> <!-- Change this to "1" to hide the on-screen debug log text -->
<debug>
<extralogging>true</extralogging>
<setextraloglevel>32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536</setextraloglevel>
<showloginfo>true</showloginfo>
</debug>
</advancedsettings>
ntim
30 May 2016 09:32
17
Got the relevant log
09:40:29 475.785675 T:1849684976 DEBUG: CecLogMessage - GetPhysicalAddress - physical address = 1100
09:40:29 475.785767 T:1849684976 DEBUG: CecLogMessage - physical address changed to 1100
09:40:29 475.785828 T:1849684976 DEBUG: CecLogMessage - physical address unchanged (1100)
09:40:30 476.236115 T:1849684976 DEBUG: CecLogMessage - >> 0f:84:00:00:00
09:40:30 476.236328 T:1849684976 DEBUG: CecLogMessage - << Recorder 1 (1) -> broadcast (F): physical adddress 1100
09:40:30 476.236420 T:1849684976 DEBUG: CecLogMessage - << 1f:84:11:00:01
09:40:30 476.236542 T:1849684976 DEBUG: CecLogMessage - >> TV (0) -> Broadcast (F): report physical address (84)
09:40:30 476.479950 T:1849684976 DEBUG: CecLogMessage - >> 81:83
09:40:30 476.480194 T:1849684976 DEBUG: CecLogMessage - << Recorder 1 (1) -> broadcast (F): physical adddress 1100
09:40:30 476.480286 T:1849684976 DEBUG: CecLogMessage - << 1f:84:11:00:01
09:40:30 476.480347 T:1849684976 DEBUG: CecLogMessage - >> Playback 2 (8) -> Recorder 1 (1): give physical address (83)
09:40:30 477.043579 T:1849684976 DEBUG: CecLogMessage - >> 8f:84:12:00:04
09:40:30 477.043793 T:1849684976 DEBUG: CecLogMessage - >> Playback 2 (8) -> Broadcast (F): report physical address (84)
09:40:31 477.182190 T:1849684976 DEBUG: CecLogMessage - >> 4f:84:13:00:04
09:40:31 477.182404 T:1849684976 DEBUG: CecLogMessage - >> Playback 1 (4) -> Broadcast (F): report physical address (84)
09:40:31 477.420593 T:1849684976 DEBUG: CecLogMessage - >> 8f:85
09:40:31 477.420807 T:1849684976 DEBUG: CecLogMessage - >> 8 requests active source
09:40:31 477.420898 T:1849684976 DEBUG: CecLogMessage - << Recorder 1 (1) -> broadcast (F): active source (1100)
09:40:31 477.420959 T:1849684976 DEBUG: CecLogMessage - << 1f:82:11:00
09:40:31 477.421021 T:1849684976 DEBUG: CecLogMessage - >> Playback 2 (8) -> Broadcast (F): request active source (85)
09:40:31 477.669769 T:1849684976 DEBUG: CecLogMessage - >> 8f:84:12:00:04
09:40:31 477.669983 T:1849684976 DEBUG: CecLogMessage - >> Playback 2 (8) -> Broadcast (F): report physical address (84)
09:40:31 477.928986 T:1849684976 DEBUG: CecLogMessage - >> 5f:84:10:00:05
09:40:31 477.929169 T:1849684976 DEBUG: CecLogMessage - >> Audio (5) -> Broadcast (F): report physical address (84)
09:40:32 478.167389 T:1849684976 DEBUG: CecLogMessage - >> 8f:85
09:40:32 478.167603 T:1849684976 DEBUG: CecLogMessage - >> 8 requests active source
09:40:32 478.167664 T:1849684976 DEBUG: CecLogMessage - << Recorder 1 (1) -> broadcast (F): active source (1100)
09:40:32 478.167725 T:1849684976 DEBUG: CecLogMessage - << 1f:82:11:00
09:40:32 478.167816 T:1849684976 DEBUG: CecLogMessage - >> Playback 2 (8) -> Broadcast (F): request active source (85)
09:40:32 478.755341 T:1849684976 DEBUG: CecLogMessage - >> 8f:84:12:00:04
09:40:32 478.755554 T:1849684976 DEBUG: CecLogMessage - >> Playback 2 (8) -> Broadcast (F): report physical address (84)
09:40:33 479.309937 T:1849684976 DEBUG: CecLogMessage - >> 51:46
09:40:33 479.310211 T:1849684976 DEBUG: CecLogMessage - << Recorder 1 (1) -> Audio (5): OSD name 'Kodi'
09:40:33 479.310272 T:1849684976 DEBUG: CecLogMessage - << 15:47:4b:6f:64:69
09:40:33 479.310333 T:1849684976 DEBUG: CecLogMessage - >> Audio (5) -> Recorder 1 (1): give osd name (46)
09:40:33 480.015930 T:1849684976 DEBUG: CecLogMessage - GetPhysicalAddress - physical address = 1000
09:40:33 480.016113 T:1849684976 DEBUG: CecLogMessage - physical address changed to 1000
09:40:33 480.016174 T:1849684976 DEBUG: CecLogMessage - setting physical address to '1000'
09:40:33 480.016266 T:1849684976 DEBUG: CecLogMessage - marking Recorder 1 (1) as inactive source
09:40:33 480.016327 T:1849684976 DEBUG: CecLogMessage - >> source deactivated: Recorder 1 (1)
09:40:33 480.016418 T:1849684976 DEBUG: CecLogMessage - Recorder 1 (1): physical address changed from 1100 to 1000
09:40:33 480.016479 T:1849684976 DEBUG: CecLogMessage - << Recorder 1 (1) -> broadcast (F): physical adddress 1000
09:40:33 480.016541 T:1849684976 DEBUG: CecLogMessage - << 1f:84:10:00:01
09:40:34 480.106598 T:1849684976 DEBUG: CecLogMessage - making Recorder 1 (1) the active source
09:40:34 480.106781 T:1849684976 DEBUG: CecLogMessage - TV (0): power status changed from 'standby' to 'in transition from standby to on'
09:40:34 480.106842 T:1849684976 DEBUG: CecLogMessage - >> source activated: Recorder 1 (1)
09:40:34 480.107544 T:1849684976 DEBUG: CecLogMessage - sending system audio mode request for 'Recorder 1'
09:40:34 480.107635 T:1849684976 DEBUG: CecLogMessage - << 15:70:10:00
09:40:34 480.287994 T:1849684976 DEBUG: CecLogMessage - sending active source message for 'Recorder 1'
09:40:34 480.288086 T:1849684976 DEBUG: CecLogMessage - << powering on 'TV' (0)
09:40:34 480.288147 T:1849684976 DEBUG: CecLogMessage - << 10:04
09:40:34 480.408478 T:1849684976 DEBUG: CecLogMessage - << Recorder 1 (1) -> broadcast (F): active source (1000)
09:40:34 480.408691 T:1849684976 DEBUG: CecLogMessage - << 1f:82:10:00
The issue seems that at some point the FireTV (Playback 2) request to be an active source, then the whole thing ends up in libcec telling to change its physical address wich then sends the TV the wakeup call.
SiO2y
14 May 2018 12:27
18
Is this still an issue for everyone else or just me? I’ve been frustrated by it for a couple of years now.
We fixed it (for most users), but by doing so it then broke things for other users who never had the problem before.
SiO2y
15 May 2018 08:50
20
Thanks for the update Sam. Love your work by the way!
I remember a year or so back, alternate updates seemed to either leave me in this situation wherein the tv switches back on, or mean I had to manually reconnect CEC on my TV each time I switched on before my remote would actually pass commands through.
Is there anything I can do to help?
Sandy
