2014-09-12, 08:01
(2014-09-12, 06:41)mk01 Wrote: I'm pretty sure that bug was there at the time I shared with popcornmix - so if that fresh patch should help pretty much depends on how (and what) you was applying. If that past version, then yes, it should help.
But colleague @Anaconda is telling me that your build system if fetching all the patches each run. Then the answer would be no as there is ~1 change relevant to process of waking up (stopping the limiter) - or I got stupid in-between and am missing again (on first look unrelated) dependency of code which I missed also with ver 1 of that patch.
Yes, my build system is pulling the patch directly from the xbian github every time, and had been building with the version prior to this latest Sep 12 update.
I've uploaded a new build, #0911b, which is the same as #0911 but now with the re-inclusion of the CecStandbyRender patch.
Even if this latest build doesn't fix the problem it should ensure you have a known version of the code when trying to interpret any debug results (all the patches used by the build are included in the OpenELEC tar, in the archive milhouse.build.tar.gz).
I'll include this patch again in future builds in the hope we can get you the debug information when you need it.
(2014-09-12, 06:41)mk01 Wrote: If possible without much hassle re-apply again and turn off TV. Check in logs for "CecStandby 1", turn TV back on. You will see in logs record about TV being "ON" again - problem is that this message comes from libCEC and comes not back to XBMC (as it is no message on CEC bus, but internal state change of libCEC for device 0(TV)). there is no OPCODE defined for device becoming ON (in contrast to dev going standby is required to be sent by the specific device).
I have the feeling that the first attempt - while trying to change as little of code as possible - was too optimistically depending on CEC messages and activity only (TV going OFF, TV changing source (so XBMC loosing ActiveSource attribute) and then back again with TV switching back to XBMC source (becoming ActiveSource again) or TV going OFF->ON - where (beside ugly LG) we don't get TVisON but TV should ask/reactivate last ActiveSource device so actually delivering the needed message to XBMC again (becoming AS)).
In reality that was far from paper specs... (not only for LG. there is also libCEC part like libCEC not reporting being AS if that info was already sent before - but not considering TV off-on cycle flushing all internal info about actual libCEC devices - so leaving TVs request to get info who is AS unanswered - limiting itself to DEBUG comment "not sending AS as libCEC is AS already and AS sent before")
Unfortunately I don't have CEC screens here so can't help with the debugging, but hopefully other testers will be able to provide you with the details you require. I'm happy to include additional logging in future builds (experimental or otherwise) if you think that might help expedite a solution.
