Pulse-Eight / libcec

USB CEC Adapter communication Library http://libcec.pulse-eight.com/
Other
722 stars 290 forks source link

Remote keys not working - Sony KDL-19S5700 #87

Closed brainstormi closed 8 years ago

brainstormi commented 9 years ago

I've an issue with libcec (Openelec 5/Osmc RC1) not sending remote key presses to Raspberry. Things I have already tested:

Inside Kodi's log, with debug enabled, I don't see any kind of activity when remote's keys are pressed, none of them. It seems TV is not forwarding the keys to the Raspberry, for example if I press "1" button it directly changes to channel 1 in TV mode.

I looked for a solution across internet without luck, although other people seems to have the same issue with Sony TVs, in particular KDL series... none of the issues got a solution. Could I provide any further info/logs that helps to clarify what could be happening?. Attached you can find a clean Kodi log with debug enabled: http://pastebin.com/427xTzDZ

brainstormi commented 9 years ago

Attached the output generated by executing: echo "as" | cec-client. Buttons on the remote are pressed without logging any activity in the debug.

No device type given. Using 'recording device' CEC Parser created - libCEC version 2.2.0 no serial port given. trying autodetect: path: Raspberry Pi com port: RPI

opening a connection to the CEC adapter... DEBUG: [ 68] unregistering all CEC clients DEBUG: [ 69] Broadcast (F): osd name set to 'Broadcast' DEBUG: [ 69] InitHostCEC - vchiq_initialise succeeded DEBUG: [ 69] InitHostCEC - vchi_initialise succeeded DEBUG: [ 69] InitHostCEC - vchi_connect succeeded DEBUG: [ 70] Open - vc_cec initialised DEBUG: [ 70] logical address changed to Free use (e) NOTICE: [ 72] connection opened DEBUG: [ 72] processor thread started DEBUG: [ 73] << Broadcast (F) -> TV (0): POLL DEBUG: [ 73] initiator 'Broadcast' is not supported by the CEC adapter. using 'Free use' instead TRAFFIC: [ 73] << e0 DEBUG: [ 104] >> POLL sent DEBUG: [ 104] TV (0): device status changed into 'present' DEBUG: [ 104] << requesting vendor ID of 'TV' (0) TRAFFIC: [ 104] << e0:8c TRAFFIC: [ 298] >> 0e:00:8c:00 DEBUG: [ 298] marking opcode 'give device vendor id' as unsupported feature for device 'TV' DEBUG: [ 298] expected response received (87: device vendor id) NOTICE: [ 299] registering new CEC client - v2.2.0 DEBUG: [ 299] detecting logical address for type 'recording device' DEBUG: [ 299] trying logical address 'Recorder 1' DEBUG: [ 299] << Recorder 1 (1) -> Recorder 1 (1): POLL TRAFFIC: [ 299] << 11 TRAFFIC: [ 398] << 11 DEBUG: [ 488] >> POLL not sent DEBUG: [ 489] using logical address 'Recorder 1' DEBUG: [ 489] Recorder 1 (1): device status changed into 'handled by libCEC' DEBUG: [ 489] Recorder 1 (1): power status changed from 'unknown' to 'on' DEBUG: [ 489] Recorder 1 (1): vendor = Pulse Eight (001582) DEBUG: [ 489] Recorder 1 (1): CEC version 1.4 DEBUG: [ 489] AllocateLogicalAddresses - device '0', type 'recording device', LA '1' DEBUG: [ 490] logical address changed to Recorder 1 (1) DEBUG: [ 490] Recorder 1 (1): osd name set to 'CECTester' DEBUG: [ 490] Recorder 1 (1): menu language set to 'eng' DEBUG: [ 491] GetPhysicalAddress - physical address = 1000 DEBUG: [ 491] AutodetectPhysicalAddress - autodetected physical address '1000' DEBUG: [ 491] Recorder 1 (1): physical address changed from ffff to 1000 DEBUG: [ 491] << Recorder 1 (1) -> broadcast (F): physical adddress 1000 TRAFFIC: [ 491] << 1f:84:10:00:01 NOTICE: [ 642] CEC client registered: libCEC version = 2.2.0, client version = 2.2.0, firmware version = 1, logical address(es) = Recorder 1 (1) , physical address: 1.0.0.0, host: armv7l-unknown-linux-gnueabihf, features: 'P8 USB' 'P8 USB detect' 'RPi' 'EXYNOS', compiled on: Sat Feb 28 10:41:05 UTC 2015 by root@vero on Linux 3.14.14-cubox (armv7l) DEBUG: [ 642] << Recorder 1 (1) -> TV (0): OSD name 'CECTester' TRAFFIC: [ 642] << 10:47:43:45:43:54:65:73:74:65:72 TRAFFIC: [ 763] << 10:47:43:45:43:54:65:73:74:65:72 DEBUG: [ 883] << requesting power status of 'TV' (0) TRAFFIC: [ 883] << 10:8f TRAFFIC: [ 1004] << 10:8f waiting for input DEBUG: [ 1125] making Recorder 1 (1) the active source DEBUG: [ 1125] TV (0): power status changed from 'unknown' to 'in transition from standby to on' NOTICE: [ 1125] >> source activated: Recorder 1 (1) DEBUG: [ 1125] sending active source message for 'Recorder 1' DEBUG: [ 1125] << requesting vendor ID of 'TV' (0) DEBUG: [ 1126] 'give device vendor id' is marked as unsupported feature for device 'TV' NOTICE: [ 1126] << powering on 'TV' (0) TRAFFIC: [ 1126] << 10:04 NOTICE: [ 1246] << Recorder 1 (1) -> broadcast (F): active source (1000) TRAFFIC: [ 1246] << 1f:82:10:00 DEBUG: [ 1367] << Recorder 1 (1) -> TV (0): menu state 'activated' TRAFFIC: [ 1367] << 10:8e:00 TRAFFIC: [ 1518] >> 01:46 DEBUG: [ 1518] >> TV (0) -> Recorder 1 (1): give osd name (46) DEBUG: [ 1518] << Recorder 1 (1) -> TV (0): OSD name 'CECTester' TRAFFIC: [ 1518] << 10:47:43:45:43:54:65:73:74:65:72 TRAFFIC: [ 1909] >> 01:00:8e:00 DEBUG: [ 1909] >> TV (0) -> Recorder 1 (1): feature abort ( 0) DEBUG: [ 1909] marking opcode 'menu status' as unsupported feature for device 'TV' WARNING: [ 2059] unhandled response received: opcode=47 initiator=1 destination=0 response=1

opdenkamp commented 9 years ago

spotted a bug in this log, when the response to a command can't be sent:

21:01:53 T:1861219360   DEBUG: CecLogMessage - << 10:47:4b:6f:64:69
21:01:53 T:1861219360   DEBUG: CecLogMessage - << 10:47:4b:6f:64:69
21:01:53 T:1861219360   DEBUG: CecLogMessage - sending abort with opcode 46 and reason 'invalid operand' to TV
21:01:53 T:1861219360   DEBUG: CecLogMessage - << transmitting abort message
21:01:53 T:1861219360   DEBUG: CecLogMessage - << 10:00:46:03

will investigate the bug

opdenkamp commented 9 years ago

I've fixed the bug that's sending the invalid response in 3.0.1 and some fixes for the Pi have already been included in 3.0.0. Can you try again once your distribution picked up the update.

erpepeillo commented 9 years ago

Hi brainstormi, have you solved this issue ?' I have the same problem, i try with Openelec 5.95 (beta), but without any results.

Hi opdenkamp, Dou you know what distribution runs 3.0.1 in a Raspberry Pi ??

opdenkamp commented 9 years ago

I have no idea which distribution is running what, but I assume that OpenELEC will be using 3.0.1

erpepeillo commented 9 years ago

Thanks a lot for your replay, I'll try to guess what's the correct version and try to make a fresh install.

opdenkamp commented 9 years ago

You can find the version in Kodi: system -> input devices -> peripherals. The version is displayed underneath the "CEC adapter" entry, at least in Confluence.

On 15-09-15 12:03, erpepeillo wrote:

Thanks a lot for your replay, I'll try to guess what's the correct version and try to make a fresh install.

— Reply to this email directly or view it on GitHub https://github.com/Pulse-Eight/libcec/issues/87#issuecomment-140343057.

erpepeillo commented 9 years ago

Hi, for Info. Yesterday I installed the last beta Openelec 5.95.5 , but while we have somewhat improves, Kodi is recognized as "Recorder 1" in HDMI TV, doesn't work the remote control to control Kodi.

Strange, that in CEC adapter version, it appears in Kodi as "Unknown", but after a Debug enabled, I can see in Log that version is 3.0.0.

I will try to upgrade to a alpha Kodi 16 Openelec, that seems to be 3.0.1 implemented.

opdenkamp commented 9 years ago

Yeah please upgrade to the latest version first

brainstormi commented 9 years ago

Hi... I was able to test the last builds from Milhouse (Openelec based on Jarvis). It seems they're the only ones implementing libcec 3.0.1 so far. Unfortunatly the outcome is the "same" and remote continue without working, showing the same behaviour than before. I attached a clean kodi.log and the output of executing: echo "as" | cec-client, hoping it could helps. http://pastebin.com/TaWcDzYn http://pastebin.com/D0v3H1Vn

brainstormi commented 9 years ago

Reviewing the logs, it seems than the fact of "menu status" opcode not being supported by TV, fires CEC to unregister all clients. Not sure if "signal caught: 2 - exiting" log when aborting is the cause of the issue or the consequence of not supporting "menu status" opcode. Is this opcode mandatory to make cec functional?.

NOTICE: [ 2377] << Recorder 1 (1) -> broadcast (F): active source (1000) TRAFFIC: [ 2377] << 1f:82:10:00 DEBUG: [ 2497] << Recorder 1 (1) -> TV (0): menu state 'activated' TRAFFIC: [ 2497] << 10:8e:00 TRAFFIC: [ 2703] >> 01:00:8e:00 DEBUG: [ 2704] marking opcode 'menu status' as unsupported feature for device 'TV' DEBUG: [ 2704] >> TV (0) -> Recorder 1 (1): feature abort ( 0) signal caught: 2 - exiting DEBUG: [ 2989] unregistering all CEC clients NOTICE: [ 2990] unregistering client: libCEC version = 3.0.1, client version = 3.0.1, firmware version = 1, logical address(es) = Recorder 1 (1) , physical address: 1.0.0.0, git revision: , compiled on Fri Oct 16 20:13:52 UTC 2015 by neil@nm-linux on Linux 3.19.0-30-generic (x86_64), features: P8_USB, P8_detect, 'RPi' DEBUG: [ 2990] Recorder 1 (1): power status changed from 'on' to 'unknown'

opdenkamp commented 8 years ago

I've just check two different Sony models with our USB-CEC adapter with libCEC 3.1.0 and I'm not seeing any issues.

Menu status indeed isn't supported by Sony.

If this issue is still relevant when using 3.1.0, please report back.