May 2, 2017 at 19:52 #11687
I think this CEC issue is a problem with my Panasonic tv since it is the same behaviour for Armada and imx6 Cubox.
I disabled the feature to automatically switch to CuBox when turning the tv on. If I switch to HDMI/CuBox manually it’s like gambling whether the tv remote works or not. Sometimes it works by telling the tv to re-initialise Viera-link (CEC).May 3, 2017 at 10:36 #11693
Well, it’s hard to say what’s going on here. Kodi uses libCEC, which implements the high-level logic and accesses the CEC bus via a relatively dumb adapter interface. So if we see problems, they might be caused either by the CEC core or the adapter interface. I contributed a bit to the latter for both CuBox models. Even though the hardware is different (Armada: external chip attached via I2C, iMX6: integrated into the SoC), they share some concepts. So there still is a possibility that the adapter interface is involved. Do you have the chance to try a RaspberryPi? It uses a radically different adapter interface so that in case this fails as well, we are pretty sure that the problems come from the CEC core. Also it needs to be said that the CEC implementations by different vendors are not 100% compatible. The standard leaves too much room for “creative” usage of certain features so that even the big electronics companies have problems with that. libCEC tries to work around this by detecting certain types/makes of TV sets and changing it’s behavior accordingly. Not really what a standard is about…May 3, 2017 at 18:53 #11695May 3, 2017 at 19:19 #11697May 5, 2017 at 16:32 #11709
I can confirm all what you said.
Only in Cubox 1st gen I seen all of:
=> sometimes after bootup you get a diagonally sheered picture, only solvable by reboot
=> A/V sync doesn’t work for some videos
=> CEC sometimes stops working with the message “CEC connection to TV lost
I solved last point configuring Lirc to know signal send from my remote (Samsung TV) bypassing CEC. With same remote I manage TV and old Cubox.
When I see old cubox in HDMI source, sometimes appears a message “Function not available”. This because both devices (Tv and Cubox) receive same remote input. Cubox reply as desired, TV doesn’t have the function.May 6, 2017 at 21:18 #11713
I did more or less the same thing as I was not able to use CEC with my old Samsung TV.
I have a Raspberry 1 with an attached IR receiver. Using lirc and the jsonrpc API from Kodi I’m forwarding all necessary events. As I don’t want to control Kodi when the TV is visible (not HDMI source selected) I have to turn it on manually by long-pressing a specific button on my remote. It is automatically turned of when some specific buttons are pressed (e.g. power, source selection, smart home, …). It’s simple and works just great without delay.
I did not notice any further issues with Geexbox on my Armada Cubox.May 7, 2017 at 22:49 #11714
The 20170507 version contains a change in the kernel driver that affects CEC operation. But as said before: I cannot really test as it (mostly) works with my TV.May 16, 2017 at 17:07 #11762
I tested now for several days the snapshot from 8th of May for ‘bcm2708-raspberrypi’
This is kodi 16.1 and libcec 3.1.0; I never had any issue with the CEC connection to my TV. libcec on rpi is configured the same way as it is on my Cuboxes.
By stating this it implies that probably the libcec ingegration in armada and imx6 Cubox is somehow faulty.May 17, 2017 at 14:41 #11765
Do you usually switch on the TV manually or by CEC? Does the Raspberry still work O.K. when you uncomment the line:
in config.txt. This prevents the videocore firmware from touching CEC on early boot.May 20, 2017 at 13:15 #11769
After writing previous comment I had one failure with the HDMI connection on RPI.
This is why I tested a bit more thoroughly the last days with the hdmi_ignore_cec_init option set.
No failure to report.
Tried to figure out how to set the same option on imx6 CuBox but didn’t succeed 😉May 20, 2017 at 14:15 #11771
You won’t find this option on CuBox(-i) as it is specific to RaspberryPi. The CEC hardware on the Pi is controlled by the (closed source) firmware of the graphics controller (VideoCore-IV). Thus it can – for example – switch on the TV before Linux is even booted. The option affects exactly this. On the Pi, libCEC interacts with the firmware using a mailbox mechanism, while on CuBox(-i) it reads and writes from/to a dedicated kernel driver.
Anyway, does the CEC operation on CuBox-i improve when the TV is switched on manually before the box is booted?May 20, 2017 at 17:41 #11772
this usually fails.
The other way round: First fire-up Cubox and then the tv has a hihger change of success.
Sometimes it helps disabeling and reenabeling CEC in the GUI (without reboot) to establish the connection
And I noticed that the chance of being able to establish the connection was hihger with kodi 16.x compared to 17.x.
With 17.x the changes are pretty low to get a working connection. Usually I have to use yatse to control it.May 20, 2017 at 19:46 #11773
Hmm, strange. I usually power up the TV and the AVR before booting the CuBox-i and it works 100%. No matter which Kodi version. Can you provide a log? I.e. in Kodi 17, enable “debug logging” and “component specific logging” for the libCEC library. Then restart Kodi, do a few key presses and then copy /root/.kodi/temp/kodi.logMay 21, 2017 at 15:06 #11774
wanted to post a stripped down version containing lines with “cec” only. But then the forum recognises my browser as spam-bot ^^
So I put the entire-log file here: log.txt
Note1: log-file has been created doing it your way: flicking on tv+amp and 30s later: Cubox-i
Note2: Cubox always reports successful CEC connection
Note3: This time CEC control didn’t work
Note4: I pressed some keys an the remote control – without any effect. Then I rebooted kodi using yatse-control (so the last key-strokes are from yatse)May 21, 2017 at 18:05 #11776
Thanks! It appears that the CuBox-i connected to input 1 of an AVR which is connected to input 1 of the TV. Is that correct? If so, can you test what happens when you connect it directly to one of the TV’s HDMI ports? Besides that, I see two commands that are sent out to the audio subsystem (“request vendor ID” and “request OSD name”) but are not answered. Instead, some vendor specific command (A0) comes in. Probably in response to “active source”. Besides that, I don’t see any obvious problem in the log. Very strange.
Does the TV switch to the correct input when the Kodi starts up?
BTW, my TV doesn’t use any vendor specific commands and does not need any command handler replacement. I will never understand, why this crap is necessary anyway…
Edit: Can you provide the same log for the (working) Raspberry?
You must be logged in to reply to this topic.