Thank you. It is 12 years since I last did that and I had completely forgotten how to do it. I will try tomorrow morning.
Check the underside of your New Ugoos, Abd compare with the Old Ugoos.
Should be 2 button
Maskrom
Recovery
Use Recovery only….Dont touch Maskrom
Both are the same, but thanks anyway. I had to use the Recovery switch to repair the old AM6.
Everything running fine now, apart from anything Google related. I am sorry I was such a pain. That can be put down to my being 70 with only intermediate PC skills, the defective OTG cable that prevented me from getting the burning tool to do its job, and not having had to make any changes to CE since 2015.
A heartful THANK YOU to EVERYONE that came to my aid!
One last question, if I may.
I have set CE to auto-update when a new stable release is found. Is this now a seamless OTA operation, or will I need to use the Recovery/Power method?
Hi everyone,
I’m looking for a way to automate audio output switching in CoreELEC (CE21) based on device connection.
Currently, both of my audio setups work perfectly when configured manually:
-
Soundbar: HDMI output with Passthrough enabled (Dolby TrueHD, DTS-HD MA, DTS:X, etc.).
-
Headphones: USB Bluetooth Transmitter (
ALSA: UGREEN-15765A, Analog) with Passthrough disabled.
Since toggling Passthrough and changing the audio output device manually every time I put on or take off my headphones is quite tedious, I’d like to automate this process.
Is there a recommended add-on, script, or event handler (e.g. via autostart.sh, udev rules, or Kodi callback scripts) that can detect when the USB Bluetooth device connects/activates and automatically swap audio profiles (or switch the sink and toggle passthrough)?
Has anyone achieved a seamless “plug-and-play” or connection-triggered audio switching setup for this? Any examples or guides would be greatly appreciated!
Thanks!
CE-22 automatic switch to BT when connection is established. And it switch back to previous device when BT connection is lost.
Headphones aren’t passthrough compatible anyway.
Thanks for the quick reply!
The issue is that simply switching the audio sink automatically isn’t enough in this case. When the output switches to the USB BT adapter, Passthrough remains enabled in the background settings.
Since headphones cannot decode raw bitstream formats (Dolby TrueHD, DTS-HD MA, DTS:X, etc.), playing a file with passthrough turned on results in either silence unless Passthrough is explicitly toggled OFF. When switching back to HDMI, Passthrough needs to be toggled back ON.
Is there a way (via script, udev rule, or Kodi callback/JSON-RPC) to link the Passthrough toggle directly to the automatic BT connection event, so that:
USB BT connected: Switch output to USB AND set audiooutput.passthrough to false
USB BT disconnected: Switch output back to HDMI AND set audiooutput.passthrough to true
Has anyone configured a script or callback to handle both the device switch and the passthrough toggle simultaneously?
Did you even tried with CE-22? Or still using EOL CE-21?
I just used this setup a week ago, works without any issues. Passthrough on HDMI on all formats, when BT connect pop-up comes up and I hear only headphones. Nothing Todo, just update to CE-22 and it works.
I’m running CE22 (latest). My setup is: Ugoos AM6B+ -> Samsung HW-Q990F Soundbar (HDMI) -> LG C5 (eARC)
The key difference in my case is that I am not using the internal Bluetooth chip. Instead, I’m using an external USB BT transmitter (UGREEN-15765A), which acts as an USB audio sound card (UAC/ALSA device). I use this specifically because the built-in BT doesn’t support the aptX Adaptive codec.
Because it’s an external USB audio device rather than the native CE Bluetooth subsystem, the automatic BT switching routine doesn’t manage it properly:
-
As long as Passthrough is set to ON, CoreELEC keeps sending the bitstream via HDMI to the soundbar, ignoring the USB dongle connection.
-
The USB transmitter only receives audio if Passthrough is explicitly toggled OFF (and output changed to ALSA: UGREEN PCM/Analog).
-
Once I disconnect the headphones, I have to manually flip Passthrough back to ON to restore TrueHD/DTS-HD bitstreaming to the Q990F.
I think my ISP has started blocking tmdb. For the past week, I’ve been getting tmdb connection error (errno 104) almost every time kodi tries to scan content. Most scans just fail with the same error and only about 1-2 out of 10 scans actually complete successfully. At this point, using a vpn seems like my only option, but I’m not sure how to set one up on ce-no. If anyone can walk me through the setup, I’d really appreciate the help.
Edit: Managed to set up wireguard. All good now.
There’s a good guide here if you search vpn or wireguard for coreelec. Alternatively you can use chatgpt or any free Ai tool(included in most phone browsers) & it will guide you. Good luck.
Just to update the thread: I ended up solving this perfectly using the Audio Profiles add-on and mapping a shortcut directly to my remote control.
Now, with a single button press, it automatically switches the audio output device to the USB BT dongle AND turns off Passthrough (or switches back to HDMI with Passthrough ON for the soundbar). It works like a charm!
Thanks again for the help!
I ran into an interesting issue regarding SD card backups and fstrim behavior on the latest CoreELEC 22 Nightly.
System Specs:
- Device: Ugoos AM6B+
- OS: CoreELEC 22.0 Nightly (Latest build)
- Storage: SD Card (/storage partition mounted on /dev/mmcblk1p2)
The Issue:
I perform full raw disk backups using dd piped into zstd -15 from my PC by inserting the SD card into a reader.
Normally, my backup size is around 400 MB - 500 MB compressed (since /storage used space is only ~240 MB). However, recently my backup size suddenly jumped to 1.7 GB, despite no major additions to the device.
I enabled fstrim.timer on CoreELEC and ran systemctl start fstrim.service. The logs confirmed that fstrim successfully trimmed unused space:
fstrim[1639]: /storage: 55.9 GiB (60055584768 bytes) trimmed on /dev/mmcblk1p2
However, after performing a dd read again, the compressed file size remained huge (~1.5 GB), meaning dd is still reading dirty/non-zero block data from the trimmed space that zstd cannot compress.
The issue was only resolved after manually writing zero-bytes directly to the filesystem on CE:
dd if=/dev/zero of=/storage/zero.fill bs=4M; rm /storage/zero.fill
After doing this zero-fill, the dd + zstd backup dropped right back to ~450 MB.
Question:
Why does fstrim report successful trims on the SD controller under CE22, while the underlying flash blocks still return original dirty data during raw sector reads (dd) instead of deterministically returning zeroes (RZAT/DRAT)? Is this a controller/driver limitation with mmcblk discard support, or expected behavior for SD cards under Linux?
Thanks for any insights!
Update / Additional note: Every time I reboot the device, fstrim -a -v reports the full 55.9 GiB trimmed again on the first run, and 0 B on the second run. After another reboot, it goes back to reporting 55.9 GiB again. This confirms the kernel is issuing discard calls to the mmcblk driver on every boot cycle, but the SD card controller is either silently dropping the discard command or simply not zeroing the underlying flash blocks (non-deterministic read after trim).
fstrim tells the device “these blocks are no longer needed” but does not guarantee a secure overwrite with zero byte data
recommend switching from raw dd to partclone, IIRC it inherently skips non allocated blocks then you don’t have to have the excess wear on your SD