Posts by chewitt

  • Official LE13 Test Images for Amlogic (Kodi-22)

    Code
    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:

    Code
    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.

  • RFC: Project BootELEC

    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.

  • [S905X] Can't play 4K UHD H265 10-Bit

    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 ^

  • [x86-64 - legacy] No HDMI sound with Nvidia ION

    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.

  • [x86-64 - legacy] No HDMI sound with Nvidia ION

    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?

  • RFC: Project BootELEC

    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.

  • Question about Flirc USB Receiver

    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.

  • Help with SMB share please

    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'

    Code
    ls -alh /storage/videos /storage/tvshows /var/media/MyDrive | paste

    (edit /var/media/MyDrive to match whatever you called it).

  • Pine A64 WiFi/BT Module Support

    If this is the correct device-tree?

    linux/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts at master · torvalds/linux
    Linux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.
    github.com

    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.

  • [Odroid-C2] CEC / AnyNet+ & ARC Issue

    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.