I'll have a look at the sample video later in the week once home from Kodi DevCon.
I'm not sure there's a default button for next language, but you could create a custom keymap that uses AudioNextLanguage if that's one of the built-in Kodi commands.
You can mark threads as resolved using the "Edit Thread" button above ^
I'm interested in feedback on the Nouveau image once you've spent more time using it.
No idea, perhaps the LE 9.2.8 image that dtech maintains. The last official vendor kernel image was LE 9.0.2 which is no longer maintained or supported. The images are still downloadable but you're on your own for install/boot support.
It worked with an LE12 release image when I last tested it about a year ago. In semi-recent experiments with nouveau there was also a sound bug, but the solution for that was a patch in mesa, so that wouldn't be applicable to something using the nVidia driver (as a different driver). On that note, this is an LE13 image with nouveau from January that you're welcome to experiment with:
https://chewitt.libreelec.tv/testing/LibreELEC-Nouveau-Legacy.x86_64-12.80.1.img.gz
It's 100% unsupported, and I'm not sure we'll support nouveau with LE13 as while it boots/runs, the older nVidia GPUs are not really tested and maintained well and I've seen some issues in test.
I've seen a handful of reports of no audio with Atom/ION devices in the last two years, but I was never able to replicate them with an Xtreamer Ultra2 board (the only ION thing I have) and in LE12 we're using the latest/laste nVidia driver available; which is dropped from the LE13 codebase as it no longer compiled against the latest xorg release; so whatever that (unknown) nVidia forum post was talking about has long been included in drivers.
Does the BIOS have any audio options? .. perhaps a switch for AC97/HD-Audio? - If yes what happens if you change them? Have you also experimented with all the available audio devices listed in Kodi?
Can you bisect the issue using older LE12 nightlies to find when the breaking change was introduced?
Thoughts summarised from private chat with core team members:
It doesn't make sense for LE to ceed control and its apex position. Our buildsystem is designed around our own needs, follows our own schedule, and is managed to our own standards. Our core team is small and focussed on contributing to LE, and multiple contributors flag themselves as less likely to remain engaged with the project if focus or effort levels are notably changed. Carving up the buildsystem in the way you've described is overwhelmingly seen as a compromising move.
Over the last decade we expended considerable effort to move away from vendor codebases. They are static which causes long-term package management issues as the needs of upstream Kodi and core packages like kernel and u-boot continously move forwards. They inherently accumulate ever-more technical debt over time as there is nowhere to offload and upstream changes to. Creating a pseudo-upstream target solves that issue for downstream forks and the forks of forks, but will progressively complicate the pseudo-upstream fork. Having worked for years towards eraditcating that problem from our codebase, LE does not want to be the pseudo-upstream target, or to be downstream from that pseudo-upstream target. If the community wants to support a device that has no upstream support, our belief is the community should focus on upstreaming support, which benefits the entire Linux ecosystem not just the audience of *ELEC projects.
The group of interested parties you foresee harmoniously working together on a common mission contains specific people who we collaborated with in the past, and would never want to interact with again. It also includes groups we already have an excellent relationship with, who choose to keep a level of downstream independence even when they openly recognise working with us more directly would reduce their own effort. They value being able to do what they want, however they want, whenever they want.
We are already broad collaborators: our Slack instance is ~20% regular contributors and 80% external folk we share interests with. We intentionally keep Slack invite-only to force separation from end-user support and to ensure it remains a polite and productive workspace. We will continue to invite and focus on people we established a positive rapport with.
We are not against structural buildsystem changes that improve downstream coexistence. We are not against accepting more distribution/project/device targets; adding things that are not always built is nothing new. However long-term maintanability always trumps short-term demand, so there will be limits on what we accept, and for larger changes we will need to trust the contributors. Rather than tackle large impossible topics, people need to focus on smaller code problems and technical details. We know there are issues downstream, but we don't spend our lives poking around in other peoples problems so we do not understand specifics. As the saying goes: If you need to eat an Elephant, do it one bite at a time.
If you rename things to dtb.img the LE image will not boot. Those are instructions for legacy LE images and other distros.
The correct (current) instructions for AMLGX image are here: https://wiki.libreelec.tv/hardware/amlogic
See: https://github.com/xbmc/xbmc/pull/26368
The PR is (was, it's merged) more about a bit of soft-promotion of flirc because Team Kodi receives royalties on Kodi flirc case sales than anything else, although the add-on might evolve in the future to support programming of the flirc USB device; it's technically possible to do that if the "flirc_util" add-on has also been installed.
It's probably something we'll add to the default image so the flirc receiver shows-up (is recognised) by default.
WiFi: https://github.com/torvalds/linux…c.dts#L135-L140
BT: https://github.com/torvalds/linux…c.dts#L334-L345
Instructions on how to self-build an LE image are here: https://wiki.libreelec.tv/development/build-basics and more build commands are here: https://wiki.libreelec.tv/development/bu…mands-le-12.0.x
Once you have a stock image self-building, tell me and I'll share a .patch file and further instructions.
There is no default SMB share for /storage but there are shares for e.g. 'Videos' which map to /storage/videos so if you drop files into that share they should show up in that location?
Samba will also auto-share "removable" drives that are mounted to /var/media so even though it's not a removable device it sounds like the second NVME drive is being auto-mounted to that location. Samba will create a share based on the disk label of the mounted device so if you labelled it as 'MyDrive' it will create an SMB share using that name that maps to the underlying /var/media/MyDrive location.
If you want to edit the default SMB shares: https://wiki.libreelec.tv/configuration/samba
It doesn't really sound like you've done anything wrong and using a Mac as the client device accessing shares isn't unusual.
If you SSH into the HTPC using Terminal.app on macOS, run this command and share the URL that's generated by 'paste'
ls -alh /storage/videos /storage/tvshows /var/media/MyDrive | paste(edit /var/media/MyDrive to match whatever you called it).
The debug log will show all the movie properties that I'm interested to see.
If this is the correct device-tree?
I don't see anything about WiFi/BT inside the dts file and I don't see any patches in our buildsystem for support. If you know what content is required to enable the module and you have some basic technical skills it's not hard to self-build an image with an extra patch to add support.
If you install from my image and then downgrade to 12.0 you are no longer running my image. The 12.0 nightly might not boot. It's hard to comment further because we're both talking hypotheticals. I haven't booted a C2 for some time and have no plans to dig a board out for a couple of weeks due to travels. So just experiment and see what happens.
NB: Even if you prove something is broken in the LE12 image and resolved in the newer one we aren't going to backport Linux 6.14.y or libCEC 7.0 to "fix" the LE12 branch so the information is entirely academic.
If things don't work, you have my LE13 image to use. K22 will start moving towards release soon.
The sample file isn't long enough to show the problem, but a Kodi debug log will be more informative.
You can drop the .tar files in /storage/.update but Kodi does not support downgrades so after downloading the .tar file to the board you need to manually stop Kodi and rename /storage/.kodi to /storage/.kodi22 before rebooting to start the update. On restart after the update this will give you a clean K21 instance to (re)configure.
Note that I don't keep archives of my older K21 images and I bumped to K22 more than a year ago, so the only K21 images around are the official releases which allegedly have a boot bug on C2 boards. It will start u-boot then fail to boot into the kernel, but this only visisble with a UART cable connected.
Also note that earlier K22 images in my share solved the boot bug with a workaround in u-boot, and the latest images solve it with a kernel fix submitted upstream (that should do the same thing). I'm not sure if the board will boot with u-boot from the latest image and kernel from the older one. You'll have to try it and see.
If anyone needs an RPi5 image that includes that patch, I pushed one here:
https://chewitt.libreelec.tv/testing/LibreELEC-RPi5.aarch64-12.80.0.img.gz
(sorry, haven't used Generic x86_64 for years now)