Have you experimented with the HDMI ports the device is connected to on the TV? .. On modern TVs they are not all equal.
Posts by chewitt
-
-
I see transfers around ~112MB/s from an RPi5 with nvme storage.
I see transfers around ~33MB/s on an elderly Amlogic S905 box with emmc storage.
I see transfers around ~12MB/s on another Amlogic board booted from USB storage.
All three have gigabit NICs, but all three internally wire them up differently and storage media can have a large impact too.
-
The bluez.conf file is intentionally empty. If you want to start bluez with either BLUEZ_ARGS or BLUEZ_DEBUG variables defined; the variables go in that file. If the bluez.conf file is missing the bluez service doesn't start (as per the systemd service config). The sole purpose of it being created is to enable the service starting (same as for sshd, avahi, samba, etc.)
No idea what the issue with the soundbar is, but for the sake of creating a half-meaningful comparison; install RaspiOS on a spare SD card and see if that works. If it also fails at least things are consistent and that probably hints at something odd with how the soundbar responds to bluez. If it succeeds, it probably hints at software versions of bluez since I'd guess that LE is using a newer version than a general purpose distro. I might be wrong on that but it's often the case.
-
ilovebytes Just to confirm .. if you connect only GND, the device boots?
-
-
Perhaps update to dtech images to bump to LE 9.2.8 and then see if Docker will install .. it's years since I ran 9.2.8 so I forget what's possible there. If Docker runs, it's a route to running a newer Tvheadend version (there is an official container these days).
-
-
Has the internal disk been wiped? - the install target needs to be formatted with a filesystem (of any kind) to show up in the list.
-
Read: https://wiki.libreelec.tv/hardware/amlogic/
The droidbox specs say it has Gigabit Ethernet so I'd experiment with the p201 dtb file (not p200) or you simply need to work the list of available "gxbb" files and see what works best (or least worst). The IR remote can be mapped easily - there's an article for that in the wiki too.
NB: If you have £100 to spend an RPi5 board is currently the best supported LE hardware and the recently released 2GB version has a nicer price point than the 4GB/8GB models. There are lots of things available with fancier specs, but average hardware with A1+ software support gets you further than A1+ hardware with average software (and RPi5 isn't exactly average hardware..).
-
I pulled the images from the share because they were becoming dated and at the moment I don't have time or enthusiam to rebase the changes and test newer kernels. If you're desperate the wiki has self-build instructions and the "amlogic" branch in my GitHub repo has the last-built state.
-
You can use "ethtool" to read and set/force configurations on NICs, but if the connection is not auto-detecting 1Gb speeds correctly the root problem is more likely to be hardware related (cables, ports, etc.) than software. In my professional experience, forcing NIC speeds is rarely the solution and often causes more issues than it solves.
-
Users have been asking us about RK3568 and RK3588 support since boards launched (3-years ago now) and there is some work in progress here: https://github.com/LibreELEC/LibreELEC.tv/pull/7864
However HDMI output support has only recently arrived and media codec drivers are still in the early stages of being written, and until those are done there's not a huge amount of point in us releasing images; hence the slow pace of progress.
-
Ohh.. that's ancient (2006 ish) and the worst era for EFI boot support over USB in Apple firmware. I had a similar era/vintage mini some time ago and it was a complete pig to get Linux installed onto. USB boot was so flakey that I have fuzzy recall of needing to remove the drive and install Linux from a more modern system, then reinstall the drive, then faff about with rEFInd.
NB: Appreciate you have this device in-front of you, but a cheap RPi3B+ board will give a better overall playback experience.
-
You cannot use device-tree files for vendor kernel images on AMLGX which uses an upstream kernel. They are very different.
Start with an LE13 nightly, use an older/smaller SD card if needed. Once booted you can install the image direct to internal eMMC.
-
The settings moved to the GUI so advancedsettings.xml isn't required.
Also note that unless your network is broken, changes to the caching defaults are not (or are only rarely) required. If your network is broken enough to need more than 1GB of cache to support playback, the correct solution is fixing the network, not forcing Kodi to use some ridiculous cache value that will add more problems than it solves.
-
The log and screenshots show that you forced the desktop to 4K@30 and there is a single whitelist entry for 4K@30 .. which means you're attempting to force all media to play at 4K@30 resolution with Kodi upscaling everything itself. It's a recent i7 CPU with 16x cores so it has some grunt, but media apps aren't as multi-threaded as you might assume, so regardless of the specs that might not work, and processing e.g. [email protected] media (most movies) to 4K@30 requires a lot of compute. The log doesn't show any playback, so hard to comment on what goes wrong, but..
I'd recommend setting the desktop to 1080p and then whitelisting 4K@30/29.97/25/24/23.976 and 1080@60/59.94/50/24/23.976 and allowing mode doubling (hence 1080@25/29.97 are not required). That should allow Kodi to switch 1080/4K to native resolutions as needed, and the only stuff that won't be handled is 4K@60/59.94/50 which requires HDMI 2.0a capabilities in the AVR/Projector.
All suggestions long documented in here: https://wiki.libreelec.tv/configuration/4k-hdr
-
mglae Could ConnMan be patched to log failed attempts too? .. might be useful?
-
If running on an x86_64 or 32-bit ARM SoC device the Docker binaries are going to update once the new addon repo is accessible and this might throw up some minor config issues related to dockerfiles; sometimes Docker conventions change and there's probably a large enough jump from whatever (older) version is used with LE 9.2.6 for that to occur.
If running on a 64-bit ARM SoC device, LE12 changed images from "arm" (32-bit) userspace to "aarch64" (64-bit) and this forces you to remove all "arm" containers before updating and redeploy them using "arm64" versions once the update has completed. If you leave arm containers installed they will crash post-update due to wrong CPU arch.