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.