My remote is without mouse as well. So that is not the point.
You can use ir-keytable (available on CoreElec) to see what keys are picked up by the BeeLink GT King and what code is generated. Lots of info on ir-keytable available on the internet.
I do not know with what action you can replace the power action in the remote.conf file.to show the power menu. Changing this action could also break the power on part of the power action.
Recently, using the GT King as an alternative digital VCR, there were to my surprise moments that I was able to transfer files from my PC to the GT King with speeds of over 100 MBytes/sec. Furthermore I was able to record TV programs from all the 6 network tuners simultaneously without any so called “continuity counter” errors. I was running Amlogic-ng Generic nightly 20190818 at the time. As I had not done anything special to get these ethernet speed results, I was convinced that the CoreElec Team had somehow solved the ethernet problems of the GT King.
Unfortunately, after updating to Nightly 20190820, the ethernet party was over again. Maximum ethernet speeds drop back to 67 MBytes/sec and I got lots of “continuity counter” errors from TvHeadEnd42, even during single tuner recordings. Although the maximum speed of 67 MB/s is better than the 20 / 40 MB/sec it used to be, it was a disappointment, especially the TvHeadEnd errors. By the way, 67 MB/sec should be more than enough for single tuner TvHeadEnd recordings (10 MBytes/sec per tuner maximum needed at the moment). So it is not speed alone what causes the current ethernet problems of the GT King.
That I was able to get ethernet speeds of 100+ Mbytes/sec, suggests to me that it is not very likely that the GT King’s hardware is the cause of the ethernet problems. Remembering the iperf3 trick I used to bump the ethernet speed to 40 MBytes/sec a couple of weeks ago, I tried this trick again. And yes, it worked again, be it that this time this trick, after a reboot of the GT King, bumped the speed all the way up to 100+ MBytes/sec.
Somehow iperf3 changes the ethernet settings in such a way that after rebooting the ethernet performance is what it should have been out of the box. These altered settings survive reboots and power off-on cycles. Why the initial reboot is needed after running iperf3 before these iperf3 settings are actually applied, is beyond me.
I hope this information will help Team CoreElec to once and fore all solve the ethernet problems of the GT King. Let me know if I can be of help or if more info is needed.
I’m pretty sure that most of the problematic GTK has a hardware error, like the wrong resistor value soldered to the RX line. Maybe yours is an exception, but you never know with these Beelink boxes…
Just today I read about two GTKs arrived yesterday with non working gbit LAN.
This is now a well documented problem with this device, the Khadas VIM3 uses the exact same RTL8211FD ethernet transceiver with the exact same driver and the exact same kernel and the exact same settings and does not exhibit the same issues, some GT-King devices run perfectly fine at full speed whilst others do not.
It’s just like Adam says. As I’ve said in multiple occasions I was lucky and I don’t have ethernet problems. Others simply can’t use ethernet. And we tested both CoreELEC and android and it worked in similar fashion in both.
Could explain me how to update a nightly built CoreElec.
I first installed CoreELEC-Amlogic-ng.arm-9.1-nightly_20190902-Generic.img.gz
and this night I can see a new version from 20190903
this information is not in update page because it is only for stable versions.
So it should be interesting to write this procedure somewhere.
Also have some problem with audio. I understand, that passthrough isn’t working yet. But with passthrough disabled I can get undistorted audio only on 2-channels config. Every other setting (like 5.1) - produces very distorted (slowed down) sound. The box is connected to AVR via HDMI cable and “ALSA:AML-AUGESOUND, HDMI” is selected. The AVR detects only 2 PCM channels.