My report on the testing of the new BT selection feature.
I dropped in the unmodified dtb.img file.
And removed the other custom commands to ensure only USB BT is available.
Installed today’s release of nightly build. Went to the services option in the CoreELEC menu, in the Default adapter I had 3 options 1 with no name, 2 with UART and MAC address, 3 USB MAC address.
Selected the third option, popup advised I needed to reboot. I did this, after reboot, I needed to put the UR02 into learning mode to re-connect the remote to the USB Bluetooth, trust and connect. UR2 works well, after additional reboots it continues to work.
However my Harmony Hub, which I had working very well, with my AI guided hack.
Programmed the hub back to the system, the connection is present and displays with gold star, lock and yes, It works great until a reboot. After reboot looking at Bluetooth the connection is present with a lock symbol. Press any hub button and a large Bluetooth overlay with a yes no message for accepting pairing, Selected yes, connect changes to yes, but press button connect is dropped again with 2 consecutive yes no overlays to pair and connect. Functionality is restored and kept after 3 Yes for pairing, untill the next reboot. Then pairing 3 times to restore functionality for the harmony hub.
I really like the new option, I think you have done a great job to get it to this point already.
I don’t understand why the service crash on boot :
Apr 22 08:04:01 CoreELEC systemd\[1\]: Starting tmate.service...
Apr 22 08:04:01 CoreELEC tmate-pre.sh\[676\]: % Total % Received % Xferd Average Speed Time Time Time Current
Apr 22 08:04:01 CoreELEC tmate-pre.sh\[676\]: Dload Upload Total Spent Left Speed
Apr 22 08:04:01 CoreELEC tmate-pre.sh\[676\]: \[124B blob data\]
Apr 22 08:04:01 CoreELEC systemd\[1\]: Started tmate.service.
Apr 22 08:04:01 CoreELEC sh\[690\]: To connect to the session locally, run: tmate -S /var/run/tmate.sock attach
Apr 22 08:04:01 CoreELEC sh\[690\]: Using /var/run/tmate_id_ed25519_ce.pub for access control
Apr 22 08:04:01 CoreELEC sh\[690\]: /var/run/tmate_id_ed25519_ce.pub: No such file or directory
Apr 22 08:04:01 CoreELEC systemd\[1\]: tmate.service: Main process exited, code=exited, status=1/FAILURE
Apr 22 08:04:01 CoreELEC systemd\[1\]: tmate.service: Failed with result 'exit-code'.
Manually, second time, it’s OK… tmate is online now.
Not sure if my issue goes to this topic. I’ve got Ugoos X5M Pro. Successfully install 22.0-Piers_alpha3 but have strange issue with remote which is UR02. It can be paired over BT and works until reboot.
I would like to point out that remote is able to wake up device so IR looks normal. But after power up BT connections section lists UR02 as not connected and when I try to connect Kodi hangs out for a little and then reply Bluetooth error “did not receive reply“. The only solution that works is delete and re-pair remote once again.
Same thing happens to occur if I just pair remote and left it unattended for a while.
I tried this remote with X4Q Pro on CoreElec 21.3-ng and remote works after reboot and BT connections section lists UR02 as connected so my guess there is something specific to X5M.
Would be glad to provide any additional information to debug the issue.
I gathered kernel logs with debug logs enabled for bluetooth. This unexpected event for opcode log I think is not really relevant. More important is this:
/* Set Default PHY parameters if command is supported */
if (hdev->commands[35] & 0x20) {
struct hci_cp_le_set_default_phy cp;
cp.all_phys = 0x00;
cp.tx_phys = hdev->le_tx_def_phys;
cp.rx_phys = hdev->le_rx_def_phys;
hci_req_add(req, HCI_OP_LE_SET_DEFAULT_PHY, sizeof(cp), &cp);
}
in kernel net/bluetooth/hci_core.c fix the adapter DOWN state.
So it seems like the mt7668 report it support HCI_OP_LE_SET_DEFAULT_PHY but does not.
I will do some more tests to see if this fix does not brake other things.