Posts by chewitt

  • LE13 Testing for RK3288, RK3328, RK3399, RK3566, RK3568, RK3576, RK3588

    I've read the feedback. I'm still experimenting with AI tools to see if they can bridge the gap in my rather lightweight coding skills or we have to resort to nagging Collabora folks to take over (or cap the current driver at 1080p to get an initial merge).

    HDR works, 8-bit only? (HDR is better when 10-bit but it's not mandatory) as RK3566/68 use the older Rockchip HDMI IP which has more colour support upstream. The newer one used with RK3588 etc. is still missing some infoframe handling IIRC.

    btw, Jonas believes https://github.com/torvalds/linux…2fdfc001d044bee might have resolved the "wiotlb buffer is full" IOMMU issue that requires RAM to be capped under 4GB. I'm going to remove the cap on my boards and see if I still get a load of weird errors. Please do the same on your LE images.

  • How to create a playlist?

    Read: https://kodi.wiki/view/Internet_video_and_audio_streams

    Create .strm files for each Soundcloud URL that you want to use as media. Kodi treats these like a media file with no metadata.

    Create .nfo files for each .strm file. This is required. It also provides a way to add metadata, e.g. pretty names, if wanted.

    Scrape the .nfo files to the Library.

    Add Library items to a playlist.

    Do something with the playlist, like script it being started 20 seconds after Kodi starts (how you do that is .. Google'able).

    Plan B .. get a Raspberry Pi and use one of the many good niche distros or RPiOS installable apps/containers designed for "signage" use-cases, as that appears to be the end goal and something Kodi is not really designed for.

  • LE13 Testing for RK3288, RK3328, RK3399, RK3566, RK3568, RK3576, RK3588

    axel I've spoken to Radxa about the AIC8800 wireless chip a couple of months ago as it's also fitted to one the boards I've been using to test. Radxa have no plans to upstream the driver as this would require a large effort, i.e. complete rewrite as the current quality of driver code would never be accepted into the kernel, and after years of working to rid our codebase of the maintenance burden of downstream (mostly Realtek) drivers we have no desire to add technical dept in the form of another vendor driver that has no plan to be upstreamed. I've shared our surprise/annoyance and position, and have strongly suggested they stick to using Broadcom, Qualcomm, Realtek (now upstream) chips in future iterations of current boards and future board designs so distros can avoid the need for crap drivers. I'm not sure LibreELEC's opinion will carry much commercial weight with them, but from our side, there's no action to be taken.

  • RPi5 kernel development image

    If you are proficient in Docker then it should be trivial for you to use the Docker files in tools/Docker that result in a pre-configured and working build environment for creating an LE image. Once you have a working LE image, add a package for the xone driver and build it into the image and push the changes to GitHub/Gitlab etc. so others can see the package.mk recipe.

    It is not impossible to build a driver add-on, but the general challenge is that kernel modules must have the same 'version magic' as the running kernel, and in LE the add-on repo version is loosely aligned to Kodi API version and not kernel version. This means for each add-on repo version users will have a range of different kernel versions in use. The kernel's media-tree used to support 'media build' which provides a method for compiling and running 'DVB' kernel modules from an older codebase to run on a newer kernel version. LE has previously used this to package a bunch of DVB drivers for e.g. TBS cards as an add-on. We have since stopped doing this because it's a pain in the rear to maintain, but the prior art still exists in the buildsystem and you could use the same approach to create an add-on for the Xone driver.

  • LE13 Testing for RK3288, RK3328, RK3399, RK3566, RK3568, RK3576, RK3588

    Quote from axel

    Zero 3W, and it booted fine however, no wifi card appears to be detected, nor bluetooth

    I can see that device-tree defines the module, but I can't see anything in documentation that states which Broadcom chipset is being used. It's probably something new(er) that we don't have firmware for, but as you didn't share the system log .. that's only a blind guess and could be wrong. In short .. no idea /shrug

  • [x86-64] How to change resolution manually?

    SSH in to the box, make /flash writeable with mount -o remount,rw /flash then append video=HDMI-A-1:1360x720M@60D to kernel boot params in syslinux.cfg in the boot partition and it will force the initial kernel DRM state for the HDMI-A-1 connector to use that mode. For this to work the kernel needs to detect/see that mode via EDID data on the same connector. Adjust the connector name to match whatever HDMI port is being used (if there is more than one). Adjust the resolution to one that is listed if not, e.g. if the TV supports 1080p then use 1920x1080 not 1360x720. The kernel is probably auto-selecting an initial display mode based on the modes advertised but for some reason the TV doesn't actually like that mode (bad EDID data can be a thing sometimes). The same is seen sometimes with 4K TV's and forcing the initial state to 1080p helps.

  • SSD connected over USB won't mount

    Quote from wolf7250

    I'll try to go through the link you sent me in detail soon. If I have some questions, would it be OK to ask you back here in this thread?

    Sure. In high-level detail: Create a default image first, then all you need to do is modify the kernel defconfig enabling the missing kernel options then re-run the same build command. The buildsystem will run through the image build process again but only rebuild the kernel package. Once complete, push the image .tar or .img.gz file to /storage/.update and reboot to update using the custom image.

  • [RPi5] No real good working over longer period of time

    The config here is generally recommended https://wiki.libreelec.tv/configuration/4k-hdr and is written by me from experience with multiple ARM SoC boards; but mostly RPi4 and now RPi5 which are the family daily-driver devices. I don't have any issues with green artefacts on the screen aside from occasional moments streaming live broadcasts from a Tvheadend instance; due to signal issues on the DVB-S2 side of the setup, or bandwidth glitches which result from the Kodi client being 7,000Km from the server.

    I would start with an update to a current LE13 nightly as even if you find an issue with LE12/12.2 we have no plans for more releases that would bring fixes to that version. Running newer/latest everything might not solve anything; but at least you eliminated 1,000+ differences between versions from possible suspicion.

  • [x86-64] Correlation between Pixel Depth and Audio Interruptions

    It would be academically interesting to see the simple (but ugly) workaround in that script used on the LE install to confirm it's the same problem. If it is, the issue is deep in driver code and no amount of configurable logging will show anything useful. It would need the driver modifying to add custom debugging to figure out, and that's something for Intel engineers to do. Unfortunately they don't seem to have grasped the issue yet (admittely we didn't poke them for a while) so it remains unresolved.

  • [x86-64] Correlation between Pixel Depth and Audio Interruptions

    The problem description reminds me of the issue with N100/N150 boxes where running the display at 12-bit depth (driver default) results in audio dropouts, but capping it at 10-bit results in lower HDMI bandwidth consumption which leaves sufficient bandwidth for audio to also fit. See this script: https://github.com/LibreELEC/LibreELEC.tv/pull/8588/files which remains un-merged because it's a rather ugly hack and a proper code fix needs to be found. See if that improves things?