No. Docker virtualises the app not the environment it runs in. So the container provides ann app which still requires a windowing environment to run under, and this still does not exist.
There is a browser called Ozone which can in theory run under GBM, but this needs to be built from sources and has a ton of dependencies so nobody has ever volunteered for the huge effort of trying to implement it for LE.
Posts by chewitt
-
-
Just force-refresh the repo.
-
Please update to this image https://chewitt.libreelec.tv/testing/LibreE…-12.90.1.img.gz and the adapter should work now? If yes I will send the required kernel patch upstream.
NB: the image is LE13 but this should be stable for normal use.
-
It looks like the device ID's are not recognised by the kernel and a patch is required.
Please run cat /sys/kernel/debug/usb/devices | paste and share the URL
-
I was pretty sure pi5 allows for multiscreens.
RPiOS can create a single 'desktop' over mutiple displays but then Kodi runs in a window on the desktop and you have to choose which desktop you want full-screen output on (as Kodi does not handle multiple screens) and you cannot 'adjust-refresh' display mode to suit the media being played (as Wayland does not allow this).
The closest you can get is stopping Kodi, editing config files with scripts to change outputs, then restarting Kodi. There is no way arouond the stop and restart because Kodi does not support dynamic change of video output.
I would describe the scripting approach as fragile. Feel free to experiment, but don't be surprised when it isn't reliable.
-
Kodi supports outputting at 1080p and switching to 4K only when required, but it cannot handle dynamic changes of HDMI output and it has no concept of fallback logic for HDMI connections. IMHO the best solution will be to send everything to the AVR and use the video/audio source mapping functions there to deliver the output routing you want.
In short, LE will not do what you require, and as the Kodi featureset is pretty consistent on all platforms I don't think any other distro or OS platform will do it either.
-
I've updated the RK356X images (and .tar) in my test share to pick the CEC fixes and include a 'getedid' script. Please test without using getedid and if the issue is solved I will add the patches to the list of things that I can nag Kwiboo about

Not sure about the video stutters, although if that's only in the lastest image (last 24h) it's possibly due to an ffmpeg bump; it would help to see a Kodi debug log to understand config/environment and media. I will dig up a Rock 3C board and experiment in the next couple of days.
Also no idea on Kodi profiles. The patch you flagged was dropped with the Python 3.9.10 bump aeons back, so if there's an issue it's presumably a new bug as that fix is upstream. You'll need to share a Kodi debug/crashlog for someone to look at.
-
The listing of the device in "lsusb" only proves the USB bluetooth receiver is connected, not that it works or is working.
To eliminate the LE settings add-on from the process (not known to have issues, but not impossible) you can use "bluetoothctl" to scan for devices and pair them from the console. See how that goes.
-
The latest images in https://chewitt.libreelec.tv/testing/ are updated to pick the mediatek firmware(s) and should work
-
As I can read here in the wiki, audio has to work. As the device is currently connected to a standard monitor without speakers, I wonder if this may contribute to all the issues?
Kodi appears to read some HDMI audio capabilities from the DRM driver layer, but the EDID data from the monitor presumably shows no speakers so Kodi ends up running in circles trying and failing to open an audio sink. This eventually fails but only after generating a ton of log noise. It will be more productive (and less log-noisy) to run tests with the TV. You must also run "getedid delete" as the previous inappropriate advice to run it will force the kernel to always see the monitor (with no speakers) attached instead of the TV .. thus guaranteeing bad results.
-
Code
2025-11-23 12:12:46.454 T:900 error <general>: SMBFile->Open: Unable to open file : 'smb://192.168.178.13/VIDEO/SPIELFILME/JAMES%20BOND/James%20Bond%20007%20-%20In%20t%c3%b6dlicher%20Mission%20(1981).mkv' unix_err:'16' error : 'Invalid argument' 2025-11-23 12:12:46.454 T:900 error <general>: CFileCache::Open - <smb://192.168.178.13/VIDEO/SPIELFILME/JAMES BOND/James Bond 007 - In tödlicher Mission (1981).mkv> failed to open 2025-11-23 12:12:46.454 T:900 error <general>: InputStream: Error opening, smb://192.168.178.13/VIDEO/SPIELFILME/JAMES BOND/James Bond 007 - In tödlicher Mission (1981).mkvThe first error looks like Kodi is configured to use the default HDMI device (#0) when the active/connected HDMI device is #2 so the alsa audio sink cannot be opened.
The second error is related to SMB (invalid argument) so check that you are using a valid IP/path and credentials in sources.xml and the SMB protocol versions used by the Kodi SMB client are correct for the NAS.
-
Chrome (not Chromium) still requires Xorg which is Generic-Legacy. There is no equivalent under the non-Legacy image.
-
Any suggestions are highly appreciated!
Put Kodi into debug mode, reboot, replicate the problem, then share the log via "pastekodi" else we are guessing (none of the info shared thus far is particularly enlightening).
-
Avahi (ZeroConf) advertises multiple services do the network browser app on Ubuntu etc. will show everything advertised. I'd guess that lowercase is SSH and uppercase is Samba (SMB). The Samba config in LE is oriented towards Windows and IIRC requires auth (libreelec/libreelec, not root/libreelec) so as long as you're using the right credential access should work. If the LE/RPi device is using DHCP it might help to add a static DHCP assigment in the router so the dynamic IP address never actually changes and thus DNS resolution of libreelec.local should also never change (avoids stale mDNS caching issues). Otherwise you need to look at Samba client logs on PopOS (or make connections manually from the console so you see stdout errors) to see why client access has failed.
NB: The perennial issue with RPi hardware and WiFi is that the antenna isn't brilliant and this affects the underlying connection and can introduce misc. errors. If running an Ethernet cable eliminates the issue, WiFi itself is the problem.
-
Code
mkdir -p /storage/.config/firmware/mediatek cd /storage/.config/firmware/mediatek wget https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/mediatek/mt7601u.bin rebootIt's nothing more than missing firwmare so do the above ^ (watch for the line wrap on the wget command) and it should work?
Confirm back and I'll pick the firmware to future images.
-
Code
Display More# zidoo v12 remote evdev:input:b0005v5A44p5A44* KEYBOARD_KEY_c0041=enter #OK KEYBOARD_KEY_7003a=l #sub KEYBOARD_KEY_c01bd=i #info KEYBOARD_KEY_7009a=o #tv out KEYBOARD_KEY_c00bc=repeat KEYBOARD_KEY_c006d=c #zoom KEYBOARD_KEY_70045=m #square key with lines KEYBOARD_KEY_c01b7=leftquote #audio KEYBOARD_KEY_c00e2=volume_mute #mute KEYBOARD_KEY_c00e9=period #vol-up KEYBOARD_KEY_c00ea=comma #vol-down KEYBOARD_KEY_70027=zero #0 KEYBOARD_KEY_7001e=one #1 KEYBOARD_KEY_7001f=two #2 KEYBOARD_KEY_70020=three #3 KEYBOARD_KEY_70021=four #4 KEYBOARD_KEY_70022=five #5 KEYBOARD_KEY_70023=six #6 KEYBOARD_KEY_70024=seven #7 KEYBOARD_KEY_70025=eight #8 KEYBOARD_KEY_70026=nine #9 KEYBOARD_KEY_7002a=backspace #backspace KEYBOARD_KEY_700b7=power #tv out greenSee if that content works?
-
1. Not unless someone upstreams support for the box to the upstream kernel and u-boot
2. There are nightlies for some RK3576 devices and equivalent test images with marginally newer kernel etc. in my test share
3. LE supports whatever level of 'properly' the current upstream kernel supports
4. If you want things to work 'properly' it will probably need device-specific dts/u-boot. Nothing exists for that device.
In short; there is code and prior-art in our buildsystem and we publish that under GPLv2 so anyone can go nuts and experiment and do whatever they like with it. There are no nicely typed up technical notes or HOWTO guides. You are welcome to ask questsions, but you should have low expectations for anyone spoon-feeding you with instructions on how to author support for your box.
-
None, and it's not likely to be nearing the top of my to-do list anytime soon due to other priorities.