Don't know if this is the same issue
The original thread is discussing the SMB client in Kodi and you're talking about the Samba server in the OS, so I've moved your post into its own thread. Start with an update to a current LE13 nightly as we're unlikely to fix anything in the LE12 codebase now.
How was the controller connected .. using the GUI or bluetoothctl?
What's the range/distance between board and controller?
Is the board in a case? - If yes, what happens when you remove the board from the case?
Update to an LE13 nightly (they are not unstable at this point in the dev cycle, I've been running them for ages).
Have you looked on eBay UK?
systemctl stop pulseaudio.service
systemctl disable pulseaudio.service
systemctl mask pulseaudio.serviceThose ^ commands will workaround the pulse problem, but it shouldn't happen on a clean install. It would be useful to see the URL/output of "pastekodi" with Kodi debug mode to see if there's more info or clues to the cause.
You can use the bluetoothctl utility over SSH to pair/connect devices. If it works there, the issue resides in the LE settings add-on. If it also fails there, it's either a bug in BlueZ or something funky about pairing the device.
For kicks, check the 12.0.2 release and/or the latest LE13 nightly.
Have you tried updating the existing install instead of reinstalling? .. our general advice is to clean install when making large OS/Kodi bumps but all you really need to do is stop Kodi and rename /storage/.kodi to /storage/.kodi-old so the post-update Kodi starts with a clean config and no Python2 add-ons installed.
Kodi on Android has massively improved in recent years, driven by Kodi forcing and adopting Google standards, and this reflects in general usage stats (Team Kodi doesn't track active installs, but we see download volumes and forum traffic). The weak link is thus the underlying Android kernel codebase for any particular vendor and/or device combination, and how it implements or ignores those standards. If the device follows standards, Kodi runs well. If it includes lots of hacks to make specific apps (that don't follow standards) work better, that often degrades the experience of other apps. TL/DR: there's not really an answer, but you can install and try for $free.
Add "ssh" to kernel boot params and the daemon is forced on during boot so you can login, then "journalctl | paste" to pastebin the system journal.
Just boot from the SD card. The OS runs in RAM so while there is a difference in I/O speeds, it's not that significant.
warning <general>: Failed to get an OpenGL context supporting core profile 3.2, using legacy mode with reduced feature setThis is a warning not an error/failure. It simply documents that the GPU doesn't support Core 3.2, but the minimum requirement for Kodi is 2.1 which this site confirms is more than covered: https://people.freedesktop.org/~imirkin/glxinfo/#v=Mesa%2018.0.0. The site is not updated for current mesa (23.x) but generally things don't regress much.
I've tested 12.0.2/340.108 in the last week when poking Nouveau and it worked fine with my GT520 card. That points towards it being an issue with older cards. If it also doesn't work with Slackware, that also points towards a driver issue and not something to do with distro build/packaging.
The kodi debug log isn't useful here as the issue resides lower in the software stack. Was anything recorded in the system journal?
Really dont know how to do the "dmesg | paste" sorry.
You managed to type "dmesg" and hit enter. All you had to do was type "dmesg | paste" and hit enter.
[ 1.543265] mmc1: Card stuck being busy! __mmc_poll_for_busy
[ 1.544665] mmc1: Failed to initialize a non-removable cardThe eMMC storage fails to init ^ and thus isn't visible to the OS, so cannot be addressed. No idea what the underlying issue is, but normally the issue with Android boxes (not specifically WP2) is the chips go bad and throw errors. On the upside, it's failed but still allows SD card boot, which is better than starting to boot and not being able to continue (which can also happen).
The WP2 "board" image you are using cannot boot with the factory Android u-boot on EMMC, so either you wiped/zero'd EMMC to use the image, or the EMMC chips have failed which means the OS cannot detect Android u-boot; thus allowing it to boot upstream u-boot from the SD card.
I'd guess the EMMC chips have gone bad. Share the URL from "dmesg | paste" and we can probably confirm.
RPi4/5 have a single i2s audio interface input, and a single audio driver that supports multiple cards, each with an HDMI connector, and the driver can route audio to either or both cards. The labelling is correct and clear; but alsa is one of the Linux "dark arts" as the terminology (and topology) of things is particularly challenging to understand.
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:
RPi5:~ # 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 #0PLEASE 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.