Remove all the config.txt changes (or create a new/clean SD card) and connect the HDMI cable to a different HDMI port on the TV and see if that works. I'd guess no, in which case you need to replace the Type-C to Type-A adapters with a proper Type-C to Type-A cable (no adapters). Adapters are often designed for use with desktop monitors which have no speakers, and thus the HDMI chips used inside them can omit wiring or support for audio to create a cheaper product. I can't 100% guarantee that's the issue, but from experience it's more likely to be something physical like that than anything in software.
Posts by chewitt
-
-
S905X and S905W are ARMv8 chips but it's common to see 64-bit kernel and 32-bit userspace on Android devices. The older LE11 (arm) image uses the same combo. LE12 and newer now run 64-bit kernel and 64-bit userspace (aarch64). The userspace change is not the reason why the older image boots and the newer one doesn't; it will be something lower level, and the only real way to understand what is or is-not happening is to see the initial u-boot and kernel boot stages via the serial UART log. That requires you to have a USB UART adapter and the UART pins to be physically on the board to connect to - the pads will be there, but cheap boxes often need the pins soldering and they were omitted to reduce manufacturing cost.
Use an official LE13 nightly or image from my test share https://chewitt.libreelec.tv/testing/ as that's the active codebase for dev work. The S905X board should boot with the p212 dtb file in the "box" image. The S905W board should boot with the p281 or Tanix TX3 mini dtb files.
-
There are MXQ boxes from Amlogic, Allwinner, and Rockchip and that photo doesn't enlighten us (although the 45 degree rotation on the chip makes Amlogic unlikely). So before we go any further, we'd need to understand the specific chip on the board, and ideally see a boot log from the original vendor OS full of driver information.
-
So i would like to ask if the support of output to both hdmi is supported out of the box or not?
RPi4/5 hardware supports use of both HDMI outputs on a conventional distro that uses X11 or Wayland. In that scenario Kodi runs as a full-screen app and you can select the single display to use, but Kodi does not support dual-output (mirrored output) and AFAIK this is true for all OS, not just Linux. In LE, Kodi runs 'on the framebuffer' with no window manager so we only support output to a single display device. TL/DR: Not possible, you need to use an external splitter.
-
Fix is merged .. the add-on should update in the next 24h
-
The majority of reports are from RPi boards but that simply reflects the demographics of a project where 80% of all users have an RPi board. The issue is probably about radio/wireless features in the network and appears to be influenced by signal strength.
It's been flagged to upstream maintainers who are keen to help resolve the issue. Debug logs from ConnMan and IWD and 'iwmon' output when the issue occurs would be useful.
-
Newer chips as S922x dont have HW acceleration with panfrost.
On ARM boards hardware video acceleration has nothing to do with the GPU, and the difference between OpenGLES 3.1 and 3.2 is frankly not important for LE/Kodi use. There is simply no good reason for LE to use a proprietary closed-source blob that requires maintenance effort over an open-source in-kernel option that requires zero effort. Abandoning libmali once lima/panfrost were viable was a no-brainer (and smart) move for the project, hence we've done it. You're welcome to disagree of course (free world and all that) but your view is firmly in the minority around here.
-
Thanks. The log omits most of the early boot, but there's an ID clue about the Ethernet device and that allowed me to dredge up some older threads in the LE/CE forums. It seems to have a problem ZTE chip and I'm not sure support for this has ever been fully resolved, but it gives me some ideas to test. I'm away for a few days but will have a look a custom device-tree later next week.
Code0.520527@2] eth0: PHY ID 03815c11 at 1 IRQ POLL (stmmac-0:01) active^ that's the important bit
-
Stop Kodi on the target device and then copy the sources.xml/passwords.xml files over from /storage/.kodi/userdata and DB files from /storage/.kodi/userdata/Databases and then restart Kodi on the target. Kodi will detect the DB files and migrate the content into new DB files versioned for the current release. Export/Import is .. something I've never used.
-
I found a patch for the Xtreamer Ultra2 audio problem. I've run into some minor issues that I suspect are simply down to nouveau not being great great quality. It chokes on Tvheadend streams that are H264/1080p and VDPAU decoded, and I've had a couple of crashes that aren't explained (or seen on other devices). Anyway.. time for some downtime.
-
Why was not updated driver from r16 (r23) to r51 for mali ?
Panfrost made mali-bifrost irrelevant for LE images. The upstream LE repo is archived: https://github.com/LibreELEC/mali-bifrost
-
Not sure what the reboot issue is about (no issues here). Flakey bootloader?
The more reading I do on nouveau, the more obvious it is that anything before GeForce 8-series is uncharted territory. As the LE12 release used the nVidia 340.108 driver which also didn't support anything below 8-series, the obvious design decision is to simply not-support anything older than 8-series cards. That also removes the need to build with LLVM support (saves build time), and that avoids the runtime complexity of picking the right mesa back-end based on PCI card ID's.
I'll continue to look at the no-audio problem on my Xtreamer Ultra2 board, but that's probably an isolated issue.
-
-
Kodi log isn't useful, it doesn't contain anything about the kernel setup. Run "dmesg | paste" after clean boot (assuming CE has a paste function like LE).
-
If you used the backup function in the LE settings add-on it includes /storage/.kodi/addons in the backup so the restore reinstated the incompatible LE12 add-on version. Just uninstall the add-on (keeping config) and then install the correct one from the LE repo.
-
The VDPAU::Open: requested picture dimensions (1920, 800) exceed hardware capabilities ( 0, 0) is the result of building mesa without support for patent codecs (VC1, H264, H265) hence only the free codecs (MPEG1/2/4) work. Configuring mesa build options with -Dvideo-codecs=all gives working hardware decode. Please validate that with the 9400GT card and the latest image posted to my test share.
I'm not sure what mesa juju is required for fallback to LLVM on the older 6100/7300 cards. I need to find the Slackware mesa and Kodi build configs to see if I can spot the difference(s).
-
Well, everthing is Ok but Iptv simple client version 21.10.1.1 doesn't work, it simply says it's not compatible with LE 13 version
I'd guess that you first installed LE12 and the LE12 compatible version of iptv.simple, and have since bumped to LE13, but for reasons unknown the add-on has not self-updated to the LE13 compatible version. LE13 releases should be using 22.4.1.1 which exists in the LE (12.80.1) add-on repo.
Try doing a force refresh on the repo. If that doesn't work, manually delete the add-on (keeping config) and then manually reinstall the add-on from the repo. Kodi debug logs should contain errors if this fails, but the add-on is there and we don't mirror add-ons or do any fancy traffic management/blocking on servers, so the main reason for add-on updates/installs to fail is basic connectivity issues on the user end.
-
Please update to the Legacy image in my test share which should now have LLVM support. Please see if that runs on the 6100 or 7300LE cards? If yes, share a Kodi debug log.
NB: Firmware will download on the first boot of the image. Please also check it's present in /storage/.config/firmware/nouveau?
EDIT: I'm also interested to know if you have working audio output on the LE image?
