You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Sony: set powers on showing our input but claims active source 0.0.0.0, source answers standby indefinitely and gets no remote keys #753
The Sony handler answers <Give Device Power Status> with standby while the source is not the active source (the behaviour discussed in #744). That relies on the set later sending its wake sequence (0x40 + 0x6d) when it selects the source. When the set powers on already showing our input, it broadcasts <Active Source> 0.0.0.0 for itself, and sometimes never sends the wake sequence. libCEC then answers standby for as long as the set stays on, and the set sends no remote keys. Kodi shows its (dimmed) screensaver and the remote does nothing. One <Active Source> from our side ends it right away.
Caught at 23:06, with Kodi confirmed on screen, and cleared by hand after 4 minutes (below). The same evening at 19:59 the bus shows an identical sequence that lasted 21 minutes, until the set was switched off, but nobody checked the screen then.
Setup
Raspberry Pi 4, LibreELEC 13 nightly, Kodi 22, Linux CEC framework (/dev/cec0, vc4-hdmi), physical address 2.0.0.0, Recorder 1
Sony TV connected directly (EDID: SONY TV, manufactured 2020)
libCEC 8.1.6 with a local diagnostic patch: it adds the [sony-power-fix] debug line below and drops the TV-power-cache/model-year part of TreatedAsPoweredOff(). The !IsActiveSource() → standby branch, which is the one hit here, is unchanged from 8.1.6. The log line prints libCEC's cached state at the moment it answers. efe7d98 (Sony Bravia: User Control "Power" (0x40) on source select suspends an already-on device #744) doesn't touch this path, since no 0x40 ever arrives.
Log (real adapter only, 2026-09-24)
Kodi had been active source until the set's power-on broadcast at 19:59, and was still marked inactive when the set came on again at 23:06:
19:59:30.445 >> 0f:82:00:00 TV -> Broadcast: active source 0000
19:59:30.781 making TV (0) the active source
19:59:30.781 marking Recorder 1 (1) as inactive source
... power status queried every 60 s, answered standby, no keys, until the set goes to standby at 20:20
23:06:18.896 >> 0f:82:00:00 TV -> Broadcast: active source 0000 (TV powers on)
23:06:19.232 TV (0) was already marked as active source
23:06:19.716 >> 0f:a0:08:00:46:00:13:00:10:00:90:01:00:00:00:00
23:06:22.265 >> 01:83 give physical address << 1f:84:20:00:01
23:06:22.473 >> 01:46 give osd name << 10:47:4b:6f:64:69
23:06:22.708 >> 01:8c give device vendor id << 1f:87:00:15:82
23:06:22.918 >> 01:8f give device power status
23:06:22.918 [sony-power-fix] source=1 requester=0 active=0 source_power=on tv_power=on tv_status=1 decision=inactive-standby
23:06:22.918 << 10:90:01
23:06:23.083 >> 01:8f (same, << 10:90:01)
23:06:33.792 >> 0f:a0:08:00:46:00:13:00:10:00:80:01:00:00:00:00
23:07:23.076 >> 01:8f active=0 ... decision=inactive-standby << 10:90:01
23:08:23.082 >> 01:8f active=0 ... decision=inactive-standby << 10:90:01
23:09:23.084 >> 01:8f active=0 ... decision=inactive-standby << 10:90:01
23:10:23.089 >> 01:8f active=0 ... decision=inactive-standby << 10:90:01
No <User Control Pressed>, <Set Stream Path> or <Routing Change> arrives in that window, although the TV's remote was being pressed and the screen showed Kodi throughout.
Then CECActivateSource was triggered by hand in Kodi (kodi-send --action=CECActivateSource):
23:10:28.975 making Recorder 1 (1) the active source
23:10:28.975 << 10:04
23:10:29.028 << 1f:82:20:00
23:10:29.143 << 10:8e:00
23:10:44.667 >> 01:44:02 key pressed: down
23:10:45.954 >> 01:44:01 key pressed: up
23:10:46.675 >> 01:44:02 key pressed: down
The next power query was answered on (active=1 decision=own-power) and the remote worked from then on.
For comparison
On other power-ons of the same set, the start looks identical: <Active Source> 0000, the same discovery queries, standby answers. The set then follows up with 0x40 + 0x6d, typically 10–40 s later, sometimes after a second <Active Source> 0000. We become active source and keys flow. On the two failing power-ons above, that follow-up never came. We don't know what makes the set skip it. A standby → on cycle and a cold start (mains unplugged) both worked on the first attempt when we tried to reproduce.
What seems to be missing
As I read the handler, the standby answer is correct for a source the set isn't showing. But nothing on our side recovers when the set is actually showing us and doesn't wake us. The set's own <Active Source> 0000 is the only routing information it gives, and in this case it is wrong. The only way out is our own <Active Source>, which libCEC doesn't send on its own after the set wakes.
Full kodi.log and a passive bus recording (cec-ctl -M) for that evening are available if useful.
Happened again today (2026-09-28), same setup and build, same sequence:
11:44:05.122 >> 0f:82:00:00 TV powers on, active source 0000
11:44:05.457 making TV (0) the active source
11:44:05.457 marking Recorder 1 (1) as inactive source
11:44:08.786 >> 01:8f [sony-power-fix] active=0 ... decision=inactive-standby << 10:90:01
11:45:08.962 >> 01:8f active=0 ... decision=inactive-standby << 10:90:01
... (every 60 s)
Two details that are new since the first report:
When the remote was pressed (11:44:24–32), the set did react on the bus. It broadcast <Vendor Command With ID> Sony 00 13 00 10 00 90 01 00 00 00 00 / ... 80 01 ... (libCEC's Sony handler then queried the set's power 500 ms later, as designed, and got on), but no <User Control Pressed> reached us and there was no 0x40/0x6d. The key reaches the set, and the set chooses not to forward it.
I tried sending <Report Power Status> on to the TV from outside libCEC (cec-ctl --report-power-status pwr-state=on, 9 times over 90 s) while the remote was pressed repeatedly. The set sent nothing back. Caveat: libCEC still answered the set's own two queries in that window with standby, so this is not a clean test of "answer on while inactive". It only suggests that a power status of on isn't enough on its own.
The set was on Kodi's input the whole time. Keys later arrived without any input change or routing message.
CECActivateSource (<Active Source> 2.0.0.0) ended it again. From the next query libCEC answered on (active=1), and keys flowed from the next press.
Summary
The Sony handler answers
<Give Device Power Status>with standby while the source is not the active source (the behaviour discussed in #744). That relies on the set later sending its wake sequence (0x40+0x6d) when it selects the source. When the set powers on already showing our input, it broadcasts<Active Source> 0.0.0.0for itself, and sometimes never sends the wake sequence. libCEC then answers standby for as long as the set stays on, and the set sends no remote keys. Kodi shows its (dimmed) screensaver and the remote does nothing. One<Active Source>from our side ends it right away.Caught at 23:06, with Kodi confirmed on screen, and cleared by hand after 4 minutes (below). The same evening at 19:59 the bus shows an identical sequence that lasted 21 minutes, until the set was switched off, but nobody checked the screen then.
Setup
/dev/cec0, vc4-hdmi), physical address 2.0.0.0, Recorder 1SONY TV, manufactured 2020)[sony-power-fix]debug line below and drops the TV-power-cache/model-year part ofTreatedAsPoweredOff(). The!IsActiveSource()→ standby branch, which is the one hit here, is unchanged from 8.1.6. The log line prints libCEC's cached state at the moment it answers. efe7d98 (Sony Bravia: User Control "Power" (0x40) on source select suspends an already-on device #744) doesn't touch this path, since no0x40ever arrives.Log (real adapter only, 2026-09-24)
Kodi had been active source until the set's power-on broadcast at 19:59, and was still marked inactive when the set came on again at 23:06:
No
<User Control Pressed>,<Set Stream Path>or<Routing Change>arrives in that window, although the TV's remote was being pressed and the screen showed Kodi throughout.Then
CECActivateSourcewas triggered by hand in Kodi (kodi-send --action=CECActivateSource):The next power query was answered
on(active=1 decision=own-power) and the remote worked from then on.For comparison
On other power-ons of the same set, the start looks identical:
<Active Source> 0000, the same discovery queries, standby answers. The set then follows up with0x40+0x6d, typically 10–40 s later, sometimes after a second<Active Source> 0000. We become active source and keys flow. On the two failing power-ons above, that follow-up never came. We don't know what makes the set skip it. A standby → on cycle and a cold start (mains unplugged) both worked on the first attempt when we tried to reproduce.What seems to be missing
As I read the handler, the standby answer is correct for a source the set isn't showing. But nothing on our side recovers when the set is actually showing us and doesn't wake us. The set's own
<Active Source> 0000is the only routing information it gives, and in this case it is wrong. The only way out is our own<Active Source>, which libCEC doesn't send on its own after the set wakes.Full kodi.log and a passive bus recording (
cec-ctl -M) for that evening are available if useful.