Closed Wlkus closed 5 months ago
Hi, from the log it looks like the wake on lan functionality stopped working (which is what actually power on the the TV). The log shows normal polling which goes on until the TV reports being powered on. The error message you are seeing is normal and is not an indication that something is going wrong.
Please starr by confirming that the wake on lan functionality of the TV is enabled and that the mac-address in the device configuration of the TV is correct
Everything on TV side was setup correctly, WOL enabled, external devices enabled. It was working like charm for some time, it just started behaving crazy few days ago. I took time to debug it now and tried: disabling eset firewall or adding rules for LGTV Comp. changed IP of TV through DHCP removed connection history in tv removing TV in LGTV Comp full reset of LGTV Comp
Nothing helped. Strange is that TV woke time to time correctly. I tried manual Turn off and Turn on through anydesk remote. And it usually worked on every 5-6th try. Very strange.
Then I restarted both network switches I have home and voila, it works no. But wtf?
Anyway thanks for tips and reply. 2 hours lost in process. Sending some $$, thanks for helping us TV as monitor users :-)
Resolved
Hmm seems that I closed this task too fast, problem is back. TV wakes randomly, it takes a lot of tries according to log.
Additional stuff I tested: Changed connection to wifi - tested two AP that I have at home - no change at all Turning computer switch - almost immediate TV on, but only first time after restart
It is very strange as connection is working, it is just very random and works after many attempts.
That's unfortunate! The IP connection seems to be working correctly all the time, but the WOL packet does not wake the TV (whether the issue is with the app, the network or the TV).
Can you try two other things then please to troubleshoot further:
Tried WOL tool - works like charm, instantly turning TV on with just one magic packet. Tried both options Broadcast IP/FQDN IP
Tried mobile WOL app on phone, again instant wake up.
Tried WOL script from my NAS - wake up on first try.
Tried all three options in LGTV Companion - no luck with any of them.
Uninstalled LGTV Companion and config file, registered everything again - nothing. Just doesnt wake up monitor.
Interesting! I noticed in the log you have two network interfaces on your PC (10.10.201.150/24, 172.19.96.1/20) . Do they correspond to two actual NICs? Can you disable the one pertaining to 172.19.96.1/20 and see if that changes anything?
There is one LAN Intel adapter, then Intel WiFi. That one with 172.19.96.1/20 is something virtual. Here is ipconfig /all
UPDATE: Strange, this HyperV adapter is not listed in Device manager. Will try to get rid of it, its not used...
Microsoft Windows [Version 10.0.22621.3447]
(c) Microsoft Corporation. All rights reserved.
C:\Windows\System32>ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : WLK-PC
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
Ethernet adapter Ethernet:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Intel(R) Ethernet Controller (3) I225-V
Physical Address. . . . . . . . . : A0-36-BC-07-88-68
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 2a00:1028:9194:ba96:218a:c2ec:789b:6dcc(Preferred)
Temporary IPv6 Address. . . . . . : 2a00:1028:9194:ba96:2c8b:84b4:fd6a:330f(Preferred)
Link-local IPv6 Address . . . . . : fe80::1a3f:bdb6:dc18:4852%3(Preferred)
IPv4 Address. . . . . . . . . . . : 10.10.201.150(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : neděle 14. dubna 2024 20:04:47
Lease Expires . . . . . . . . . . : pondělí 15. dubna 2024 20:51:00
Default Gateway . . . . . . . . . : fe80::7e10:c9ff:fe37:5da8%3
10.10.201.10
DHCP Server . . . . . . . . . . . : 10.10.201.10
DHCPv6 IAID . . . . . . . . . . . : 127940284
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-2B-15-29-BA-A0-36-BC-07-88-68
DNS Servers . . . . . . . . . . . : 2a00:1028:9194:ba96::1
8.8.8.8
8.8.4.4
10.10.201.10
NetBIOS over Tcpip. . . . . . . . : Enabled
Ethernet adapter Ethernet 2:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : TAP-NordVPN Windows Adapter V9
Physical Address. . . . . . . . . : 00-FF-FA-2F-FE-14
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Wireless LAN adapter Wi-Fi:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Intel(R) Wi-Fi 6E AX211 160MHz
Physical Address. . . . . . . . . : 2C-0D-A7-FA-B4-CD
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Wireless LAN adapter Local Area Connection* 9:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft Wi-Fi Direct Virtual Adapter
Physical Address. . . . . . . . . : 2C-0D-A7-FA-B4-CE
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Wireless LAN adapter Local Area Connection* 10:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft Wi-Fi Direct Virtual Adapter #2
Physical Address. . . . . . . . . : 2E-0D-A7-FA-B4-CD
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Ethernet adapter Bluetooth Network Connection 2:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Bluetooth Device (Personal Area Network) #2
Physical Address. . . . . . . . . : 2C-0D-A7-FA-B4-D1
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Ethernet adapter vEthernet (Default Switch):
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter
Physical Address. . . . . . . . . : 00-15-5D-FE-CB-A8
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::c608:76ee:b3a:8ceb%24(Preferred)
IPv4 Address. . . . . . . . . . . : 172.28.64.1(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.240.0
Default Gateway . . . . . . . . . :
DHCPv6 IAID . . . . . . . . . . . : 402658653
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-2B-15-29-BA-A0-36-BC-07-88-68
NetBIOS over Tcpip. . . . . . . . : Enabled
This sounds similar to this old issue: https://github.com/JPersson77/LGTVCompanion/issues/6 on the surface. I also remember someone else had an issue with nord-vpn but can't remember if it was the same issue. However if the TV can be awoken with another WOL-app then something is wrong here. My suspicion is that the WOL-packet is going out the wrong adapter. If you are proficient with using wireshark I think that could provide insight
Removed Hyper-V Virtual Ethernet Adapter by uninstalling windows optional Hyper-V support, still no change. App wont wake tv, any other packet works fine. Will try to get rid of NordVPN, but it was there before. It started behaving like this during last week, I suspect some update of system or apps. But its strange. Never used Wireshark, but will try to learn. Have no probs with technical stuff.
Its strange that when I turn TV off and connect to PC through anydesk from phone, hammering Turn on function in LGTV Comp result sooner or later in success. In log I see that app is trying to continuously send magic packets, I see newly issued Turn on commands, it takes 5-6 till it starts.
Wireshark is an IP-sniffer tool and can be configured to listen to a particular network interface for packets going from the adapter to the TV. And more! It's not terribly difficult to set up and get up and running so that could help. You could for example monitor the difference between using the WOL-app you downloaded on the same PC with the packages that LGTV companion send out. It would be great to get more info and clues
Just work in progress, here is the example of one session where LGTVcomp was able to turn TV on. First try was successful after few repeats, other I lost patience and used phone to wake it up.
Sun 21:20:40 > -poweroff Device1
Sun 21:20:40 > [IPC] Force power OFF: Device1
Sun 21:20:40 > Device1, spawning Thread_DisplayOff().
Sun 21:20:40 > Device1, [DEBUG] (SSL) OFF response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:20:40 > Device1, [DEBUG] (SSL) OFF response 2: {"type":"response","id":29,"payload":{"state":"Active","returnValue":true}}
Sun 21:20:40 > Device1, [DEBUG] (SSL) OFF response 4: {"type":"response","id":30,"payload":{"returnValue":true}}
Sun 21:20:40 > Device1, power state is: OFF.
Sun 21:20:46 > -poweron Device1
Sun 21:20:46 > [IPC] Force power ON: Device1
Sun 21:20:46 > Device1, spawning Thread_DisplayOn().
Sun 21:20:46 > Device1, repeating WOL broadcast started to MAC: F801B45726E6 using network broadcast: 255.255.255.255
Sun 21:20:46 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:20:46 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":31,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:20:46 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":32,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:20:47 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:20:47 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":33,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:20:47 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":34,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:20:48 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:20:48 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":35,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:20:48 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":36,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:20:49 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:20:49 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":37,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:20:49 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":38,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:20:50 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:20:50 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":39,"error":"500 Application error","payload":{"returnValue":false,"state":"Screen On","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:20:50 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":40,"payload":{"state":"Active Standby","processing":"Screen On","returnValue":true}}
Sun 21:20:51 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:20:51 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":41,"error":"500 Application error","payload":{"returnValue":false,"state":"Screen On","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:20:51 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":42,"payload":{"state":"Active Standby","processing":"Screen On","returnValue":true}}
Sun 21:20:53 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:20:53 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":43,"error":"500 Application error","payload":{"returnValue":false,"state":"Screen On","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:20:53 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":44,"payload":{"state":"Active Standby","processing":"Screen On","returnValue":true}}
Sun 21:20:53 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:20:53 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":45,"error":"500 Application error","payload":{"returnValue":false,"state":"Screen On","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:20:53 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":46,"payload":{"state":"Active Standby","processing":"Screen On","returnValue":true}}
Sun 21:20:54 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:20:54 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":47,"error":"500 Application error","payload":{"returnValue":false,"state":"Active","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:20:54 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":48,"payload":{"state":"Active","returnValue":true}}
Sun 21:20:54 > Device1, power state is: ON
Sun 21:20:55 > Device1, repeating WOL broadcast ended
Sun 21:21:52 > -poweroff Device1
Sun 21:21:52 > [IPC] Force power OFF: Device1
Sun 21:21:52 > Device1, spawning Thread_DisplayOff().
Sun 21:21:52 > Device1, [DEBUG] (SSL) OFF response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:21:52 > Device1, [DEBUG] (SSL) OFF response 2: {"type":"response","id":50,"payload":{"state":"Active","returnValue":true}}
Sun 21:21:52 > Device1, [DEBUG] (SSL) OFF response 4: {"type":"response","id":1,"payload":{"returnValue":true}}
Sun 21:21:52 > Device1, power state is: OFF.
Sun 21:21:57 > -poweron Device1
Sun 21:21:57 > [IPC] Force power ON: Device1
Sun 21:21:57 > Device1, spawning Thread_DisplayOn().
Sun 21:21:57 > Device1, repeating WOL broadcast started to MAC: F801B45726E6 using network broadcast: 255.255.255.255
Sun 21:21:57 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:21:57 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":2,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:21:57 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":3,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:21:58 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:21:58 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":4,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:21:58 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":5,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:21:59 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:21:59 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":6,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:21:59 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":7,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:22:00 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:00 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":8,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:00 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":9,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:22:01 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:01 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":10,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:01 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":11,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:22:03 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:03 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":12,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:03 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":13,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:22:03 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:03 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":14,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:03 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":15,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:22:04 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:04 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":16,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:04 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":17,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:22:05 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:05 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":18,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:05 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":19,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:22:06 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:06 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":20,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:06 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":21,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:22:07 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:07 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":22,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:07 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":23,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:22:08 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:08 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":24,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:08 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":25,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:22:09 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:09 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":26,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:09 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":27,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:22:10 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:10 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":28,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:10 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":29,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:22:11 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:11 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":30,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:11 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":31,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:22:12 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:12 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":32,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:12 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":33,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:22:13 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:13 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":34,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:13 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":35,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:22:14 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:14 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":36,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:14 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":37,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:22:15 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:15 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":38,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:15 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":39,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:22:16 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:16 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":40,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:16 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":41,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:22:18 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:18 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":42,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:18 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":43,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:22:18 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:18 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":44,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:18 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":45,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:22:19 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:19 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":46,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:19 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":47,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:22:20 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:20 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":48,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:20 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":49,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:22:21 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:21 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":50,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:21 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":1,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:22:22 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:22 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":2,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:22 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":3,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:22:23 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:23 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":4,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:23 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":5,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:22:24 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:24 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":6,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:24 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":7,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:22:25 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:25 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":8,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:25 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":9,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:22:26 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:26 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":10,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:26 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":11,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:22:27 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:27 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":12,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:27 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":13,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:22:28 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:28 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":14,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:28 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":15,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:22:29 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:29 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":16,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:29 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":17,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:22:30 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:30 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":18,"error":"500 Application error","payload":{"returnValue":false,"state":"Screen On","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:31 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":19,"payload":{"state":"Active Standby","processing":"Screen On","returnValue":true}}
Sun 21:22:31 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:31 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":20,"error":"500 Application error","payload":{"returnValue":false,"state":"Screen On","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:31 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":21,"payload":{"state":"Active Standby","processing":"Screen On","returnValue":true}}
Sun 21:22:32 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:32 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":22,"error":"500 Application error","payload":{"returnValue":false,"state":"Screen On","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:32 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":23,"payload":{"state":"Active Standby","processing":"Screen On","returnValue":true}}
Sun 21:22:33 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:22:33 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":24,"error":"500 Application error","payload":{"returnValue":false,"state":"Active","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:22:33 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":25,"payload":{"state":"Active","returnValue":true}}
Sun 21:22:33 > Device1, power state is: ON
Sun 21:22:33 > Device1, repeating WOL broadcast ended
https://wiki.wireshark.org/WakeOnLAN
Also, there is a listener in the WOL-app you downloaded. It can capture and display WOL-packets sent to 255.255.255.255 (network broadcast), i.e. option 1 in the LGTV companion app. It will not capture packets to IP (default option 2) as you need wireshark to do that. Might be an easier start
Have wireshark up and running, with filter for WoL magic packets, and found this. It waked display but with delay. Seems that first packet went to wrong interface, but there was correct on few secs later.
UPDATE: It was random success. Tried two more times and there was no packet captured at all. Same settings used, just pressed Test clicked Yes, waited, pressed enter. Nothing. Screens and log are for successful test.
Sun 21:44:55 > -poweroff Device1
Sun 21:44:55 > [IPC] Force power OFF: Device1
Sun 21:44:55 > Device1, spawning Thread_DisplayOff().
Sun 21:44:55 > Device1, [DEBUG] (SSL) OFF response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:44:55 > Device1, [DEBUG] (SSL) OFF response 2: {"type":"response","id":36,"payload":{"state":"Active","returnValue":true}}
Sun 21:44:55 > Device1, [DEBUG] (SSL) OFF response 4: {"type":"response","id":37,"payload":{"returnValue":true}}
Sun 21:44:55 > Device1, power state is: OFF.
Sun 21:45:01 > -poweron Device1
Sun 21:45:01 > [IPC] Force power ON: Device1
Sun 21:45:01 > Device1, spawning Thread_DisplayOn().
Sun 21:45:01 > Device1, repeating WOL broadcast started to MAC: F801B45726E6 using network broadcast: 255.255.255.255
Sun 21:45:01 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:45:01 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":38,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:45:01 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":39,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:45:02 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:45:02 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":40,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:45:02 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":41,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:45:03 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:45:03 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":42,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:45:03 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":43,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:45:04 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:45:04 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":44,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:45:04 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":45,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:45:05 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:45:05 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":46,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:45:05 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":47,"payload":{"state":"Active Standby","returnValue":true}}
Sun 21:45:21 > Device1, WARNING! Thread_DisplayOn(): handshake: An existing connection was forcibly closed by the remote host [system:10054]
Sun 21:45:22 > Device1, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"932070516232afe0aaae72c3ca506aa4"}}
Sun 21:45:22 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":48,"error":"500 Application error","payload":{"returnValue":false,"state":"Active","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Sun 21:45:22 > Device1, [DEBUG] (SSL) ON response 3: {"type":"response","id":49,"payload":{"state":"Active","returnValue":true}}
Sun 21:45:22 > Device1, power state is: ON
Sun 21:45:22 > Device1, repeating WOL broadcast ended
I think both screenshots show the same package, but for different adapters. Both are at time 0 (i.e. immediately), at the LAN adapter and the Loopback adapter. But, as evident in the log the TV did not turn on, so there should be similar entries, each for a new WOL package, every 1-2 seconds (until the TV communicates it has turned on or the power on timeout occurs, 40 secs by default).
Why? No idea at the moment so I will think about it
Result from my side after hour of playing is that LGTV comp is just not sending WOL packet even though it says so in the log. Wireshark just doesn't capture anything (running on all local interfaces) even though it works correctly with other apps like Wakeonlan or ColorControl.
It is strange, because it was working flawlessly just few days ago. Also strange is that it randomly sends packet when I hammer Turn on function again and again, but cannot repeat this and figure out why it works sometimes. Using Anydesk remote connection from mobile device for that, which could also somehow influence behavior.
Tried even clean uninstall with settings removed and tested previous version 3.4. Same results, no magic packet captured in Wireshark.
did you by any chance install webos23 recently on your TV. Not that it would directly influence the WOL packets from your PC but just checking
Have it on autoupdate, ver of firmware is 03.30.73 not sure how to check webos. But this seems to me more related to my PC...
UPDATE webOS TV Version shows 8.3.0-1506
OK I see in the post title you are running a C3 so you already have webos23. I noticed a warning in a log you posted about a -handshake issue so I am cross-thinking to another issue discussed on discord. But yes it seems to do with your PC and the app specifically
Do you mind coming to the Discord server and try a test build?
As I was reading quickly through this issue, I realized it is a very recent and relevant to an issue I am experiencing so I hope it's OK to add to this issue rather than create a new one.
I have 2 LG OLED TV's connected to my computer - a C2 42" and a C1 48". I have been using your great application to control both. I don't know what I would do without your app, so thank you for all the work you have and continue to put into it.
If I am not mistaken, I am experiencing a very similar issue to the OP. The app had been working pretty much without issues for 2+ years. However, recently I began having issues where the LG TV's intermittently either don't wake/sleep as they had been for past 2 years. The typical behavior had been the TV's would wake upon mouse movement or touching a key on keyboard. I never really extensively tested the sleep feature, but basically when I would lock my computer for the evening and go to sleep, once windows was at the user login screen, the TV's would turn off for the night within maybe 10 seconds.
I'm not sure why, but recently as in within the past 2 or 3 weeks, the TV's seem to have a sometimes extended delay when waking/sleeping or may not respond at all. For example, upon arrival at my desk this AM, I attempted to wake the TV's by moving mouse / pressing keys, etc. Both TV's remained off for about a minute until one of them woke and I was able to login. The other TV never turned on, but as soon as I was able to login, I was able to turn it on with your application manually with no issue.
My C2 did receive some big webOS update recently which changed the UI, but the issue occurs on both the C2 and C1. My log file is kind of huge, but I don't know how much of it is useful or not, so I just uploaded the entire file.
It's a very odd issue as everything had been working flawlessly for so long. I am not aware of any other changes which could have impacted this and would be grateful for any help. As it is currently working, most of the time it does complete the wake/sleep action. It's just unknown how long of a delay it will be. I am just trying to figure out what introduced the delay to hopefully fix it.
Hi @joebeem I had a look at the log and nothing immediately stands out. The issue with @Wlkus is likely a compatibility issue with Eset Internet Security which I'm thinking about how to workaround. What I'd normally recommend to do for issues like these are to restart all network equipment, including switches, access points etc which usually solves many mysterious network issues.
@joebeem I do see a SSL handshake issue in your log however which I've noticed for a few others recently. It is not clear if it is due to webos23. THere is a development build on Discord (see link above) if you want to try it and feedback on how it works for you
Hello, first of all, really thank you for your hard work with this awesome application!
I'm experiencing same problem as two guys here. For about week or so, TV (C1) cannot be turned on. But black screen in idle and "resuming" screen works. So it looks like WOL problem. As I was reading through this issue, I noticed that I have "problematic" setup, since I have hyper-V adapter, nordvpn adapter and also ESET Smart Security installed. Do you think, that my AV is somehow the culprit here?
It's been a week without reply here, so I'm just checking, whether those beta builds helped. If needed new volunteer for testing that build, I can definitely do that for you and also provide logs.
Thanks for your work.
Unfortunately no working solution yet. Seems that culprit is ESET, as I uninstalled even NordVPN but without any success. Only solution which helped was removing antivirus, which somehow magically eating magic packets without noticing nor telling user that something is wrong. Just disabling network protection of ESET doesnt help.
I tried even writing to their support, but there was no feedback.
Using ColorControl instead temporarily, it has better success sending WOL packets. But lately starts showing same symptoms. Some packets are lost, especially after longer periods in suspend state (ie overnight).
Thanks too! Like @Wlkus mentions here is no conclusion on the WOL issue (which is what cause the display to not turn on. The SSL handshake is another issue) but yeah uninstalling ESET seems to solve the issue, the rate limiting in the beta build does not seem to change anything.If you have the opportunity to try and uninstall ESET it I'd be interested in your feedback. Meanwhile I'm looking over the network code..
@aklozep can you please try the other WOL options, primarily option 1, and see if that improves the issue?
Btw I'm also looking into the SSL handshake issue
Hello, selecting option 1, same behavior ->
Tue 10:31:54 > LGTV Companion Service started (v 3.5.0) --------------------------- Tue 10:31:54 > Data path: C:\ProgramData\LGTV Companion\ Tue 10:31:54 > Device1, [LG] webOS TV OLED55CX3LA, with IP 192.168.160.212 initiated (Enabled:no, NewConn:yes, WOL:2, SubnetMask:255.255.255.0, PairingKey:n/a, MAC: AC:F1:08:ED:92:D4 , VerifyHdmiInput:off, SetHdmiInput:off, BlankOnIdle:on(3m)) Tue 10:31:54 > Device2, [LG] webOS TV OLED48C11LB, with IP 192.168.160.123 initiated (Enabled:yes, NewConn:yes, WOL:1, SubnetMask:255.255.255.0, PairingKey:fa7d0f0945ab9587851b0ca3ff70ed80, MAC: DC:03:98:14:C5:F0 , VerifyHdmiInput:off, SetHdmiInput:off, BlankOnIdle:on(3m)) Tue 10:31:54 > Host IPs detected: 10.5.0.2/16, 172.17.112.1/20, 192.168.2.1/24, 192.168.131.1/24, 192.168.160.2/24 Tue 10:31:54 > Shutdown timing: early Tue 10:31:54 > ** System requests displays ON. Tue 10:31:54 > Device2, spawning Thread_DisplayOn(). Tue 10:31:54 > Device2, repeating WOL broadcast started to MAC: DC039814C5F0 using network broadcast: 255.255.255.255 Tue 10:31:54 > Device2, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"fa7d0f0945ab9587851b0ca3ff70ed80"}} Tue 10:31:54 > Device2, [DEBUG] (SSL) ON response 2: {"type":"error","id":1,"error":"500 Application error","payload":{"returnValue":false,"state":"Active","errorCode":"-102","errorText":"The current state must be 'Screen Off'"}} Tue 10:31:54 > Device2, [DEBUG] (SSL) ON response 3: {"type":"response","id":2,"payload":{"returnValue":true,"state":"Active"}} Tue 10:31:54 > Device2, power state is: ON Tue 10:31:54 > -daemon 8 started Tue 10:31:54 > [IPC Daemon 8] Started. Tue 10:31:55 > Device2, repeating WOL broadcast ended Tue 10:35:38 > ** System requests displays OFF. Tue 10:35:38 > Device2, spawning Thread_DisplayOff(). Tue 10:35:38 > Device2, [DEBUG] (SSL) OFF response 1: {"type":"registered","id":"register_0","payload":{"client-key":"fa7d0f0945ab9587851b0ca3ff70ed80"}} Tue 10:35:38 > Device2, [DEBUG] (SSL) OFF response 2: {"type":"response","id":4,"payload":{"returnValue":true,"state":"Active"}} Tue 10:35:38 > Device2, [DEBUG] (SSL) OFF response 4: {"type":"response","id":5,"payload":{"returnValue":true}} Tue 10:35:38 > Device2, power state is: OFF. Tue 10:35:38 > ** System is suspending to a low power state.(or event callback is missing) Tue 10:36:56 > ** System resumed from low power state. Tue 10:36:56 > ** System requests displays ON. Tue 10:36:56 > Device2, spawning Thread_DisplayOn(). Tue 10:36:56 > Device2, repeating WOL broadcast started to MAC: DC039814C5F0 using network broadcast: 255.255.255.255 Tue 10:36:58 > ** System resumed from low power state (Automatic). Tue 10:37:17 > Device2, WARNING! Thread_DisplayOn(): connect: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond [system:10060 at D:\a\LGTVCompanion\LGTVCompanion\vcpkg_installed\x64-windows-static\x64-windows-static\include\boost\asio\detail\win_iocp_socket_service.hpp:629:5 in function 'connect'] Tue 10:37:22 > -daemon 9 started Tue 10:37:22 > [IPC Daemon 9] Started. Tue 10:37:38 > Device2, WARNING! Thread_DisplayOn(): connect: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond [system:10060 at D:\a\LGTVCompanion\LGTVCompanion\vcpkg_installed\x64-windows-static\x64-windows-static\include\boost\asio\detail\win_iocp_socket_service.hpp:629:5 in function 'connect'] Tue 10:37:59 > Device2, WARNING! Thread_DisplayOn(): connect: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond [system:10060 at D:\a\LGTVCompanion\LGTVCompanion\vcpkg_installed\x64-windows-static\x64-windows-static\include\boost\asio\detail\win_iocp_socket_service.hpp:629:5 in function 'connect'] Tue 10:38:21 > Device2, WARNING! Thread_DisplayOn(): connect: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond [system:10060 at D:\a\LGTVCompanion\LGTVCompanion\vcpkg_installed\x64-windows-static\x64-windows-static\include\boost\asio\detail\win_iocp_socket_service.hpp:629:5 in function 'connect'] Tue 10:38:21 > Device2, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"fa7d0f0945ab9587851b0ca3ff70ed80"}} Tue 10:38:21 > Device2, [DEBUG] (SSL) ON response 2: {"type":"error","id":6,"error":"500 Application error","payload":{"returnValue":false,"errorCode":"-2","errorText":"com.webos.service.tvpower/power is busy"}} Tue 10:38:21 > Device2, [DEBUG] (SSL) ON response 3: {"type":"response","id":7,"payload":{"returnValue":true,"state":"Suspend","processing":"Screen On"}} Tue 10:38:22 > Device2, [DEBUG] (SSL) ON response 1: {"type":"registered","id":"register_0","payload":{"client-key":"fa7d0f0945ab9587851b0ca3ff70ed80"}} Tue 10:38:22 > Device2, [DEBUG] (SSL) ON response 2: {"type":"error","id":8,"error":"500 Application error","payload":{"returnValue":false,"state":"Active","errorCode":"-102","errorText":"The current state must be 'Screen Off'"}} Tue 10:38:22 > Device2, [DEBUG] (SSL) ON response 3: {"type":"response","id":9,"payload":{"returnValue":true,"state":"Active"}} Tue 10:38:22 > Device2, power state is: ON Tue 10:38:22 > Device2, repeating WOL broadcast ended
I have two LG TVs on network, that 55" is used as TV, so we can ignore it in this case. My monitor/TV is that 48". It stopped broadcasting WOL, because I manually turned it on with remote after a while.
I'm investigating behavior with ESET Smart Security and its settings/exclusions.
Wish you good luck with ESET settings. Just FYI what I tried and didnt help:
What really helped was full uninstall of ESET.
My observation - network part of ESET somehow blocks specially LGTV Companion, but in limited scope even other apps sending WOL packets. ESET internally doesnt show any info about blocked packets, probably some unintended bug.
Strange is that blocking is almost 100% for LGTV Companion, other apps are blocked randomly or have other troubles. Could be connected to fact that LGTV Companion doesnt have app signature?
I created rule in ESS to notify me when any traffic from my computer try to contact IP of my TV and specifically allowed communication. I can see in popups, that LGTV companion is sending request and ESS is allowing traffic. Also I tried disabling all protection, FW and many other setting I could think of. No success. But I could see from popups that traffic is allowed.
After I uninstalled ESS, LGTV companion started to work perfectly.
I also tried LGTV companion from my NTB, where I have EES installed (business branch of ESET AV) and there it works without problems.
Installed ESS 17.1.9.0 and made no changes to settings, only exclusion for folders. And it works now. Quite strange but you can try too. Will be observing behavior in future days, whether it will stuck itself somehow after time.
Tried full fresh reinstall of ESET, aslo using ESET Internet Security v17.1.9.0 - no change. You mentioned exclusions for folders, what did you mean by that?
Regarding business version of ESET, we had in office version without firewall, but I assume that there is also business solution with FW. Its more like home version has faster dev process and getting new features sooner than business branch, where you focus on stability.
That's really weird if fresh install is not working for you. By exclusion I mean: Have you resterted PC after uninstalling ESS?
ESET have more products, but basically most common for end users are: ESET Endpoint Security - For business with FW ESET Endpoint Antivirus - For business without FW ESET Smart Security - For home users with FW
I turned off PC and turned it on again (not restart but proper shutdown) and it works for me. Can you try to uninstall Internet Security and install Smart Security? Just for fun, maybe there is some difference. If you have proper licence of corse.
If not, I can look at it at the evening and "downgrade" ESET to try it with Internet Security.
I am one of the others that posted here with similar issues. One thing I did not report at the time was that I am also using ESET Internet Security. I didn't think it was relevant at the time because I had been using it for years, but perhaps something changed. I'd love to be able to get ESET working with it again if it turns out to be the issue for me as well. I am going to try to remove it to see if it fixes my issues and I will report back soon.
@joebeem thanks for info I hope you can confirm a compatibility issue with ESET by uninstalling. I have no definitive idea what ESET is doing but I can nevertheless take a guess, so I'm doing some work to upgrade the code and we'll see if that helps. I will let you know in this thread when there is something to test
Just to add bit more info, even ColorControl is lossing its ability to wake up LG. Now it is like 50% success rate. Same culprit, ESET is somehow eating magic packets. There was update to ESET core today, requidlred restart, but no change for me...
On Sun, Apr 28, 2024, 09:52 JPersson77 @.***> wrote:
@joebeem https://github.com/joebeem thanks for info and confirming if there is a compatibility issue with ESET! I have no definitive idea what ESET is doing but I can nevertheless take a guess, so I'm doing some work to upgrade the code and we'll see if that helps. I will let you know in this thread when there is something to test
— Reply to this email directly, view it on GitHub https://github.com/JPersson77/LGTVCompanion/issues/208#issuecomment-2081378705, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKW63DD7KB6NOS3HMQWO3DY7STEZAVCNFSM6AAAAABGGEMMBGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBRGM3TQNZQGU . You are receiving this because you were mentioned.Message ID: @.***>
I have tried this scenario with ESET Internet Security and it's working for me without problem. But I don't have problem with any ESET product now. Kinda weird. Can you uninstall both, ESET AV and also LGTV Companion, reboot PC and install it all over again? Maybe it will help. Also there is 17.1.11.0 version now available. So maybe you will have better luck with it.
Hi @aklozep @Wlkus @joebeem there is a dev build (v3.6.6) to address the SSL handshake issue and also attempt to fix issues outlined in this thread on Discord if you want to try https://discord.gg/7KkTPrP3fq .
Seems that it works fine, will switch to LGTV Companion from ColorControl and test it more. But it looks really promising! Good job.
UPDATE: Using version 3.6.8
Just an update, as happened before, after initial phase where everything seems to be working fine the waking up part which uses magic packets starts behaving erratically and instead immediately waking display it takes few seconds to go through. Unfortunately logging is now very brief and doesnt show repeated attempts to wake display up. Maybe adding line with each attempt to send WOL packet would help to see how long does it take to turn display on...
Thu 08:59:44 > System resumed from low power state. Thu 08:59:44 > System requests displays ON. Thu 08:59:46 > System resumed from low power state (Automatic). Thu 10:57:27 > System requests displays OFF(DIMMED). Thu 11:01:39 > System requests displays ON. Thu 12:25:33 > System requests displays OFF(DIMMED). Thu 12:35:43 > System requests displays OFF. Thu 12:46:17 > System is suspending to a low power state.(or event callback is missing) Thu 13:07:28 > System resumed from low power state (Automatic). Thu 13:07:28 > System resumed from low power state. Thu 13:07:28 > ** System requests displays ON.
the log is (temporarily) in async_session_log.txt. Please paste that
UPDATE1: Just an observation, it usually takes longer to wake up from proper sleep. When I test it just by turning display off with script, it works fine and turns on immediately.
UPDATE2: Tried to sleep PC and turned it on immediately after few secs and display turned on immediately. But seeing these longer wakeups regularly after longer sleeps. Will try to watch it carefully and try to get the pattern...
Thu May 09 12:25:33 [LG] > ----- START POWER OFF -----
Thu May 09 12:25:33 [LG] > Sending: {"type":"request","id":"getPowerState","uri":"ssap://com.webos.service.tvpower/power/getPowerState","payload":{}}
Thu May 09 12:25:33 [LG] > Received: {"type":"response","id":"getPowerState","payload":{"state":"Active","returnValue":true}}
Thu May 09 12:25:33 [LG] > INFO! Power state is at the moment ON
Thu May 09 12:25:33 [LG] > Sending: {"type":"request","id":"powerToggle","uri":"ssap://system/turnOff","payload":{}}
Thu May 09 12:25:33 [LG] > Received: {"type":"response","id":"powerToggle","payload":{"returnValue":true}}
Thu May 09 12:25:33 [LG] > Power state is OFF
Thu May 09 12:25:33 [LG] > Work queue has been emptied!
Thu May 09 13:07:28 [LG] > Enqueueing work of type: 1
Thu May 09 13:07:28 [LG] > Enqueueing work of type: 4
Thu May 09 13:07:28 [LG] > Starting new queued work unit of type: 1
Thu May 09 13:07:28 [LG] > ----- START POWER ON -----
Thu May 09 13:07:28 [LG] > Sending: {"type":"request","id":"getPowerState","uri":"ssap://com.webos.service.tvpower/power/getPowerState","payload":{}}
Thu May 09 13:07:28 [LG] > Can not start new work yet, busy!
Thu May 09 13:07:47 [LG] > ERROR! async_read() failed (error: The semaphore timeout period has expired)
Thu May 09 13:07:47 [LG] > Invalid socket.
Thu May 09 13:07:47 [LG] > INFO! Retrying connection...
Thu May 09 13:07:47 [LG] > Sending out magic packets (WOL)
Thu May 09 13:07:48 [LG] > ARP override best source: 10.10.201.150, Interface index: 3, LUID: 1689399632855040, Route protocol: 2
Thu May 09 13:07:48 [LG] > WOL - bytes sent: 102
Thu May 09 13:07:48 [LG] > WOL - bytes sent: 102
Thu May 09 13:07:48 [LG] > WOL - bytes sent: 102
Thu May 09 13:07:48 [LG] > Sending: {"type":"register","id":"register_0","payload":{"forcePairing":false,"pairingType":"PROMPT","client-key":"4572942fe9d41176b19270927601a209","manifest":{"manifestVersion":1,"appVersion":"1.1","signed":{"created":"20140509","appId":"com.lge.test","vendorId":"com.lge","localizedAppNames":{"":"LG Remote App","ko-KR":"리모컨 앱","zxx-XX":"ЛГ Rэмotэ AПП"},"localizedVendorNames":{"":"LG Electronics"},"permissions":["TEST_SECURE","CONTROL_INPUT_TEXT","CONTROL_MOUSE_AND_KEYBOARD","READ_INSTALLED_APPS","READ_LGE_SDX","READ_NOTIFICATIONS","SEARCH","WRITE_SETTINGS","WRITE_NOTIFICATION_ALERT","CONTROL_POWER","READ_CURRENT_CHANNEL","READ_RUNNING_APPS","READ_UPDATE_INFO","UPDATE_FROM_REMOTE_APP","READ_LGE_TV_INPUT_EVENTS","READ_TV_CURRENT_TIME"],"serial":"2f930e2d2cfe083771f68e4fe7bb07"},"permissions":["LAUNCH","LAUNCH_WEBAPP","APP_TO_APP","CLOSE","TEST_OPEN","TEST_PROTECTED","CONTROL_AUDIO","CONTROL_DISPLAY","CONTROL_INPUT_JOYSTICK","CONTROL_INPUT_MEDIA_RECORDING","CONTROL_INPUT_MEDIA_PLAYBACK","CONTROL_INPUT_TV","CONTROL_POWER","CONTROL_TV_SCREEN","READ_APP_STATUS","READ_CURRENT_CHANNEL","READ_INPUT_DEVICE_LIST","READ_NETWORK_STATE","READ_RUNNING_APPS","READ_TV_CHANNEL_LIST","WRITE_NOTIFICATION_TOAST","READ_POWER_STATE","READ_COUNTRY_INFO","READ_SETTINGS"],"signatures":[{"signatureVersion":1,"signature":"eyJhbGdvcml0aG0iOiJSU0EtU0hBMjU2Iiwia2V5SWQiOiJ0ZXN0LXNpZ25pbmctY2VydCIsInNpZ25hdHVyZVZlcnNpb24iOjF9.hrVRgjCwXVvE2OOSpDZ58hR+59aFNwYDyjQgKk3auukd7pcegmE2CzPCa0bJ0ZsRAcKkCTJrWo5iDzNhMBWRyaMOv5zWSrthlf7G128qvIlpMT0YNY+n/FaOHE73uLrS/g7swl3/qH/BGFG2Hu4RlL48eb3lLKqTt2xKHdCs6Cd4RMfJPYnzgvI4BNrFUKsjkcu+WD4OO2A27Pq1n50cMchmcaXadJhGrOqH5YmHdOCj5NSHzJYrsW0HPlpuAx/ECMeIZYDh6RMqaFM2DXzdKX9NmmyqzJ3o/0lkk/N97gfVRLW5hA29yeAwaCViZNCP8iC9aO0q9fQojoa7NQnAtw=="}]}}}
Thu May 09 13:07:48 [LG] > Received: {"type":"registered","id":"register_0","payload":{"client-key":"4572942fe9d41176b19270927601a209"}}
Thu May 09 13:07:48 [LG] > Sending: {"type":"request","id":"getPowerState","uri":"ssap://com.webos.service.tvpower/power/getPowerState","payload":{}}
Thu May 09 13:07:48 [LG] > Received: {"type":"response","id":"getPowerState","payload":{"state":"Suspend","processing":"Prepare Resume","returnValue":true}}
Thu May 09 13:07:48 [LG] > INFO! Power state is Suspend
Thu May 09 13:07:49 [LG] > WOL - bytes sent: 102
Thu May 09 13:07:49 [LG] > WOL - bytes sent: 102
Thu May 09 13:07:49 [LG] > WOL - bytes sent: 102
Thu May 09 13:07:49 [LG] > Sending: {"type":"request","id":"getPowerState","uri":"ssap://com.webos.service.tvpower/power/getPowerState","payload":{}}
Thu May 09 13:07:49 [LG] > Received: {"type":"response","id":"getPowerState","payload":{"state":"Suspend","processing":"Screen On","returnValue":true}}
Thu May 09 13:07:49 [LG] > INFO! Power state is Suspend
Thu May 09 13:07:50 [LG] > WOL - bytes sent: 102
Thu May 09 13:07:50 [LG] > WOL - bytes sent: 102
Thu May 09 13:07:50 [LG] > WOL - bytes sent: 102
Thu May 09 13:07:50 [LG] > Sending: {"type":"request","id":"getPowerState","uri":"ssap://com.webos.service.tvpower/power/getPowerState","payload":{}}
Thu May 09 13:07:50 [LG] > Received: {"type":"response","id":"getPowerState","payload":{"state":"Suspend","processing":"Screen On","returnValue":true}}
Thu May 09 13:07:50 [LG] > INFO! Power state is Suspend
Thu May 09 13:07:51 [LG] > WOL - bytes sent: 102
Thu May 09 13:07:51 [LG] > WOL - bytes sent: 102
Thu May 09 13:07:51 [LG] > WOL - bytes sent: 102
Thu May 09 13:07:51 [LG] > Sending: {"type":"request","id":"getPowerState","uri":"ssap://com.webos.service.tvpower/power/getPowerState","payload":{}}
Thu May 09 13:07:51 [LG] > Received: {"type":"response","id":"getPowerState","payload":{"state":"Active","returnValue":true}}
Thu May 09 13:07:51 [LG] > INFO! Power state is ON
Thu May 09 13:07:51 [LG] > Starting new queued work unit of type: 4
Thu May 09 13:07:51 [LG] > ----- START SEND REQUEST -----
Thu May 09 13:07:51 [LG] > Sending: {"id":"request","payload":{"id":"com.webos.app.hdmi1"},"type":"request","uri":"ssap://system.launcher/launch"}
Thu May 09 13:07:52 [LG] > Received: {"type":"response","id":"request","payload":{"returnValue":true,"id":"com.webos.app.hdmi1","sessionId":"Y29tLndlYm9zLmFwcC5oZG1pMQ=="}}
Thu May 09 13:07:52 [LG] > Work queue has been emptied!
Thu May 09 13:07:52 [LG] > Done sending out WOL.
From the log it does not look like the original issue. There is a delay from 13.07.28 to 13.07.47 before the WOL packages was sent out due to "semaphore timeout period has expired" at which point the WOL packages went out and it seems like it then woke the device. It rather looks like a minor flaw in the logic and I think it has been fixed already. Can probably upload a new dev build soon
v3.7.8 dev build is on #development-builds now. See if that works for you :)
So far so good, working as intended and didnt notice any wakeup delays...
Good job!
How is v4.0.0 working for you?
Works perfectly now, not a single missed wakeup. Thanks a lot!
That is good to hear! @aklozep @joebeem any input from you wrt the new version and the issues as stated above?
closing the issue, feel free to reopen as needed please. Cheers
App was working perfectly for month or so, but last few days is total hit and miss. It turns TV off correctly, but turning it on is different story. Seems like screen even when it seems off is in some "Active standby" instead of "screen off". Any tips or idea how to make it work again?
Attaching log, but main reason seems to me like
Sun 13:38:26 > Device1, [DEBUG] (SSL) ON response 2: {"type":"error","id":38,"error":"500 Application error","payload":{"returnValue":false,"state":"Active Standby","errorCode":"-102","errorText":"The current sub state must be 'screen off'"}}
Full log is here: Log.txt