Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added LG-Reconnect-Request #256

Merged
merged 1 commit into from Oct 25, 2016

Conversation

@Vollstrecker
Copy link

commented Oct 25, 2016

Just ignoring the command, doesn't work. My Pc even doesn't notice that it is the active source, and without reconnecting it never gets any input.

Here is my solution, which is working for quite some time now.

@opdenkamp

This comment has been minimized.

Copy link
Contributor

commented Oct 25, 2016

Ok thanks, I'll give this a go with the LGs that I have here.

Could you clean up the patch a bit to get rid of the reordered code. This changes 10 lines, while the actual fix for you is just the added HandleVendorCommandPowerOn() call + the cosmetic name change of the #define. Thanks

@Vollstrecker

This comment has been minimized.

Copy link
Author

commented Oct 25, 2016

If you like an easier to read patch more, for sure I can, but to be honest: I like to have 0x0b before 0xa0.

@opdenkamp

This comment has been minimized.

Copy link
Contributor

commented Oct 25, 2016

You're right, been looking at this code for too long and didn't spot that. nvm the cosmetics.
I've tested it on one of the LGs that I have here, and it doesn't break things on that one, but I didn't see 0x0b anywhere in the log, so it looks like this one isn't sending it. I'll try a more recent one in a bit, thanks.

@opdenkamp opdenkamp merged commit c1d26cd into Pulse-Eight:master Oct 25, 2016
@Vollstrecker

This comment has been minimized.

Copy link
Author

commented Oct 25, 2016

It's an 55LF6309 with current WebOS Version. From the energylabel it was introduced in late 2014. Unfortunatele I can't tell if the command was sent before the webOS update.

@opdenkamp

This comment has been minimized.

Copy link
Contributor

commented Oct 25, 2016

The webos version can be found in the TV's menu, if you go to "about this TV". My most recent one is 2.0

@Vollstrecker

This comment has been minimized.

Copy link
Author

commented Oct 25, 2016

On TV-menu I get 04.05.1, but maybe it's a "feature" of LF-Series or something else. I don't think someone can tell us.

@opdenkamp

This comment has been minimized.

Copy link
Contributor

commented Oct 25, 2016

That's the same version as mine is running, so I should be able to reproduce this, thanks

@jfjm

This comment has been minimized.

Copy link

commented Apr 28, 2017

With this change, it is causing the issue of TV switching source to the device using libece when TV turns on (regardless what the previous source was on). Was working fine with version 3.x. Please consider reverting to the previous behavior.

@Vollstrecker

This comment has been minimized.

Copy link
Author

commented Apr 28, 2017

I'm sure it's no general side-effect, as my device does't show that problem.

I think the reconnect is working as expected and maybe some new vendorspecific thing appeared.

@anomaly256

This comment has been minimized.

Copy link

commented Apr 28, 2017

My tv is an 60LM6450, quite old now and predates WebOS. It was working fine previously but now switches to the source Kodi is on every time the TV powers on. Judging by the responses in #307 this is causing more problems than it fixes, if it is indeed the change that caused it

@anomaly256

This comment has been minimized.

Copy link

commented Apr 28, 2017

Is the addition of HandleVendorCommandPowerOn() intended here? This calls device->MarkAsActiveSource() in SLCommandHandler.cpp

Or am I reading this wrong and that function only tells LibCEC it's the active source as opposed to telling the TV to change the active source?

@jfjm

This comment has been minimized.

Copy link

commented Apr 29, 2017

There are few threads with many people at the OSMC forum reporting the LG TV automatically switching source after updated to the new Kodi version. Initial effort was focused on if changes in OSMC or Kodi caused the behavior change, but it was narrowed down to the change in libcec. Based on the the logs provided in #307, the symptoms, and the changes, they match perfectly.

Note, my LG model is 55LS5700, a 5 years old TV. It was also working fine with 3.x version, and now switch source every time TV turns on.

@mfarrell34

This comment has been minimized.

Copy link

commented May 2, 2017

I've done some testing on my LG 65UF6450 with and without the SL_COMMAND_REQUEST_RECONNECT being handled and confirmed that removing this change and ignoring the 0b vendor command stops the input switching issue from occurring. When testing with lib-cec on a raspberry pi, I found:

-Regardless of whether the 0b command is handled or not, if SIMPLINK auto power sync was not enabled on my TV when turning on my TV by sending 'on 0' it would hang on the power status 'in transition from standby to on' and repeatedly broadcast device vendor id requests. Therefore I have to enable auto power sync mode on my TV in order to turn it on via a cec command.

-With auto power sync on my TV would request the cec adapter's physical address and vendor id. After receiving a response from the adapter my TV sent several 0b vendor commands followed by a 01 INIT vendor command, and then request the adapter device's power status. The adapter device's power status had been changed to standby during the INIT command handling, and then the power status was updated to 'on' during the REQUEST_POWER_STATUS command handling. This seems to indicate the adapter hadn't been the active source prior to this point (unless I'm reading it wrong and my raspberry pi wasn't the destination of the command). With the 0b command being ignored the active source was never set by the adapter, so the TV turned on and remained on the same input it had been on prior to being turned off.

What information indicated the 0b command was a reconnect request? I saw two 0b vendor commands followed by a 01 vendor command after the TV had already requested and received the adapter's physical address and vendor id.

I think the key difference in whether the input of the TV changes after it's powered on is whether the device had been marked as the active source prior to this. When HandleVendorCommandPowerOn is called to handle the 0b commands being received, this is marking the device as the active source which is then passed to the TV after it turns on and requests the active source. Also I never saw the 03 POWER_ON command from my TV when testing, it could vary from TV to TV but it doesn't seem correct that the power on command handler would be getting called before the init command handler, unless I'm misunderstanding.

@Vollstrecker

This comment has been minimized.

Copy link
Author

commented May 2, 2017

The reason for just ding the reconnect was, that after turning the TV off, Everest time I got 0b, Ich had to reconnect. Otherwise the TV didn't communicate with the adapter at all.

The cause for using The PowerON method was just, that I didn't find any other way to get that done.

I can't search the part would have preffered atm, as I'm away from home since 2 weeks now, and doing this search on my mobile isn't any sort of fun.

Btw: my TV doesn't change the source in the described situation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.