Posts by chewitt
-
-
Any suggestions?
RPi boards simply have rubbish wireless. Use Ethernet. Use an WiFi bridge device that presents Ethernet. Use external dongles with a proper antenna. In short, do anything except try to make the internal WiFi work.
-
I'm not aware of any project staff that use Chromeboxes these days. Have you looked at the MrChromebox site?
Are there any specific errors with the update process?
-
According to aplay output, you've connected both RPi4 HDMI ports. Unplug HDMI-1.
Nope. The aplay -l command does not show connected state, so it is not showing something on HDMI-A-0 or HDMI-A-1 ports.
Here's the output from my RPi5 which 1000% only has a single connection on HDMI-A-0:
CodeRPi5:~ # aplay -l **** List of PLAYBACK Hardware Devices **** card 0: vc4hdmi0 [vc4-hdmi-0], device 0: MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: vc4hdmi1 [vc4-hdmi-1], device 0: MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0] Subdevices: 1/1 Subdevice #0: subdevice #0
PLEASE stop guessing at answers.
-
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.
-
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.
^ 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).