Posts by chewitt

It's normally faster to backup and restore than clone as less data is being moved, and you avoid issues with disk/filesystems being different sizes.

Kodi binary add-ons might be small but are still built using the LE buildsystem, which 100% does not support compile on Windows.

Quote from goAtsy

Are some more likely to be stable than others, due to some development cycle or similar, or is it random?

The devil is in the details of what specifically changed on a day-to-day basis. We tend to queue anything majorly distruptive for the start of the release cycle but in recent years even those have been quite smooth. For context, the family daily-driver RPi5 has been running dangerously unstable sounding "pre-alpha" K22 images for more than a year now without any drama. Hopefully K22 will start lurching towards release soon.

<?xml version="1.0" encoding="utf-8" ?>
<advancedsettings version="1.0">
  <loglevel hide="false">1</loglevel>
</advancedsettings>

That ^ content will enable debug logging without the OSD.

The current log is /storage/.kodi/temp/kodi.log and previous log is kodi.old.log, there are kodi crashlog(s) in the same folder. The current and previous log are rotated with each reboot so they are persistent but not preserved. Crashlogs are preserved.

You cannot build LE images natively on Windows and since an older Ubuntu release (16.04/18.04) is required to build older LE images it's not possible to use WSL either. Virtual machines are the only option.

The audio card is not probing correctly for some reason, which is a kernel problem, so everything you then see in userspace via Kodi logs is the result of the audio card not being present.

Apr 03 22:34:29.889183 LibreELEC kernel: ALSA device list:
Apr 03 22:34:29.889203 LibreELEC kernel:   No soundcards found.

The kernel doesn't detect/setup the audio card; hence nothing is seen in Kodi.

The OF: /sound: Read of boolean property entries in the system log are unusual and something I'll look into, but I don't think they are related to the issue as I also see them on an Odroid N2 board here which has the audio card detected fine.

I don't have any Dreambox hardware so I'll need to defer investigation to _emanuel_ who does.

EDIT .. this is more concerning:

Apr 14 18:27:14.278630 LibreELEC kernel: platform ff642240.audio-controller: deferred probe pending: platform: supplier ff642280.reset-controller not ready
Apr 14 18:27:14.279563 LibreELEC kernel: platform audio-controller-1: deferred probe pending: axg-tdm-iface: failed to get sclk
Apr 14 18:27:14.280314 LibreELEC kernel: platform ff642540.audio-controller: deferred probe pending: axg-tdmout: failed to get pclk
Apr 14 18:27:14.281349 LibreELEC kernel: platform sound: deferred probe pending: axg-sound-card: can't parse dai
Apr 14 18:27:14.282533 LibreELEC kernel: platform ff642480.audio-controller: deferred probe pending: axg-spdifout: failed to get pclk
Apr 14 18:27:14.283568 LibreELEC kernel: platform ff642680.audio-controller: deferred probe pending: axg-spdifout: failed to get pclk
Apr 14 18:27:14.284233 LibreELEC kernel: platform ff642744.audio-controller: deferred probe pending: (reason unknown)
Apr 14 18:27:14.284768 LibreELEC kernel: platform ff642280.reset-controller: deferred probe pending: meson-audio-arb-reset: failed to get clock
Apr 14 18:27:14.285620 LibreELEC kernel: platform ff6421c0.audio-controller: deferred probe pending: platform: supplier ff642280.reset-controller not ready
Apr 14 18:27:14.286495 LibreELEC kernel: platform ff642200.audio-controller: deferred probe pending: platform: supplier ff642280.reset-controller not ready

Possibly something wrong in device-tree then.

The current nightly images are Linux 6.14.2 the same as my images. If you go back a month to an LE13 nightly image that uses the older 6.12.y kernel is anything different? - share the system log, ideally with 'debugging' removed so the log is not full of verbose connman content.

Maintaining our apex position is about keeping the power to shepherd limited resources and control our workload, not to dominate others, there's no agenda for that. The same cannot be said for some of the downstream elements of our ecosystem.

I'm home again from Tuesday so if you're around in evening hours (GMT+4) ping IRC and we can chat.

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.

Have a read here: https://wiki.libreelec.tv/hardware/amlogic