Thanks for the reply, i"m aware of the main purpose of this box but it's outdated
I tried to explore other options such as emulator or linux etc but no build was found or found to be working to be exactI don't mind an old kernel but apart from the original outdated android and libreelec i couldn't get anything to work on it...
I've had Lakka running on my Core(s) (specifically Lakka-WeTek_Core.arm-2.1.0.img.gz / Lakka-WeTek_Core.arm-2.3.1.img.gz).
Sorry for the late reply, but I was busy over the weekend.
My lockup is definitely related to the Ethernet port. It must not like either the multicast traffic it's receiving or possibly the LLDP it's receiving. It was connected to a Mikrotik CRS125 switch that is broadcasting LLDP on all ports and there is some multicast traffic on there as well.
I've experienced similar network anomalies before, as I have multiple MikroTik devices on my network, including the main router. Although I've only had issues with some IP cameras and DVRs, it wasn't easy to track down the source.
This MXQ has a SPDIF output to my Yamaha receiver to maintain digital connection. I just use one of those standard 1/8" to dual RCA cables and use the left (White) RCA cable for the SPDIF connection to my receiver.
I created a media converter for it so that I could use it with Toslink. 
(S/PDIF 3.5 mm Jack -> RCA -> Toslink)
I mean locate issue in ISA default konfig. My issue is in TV PVR switching channels and this use plugin managed streams over Input stream adaptive, seems default config have issue. Change to manual 1080 and now no crash.
Unfortunately, I can't really comment on that, since it's an add-on, and the last version released for Leia is already outdated.
I also suspect that this bug isn't specifically Amlogic specific, but has existed on all platforms. IDK.
Edit: I found a fairly similar bug on GitHub: https://github.com/xbmc/inputstream.adaptive/issues/1362
Hi,
thanks a lot for your fork! - It is really a big thing to keep my WeTekPlay1 running! - Unfortunately I just got it to work with your workaround via ssh and .tar Update File to upgrade from 9.0.2. With toothpick and with libreelec-writer no success via SD-card neither with USB-Stick...
Anyway... now I need a wireguard-connection and brought it to work. - Unfortunately when connmanctl starts the tunnel it takes it automaticly as default gateway. - I just need one explizit address in my other homenetwork. It is an openATV-Receiver. So the problem is that it forces all traffic to that endpoint.
It seems that there is a big bug somewhere in the wireguard implementation. I noticed that a complete network is getting a correct route, but it is also not possible to change the default route by hand after wireguard-tunnel is started.
wetekplay:~ # ip route del default
wetekplay:~ # ip route
default dev wg0 scope link
10.1.1.0/24 dev wg0 scope link src 10.1.1.12
192.168.183.0/24 dev wlan0 scope link src 192.168.183.101
192.168.183.1 dev wlan0 scope link
255.255.255.255 via 192.168.183.1 dev wlan0
wetekplay:~ # ip route add default via 192.168.183.1
ip: RTNETLINK answers: File exists
wetekplay:~ # ip route del default dev wg0 scope link
wetekplay:~ # ip route
default dev wg0 scope link
10.1.1.0/24 dev wg0 scope link src 10.1.1.12
192.168.183.0/24 dev wlan0 scope link src 192.168.183.101
192.168.183.1 dev wlan0 scope link
255.255.255.255 via 192.168.183.1 dev wlan0
wetekplay:~ # connmanctl disconnect vpn_conni_dns64_de
Disconnected vpn_conni_dns64_de
wetekplay:~ # ip route
default via 192.168.183.1 dev wlan0
192.168.183.0/24 dev wlan0 scope link src 192.168.183.101
192.168.183.1 dev wlan0 scope link
255.255.255.255 via 192.168.183.1 dev wlan0
wetekplay:~ # systemctl stop wireguard
wetekplay:~ # nano /storage/.config/wireguard/wg0.config
wetekplay:~ # connmanctl connect vpn_cxxx_dns64_de
Connected vpn_cxxx_dns64_de
wetekplay:~ # ip route
default dev wg0 scope link
10.1.1.0/24 dev wg0 scope link src 10.1.1.12
192.168.183.0/24 dev wlan0 scope link src 192.168.183.101
192.168.183.1 dev wlan0 scope link
255.255.255.255 via 192.168.183.1 dev wlan0
wetekplay:~ # wg
interface: wg0
public key: xxx=
private key: (hidden)
listening port: 61096
peer: xxx=
preshared key: (hidden)
endpoint: (ip-fits-tested):61006
allowed ips: 10.1.1.0/24
latest handshake: 14 seconds ago
transfer: 92 B received, 6.96 KiB sent
persistent keepalive: every 25 seconds
wetekplay:~ # ping 10.1.1.3
PING 10.1.1.3 (10.1.1.3): 56 data bytes
^C
--- 10.1.1.3 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
wetekplay:~ # ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 56 data bytes
ping: sendto: Required key not available
wetekplay:~ # connmanctl disconnect vpn_conni_dns64_de
Disconnected vpn_cxxx_dns64_de
wetekplay:~ # ping 10.1.1.3Here is the config of the WeTekPlay1
[provider_wireguard]
Type = WireGuard
Name = WireGuard VPN Tunnel
Host = cxxx.dns64.de
WireGuard.Address = 10.1.1.12/24
WireGuard.ListenPort = 61096
WireGuard.PrivateKey = xxx=
WireGuard.PublicKey = xxx=
WireGuard.PresharedKey = xxx=
WireGuard.DNS = 1.1.1.1, 9.9.9.9
WireGuard.AllowedIPs = 10.1.1.0/24
WireGuard.EndpointPort = 61006
WireGuard.PersistentKeepalive = 25
WireGuard.Table = offHere is the OpenATV-Side:
[Peer]
#Description = WeTekPlayIsa
PublicKey = xxx=
PresharedKey = xxx=
AllowedIPs = 10.1.1.12/32Keys fit, you can see it because sometimes there is a short connection for a few bytes in tx and rx direction when you check it wit "wg".
With my smartphones I can connect to my OpenATV Box. It is an SF8008 and Kernel 4.4.35.
Also a tunnel from a fritzbox7490 works to that device, but unfortunately not the wetekplay. - There is a problem with the gateway. I added the last line because I read it should force wireguard to not change default route:
WireGuard.Table = offBut it is the same behavior with or without the line. It always changes the default gw when wireguard tunnel is established.
Please doublecheck it or send me some advices. I used ChatGPT, Gemini and Ecosia AI. No real help and change...
Hey chewitt , thanks for the information. - Unfortunetly in my case it doesn't work. I use a wireless connection. And always if I do an
connmanctl move-after vpn_service_name wifi_service_nametwice my box hangs and my ip-connection is gone. If I do this once it doesn't commit the command. So as you also do in your link I do it twice.
Unfortunately I also edited my service as following and now I don't get any ssh-connection anymore
[Unit]
Description=WireGuard VPN Service
After=network-online.target nss-lookup.target wait-time-sync.service connman-vpn.service
Before=kodi.service
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStartPre=/usr/bin/sleep 5
ExecStart=/usr/bin/connmanctl connect vpn_service_name
ExecStartPost=/usr/bin/connmanctl move-after vpn_service_name wifi_service_name
ExecStartPost=/usr/bin/connmanctl move-after vpn_service_name wifi_service_name
ExecStartPost=/usr/sbin/route add -net 192.168.178.0 netmask 255.255.255.0 gw ip_of_wireguard_peer_ip
ExecStartPost=/usr/sbin/route add wireguard_local_interface_ip via 192.168.183.1 (local gw) dev eth0
ExecStop=/usr/bin/connmanctl disconnect vpn_service_name
[Install]
WantedBy=multi-user.targetOk... HDMI-CEC with Samsung Anynet+ is horrible. It just works in the beginning for around 1 Minute than it stops... No matter which preferences I use....
Is there somone using HDMI-CEC (TV remote control)? - Otherwise I thnik I need really to dump the device and buy an amazon fire tv stick 4k max or something...
I still don't know why after 10 years of development there are still this kind of issues... No working wireguard configuration and no HDMI-CEC-Conrol...
I can offer logs if you tell me how to get them
The box is running a downstream version of Linux 3.10 from 2013 full of hacky vendor code. There are many improvements to CEC support in Linux since then, but you are stuck with an ancient kernel because the vendor made zero effort to upstream support for their products. The codebase is basically untouched since release.
The same old kernel and surrounding userspace are probably the reason for poor WireGuard support too.
Hi chewitt
Do you see any chance to get this to work or can someone else help to find a working solution?
The standard thing to try with CEC issues is "turn off and disconnect everything, go have a cup of tea or wait a while, then reconnect and power it all back on again" .. but if that doesn't resolve the issue I wouldn't expect any development against that codebase.
Do you see any chance to get this to work or can someone else help to find a working solution?
In the leading post of this topic, I also indicated under the description of the device:
5. Amlogic Meson6 (AML8726-MX) SoC on Linux kernel v3.10.108 (LTS):
- WeTek_Play | WeTek Play (a.k.a. WP1) with AML8726-MX SoC (1 GB RAM, 4 GB NAND) and a modular removable tuner:
Working services: Power status LED, CPU temperature sensor, Analog+S/PDIF+HDMI audio output, 10/100 Mbps Ethernet, Wireless (2.4 GHz), Bluetooth, RF+IR combo remote control (HID+amremote), HDMI-CEC*, NAND boot**....
* On some TVs, this can cause instability, but in this case it is worth turning it off:
Settings -> System -> Input -> Peripherals -> CEC Adapter
Unfortunately, many features of the WeTek Play (and Meson6-based boxes in general) are far more unstable/unusable than even an S805/S8X2, even though they are based on the same kernel. These include the CEC service, but has also some audio and network based issues, including Bluetooth-related that are either unstable or can cause the box to freeze for no reason, which can only be helped by unplugging/replugging the power adapter.
Therefore, it can only be recommended for basic tasks. For example, WP1 may still be suitable for a headless tvheadend server.
Thanks chewitt and a big THANK YOU dtech for your hard work! - I really know and appreciate it and it is not always embracing to just get all of the bugs and things which are not great. There are a lot of great things you did!
So maybe we can find some settings to find "workarounds" and I am curios how you use the device nowadays? There is easily a problem if you need to remote controls with your wife... That is just the simple reason why HDMI-CEC is so necesseary...
Just if the wireguard would somehow work, did someone test this with wifi? All the reports here were with LAN-Connection as far I understood. And will it be fast enough to get a ~20 Mbit/s stream like "Das Erste HD" or similar high-bitrate Channels through the wireguard tunnel and decoding properly?
My workaround is now using my 7490, but if there is streaming the whole network performance goes down and I can't use a third device for just 1 service in the end... the power consumtion in total is nowadays also big point... And beside this the routing complexities...
Amlogic's 3.10 codebase is full of very old, very ugly, and very fragile code. The moment you start "fixing" things you cause breakage in other areas. It doesn't matter how many times you hint, ask, beg, or plead. No developer with any common sense is going to start a quest looking for CEC issues because however well meaning the attempt, you quickly end up in some rat-hole and burn hundreds of man-hours, and people prefer doing fun things with their donated free time, not that. TL/DR: if CEC works for you that's great, and if it doesn't work for you, sadly it just doesn't. IMHO Kodi life is always easier when you avoid CEC.
WireGuard doesn't care whether the underlying transport is WiFi or Ethernet. In theory they work the same. In practice WiFi is never as reliable as Ethernet .. because radio isn't as reliable as a physical connection. You also need to factor in ye olde vendor codebase with old drivers. Whether your unique WiFi environment is fast enough for your needs; nobody knows 
Unfortunately, I can't really comment on that, since it's an add-on, and the last version released for Leia is already outdated.
I also suspect that this bug isn't specifically Amlogic specific, but has existed on all platforms. IDK.
Edit: I found a fairly similar bug on GitHub: https://github.com/xbmc/inputstream.adaptive/issues/1362
As you say , this is in base kodi error and i ask for solution your or myself. LTS i mean is as is, then try help with solve this annoy issue with TV channel switching hang your build KODI compete but ssh still works.
LibreELEC:~ # tail .kodi/temp/kodi.log
2025-07-26 10:44:05.892 T:4093816896 NOTICE: CVideoPlayer::CloseFile()
2025-07-26 10:44:05.892 T:4093816896 NOTICE: VideoPlayer: waiting for threads to exit
2025-07-26 10:44:05.896 T:3402756864 NOTICE: CVideoPlayer::OnExit()
2025-07-26 10:44:05.896 T:3402756864 NOTICE: Closing stream player 1
2025-07-26 10:44:05.896 T:3402756864 NOTICE: Waiting for audio thread to exit
2025-07-26 10:44:05.906 T:3344007936 NOTICE: thread end: CVideoPlayerAudio::OnExit()
2025-07-26 10:44:05.906 T:3402756864 NOTICE: Closing audio device
2025-07-26 10:44:05.908 T:3402756864 NOTICE: Deleting audio codec
2025-07-26 10:44:05.909 T:3402756864 NOTICE: Closing stream player 2
2025-07-26 10:44:05.909 T:3402756864 NOTICE: waiting for video thread to exit
no crash then no crashlog now. When you coant correct then give me command to safe restore from this state over ssh.
systemctl restart kodi work , but display TV stay hang seems aml driver lockup
reboot not work
systemctl stop kodi no error , but kodi process still run
13495 root 0:00 [kworker/1:2]
13499 root 0:02 [kworker/3:0]
13504 root 0:00 [kworker/3:3]
13516 root 0:00 /usr/lib/kodi/kodi.bin --standalone -fs
13517 root 0:00 [kworker/2:0]
13533 root 0:00 ps xa
kill 13516 nothing
Then what?
As you say , this is in base kodi error and i ask for solution your or myself. LTS i mean is as is, then try help with solve this annoy issue with TV channel switching hang your build KODI compete but ssh still works.
The long-term support is for the system itself, not for Kodi. Unfortunately, Kodi developers don't provide short-term support either, so when a new version is released, there's usually no update for the old version, regardless of whether it runs on certain platforms or not.
If this bug is really the same as the one I linked earlier, then it should be backported, but the fix only arrived for versions 20 and 21. Since there were quite radical changes from 18 to 19 (dropping legacy amlogic support, replacing python2 with python3, etc.), so I wouldn't say that backporting to 18 is impossible, but it would certainly be a very looooong task.
Unfortunately, I don't have enough time to try to patch this at the moment, moreover I can't test it, because I don't have any television broadcasting source that uses ISA.
I will probably end LTS support with the release of the first stable version of Kodi Piers (v22).
