Posts by chewitt

  • Question with Addon paths

    Have a look at how inputstream.adaptive depends upon widevine CDM files being installed to the OS in a known location. If the files are not present, the add-on initiates a download of a ChromeOS update file which contains them, and then the update file is unpacked and the needed files are moved to a consistent location where inputstream.adaptive can find them. This keeps the core add-on size small (and avoids the legal issues involved with pre-bundling the widevine files).

    In your case you can detect distro by looking in /etc/os-release and if LE, initiate a download of the needed (bulky) files to a cache location under /storage/.kodi or somewhere else on /storage, and if not LE, check for the package being installed in the known location. Then set the media file paths to either the cache location or the /usr location as needed. On other distros you'll need to gracefully handle the dependency on the app binaries being installed anyway.

  • Tonemapping HDR content to SDR on RPI4

    Things that use the Amlogic vendor kernel (and suitably hacked versions of Kodi) support HDR > SDR tonemapping - on Linux or on Android using devices. Otherwise you are waiting for Kodi to support it, and drivers to be written for other ARM hardware that has hardware modules that can do it. Or you need to re-rip original media without HDR (which would have made sense since you don't have an HDR capable TV) .. or use a TV that supports HDR.

  • Live-TV nearly not useable

    Kodi can only output progressive, so to handle interlaced media you *must* be using 'doubled' modes for playback, e.g. PAL 25Hz must use a 50Hz mode from the TV. In other words, a 1080p whitelist would be 60/59.94/50/24/23.976 .. deliberately no 25/29.97/30 modes. If you also find one of the pre-10.0.2 testing images from HiassofT these have deinterlace support, it will be in the next 10.0.x release (soon, we hope).

    I'm using TVH from a server 4,700 Km away and it's pretty usable :)

  • Vero 4K+ board bring-up and testing

    I'm aware of a well known SOM board manufacturer who's nearing launch of an A311D based product, and an early customer wants upstream kernel and working video on Linux so I've been connecting their lead developer to all the right sources and bits, and he's preparing to start looking at the code although we need to be patient as there's some other tasks on the board bring-up list right now. How much overlap there is between his customer's needs and our needs remains to be seen, but I'm hopeful that we can get another lurch forwards on the newer hardware out of it. Otherwise we're at the mercy of community development. It needs one or two 'community' developers with some driver skills and time on their hands who are prepared to experiment and learn. Some of the changes needed probably aren't too big .. it just needs the will to fiddle and do trial/error testing.

  • Official LE11 Test Images for Amlogic (Kodi-20)

    Quote from tomaszc

    Do these types of bugs need to be reported somewhere or assume that the developers know about them?

    Who is developing this codec? Is this project available somewhere like github, or is it integrated with Kodi?

    If you've anything insightful about codecs to share, please share it. If you've just got a "this doesn't work" to report, we already know it.

    The code is in the upstream Linux kernel staging area: drivers/staging/media/meson/vdec

    Nobody is currently developing this code. That should change soon, but we have to be patient.

  • Vero 4K+ board bring-up and testing

    I don't see any mention of the GPIOs in the original dts files either, but "If it works, don't fix it" so I think we're good. Can you share a final dmesg with that applied please.

    It would also be good to validate the 4K dts as well, although ethernet on that should be trivial as all S905X use internal PHY and there's nothing to configure. I suspect only the usb fix might be needed.

    Sadly the next round of improvements will be all about media codecs, which is beyond my code-skills.

  • How do I fix the error that appears on boot?

    Code
    boot=UUID=0602-0454 disk=UUID=a7ecf32f-d897-4f8e-b760-03d219e31c88 quiet ssh

    ^ cmdline.txt normally looks like this, with both "boot" and "disk" using UUID identifier. I'm not sure why yours is using =label for the "disk" but it can be changed. The UUID will be unique to each .img.gz file that we release so ^ above is NOT something you can use, as it's for an image I've created that you don't have. You can find the UUIDs for your image using "blkid" command. It will look something like:

    Code
    /dev/mmcblk0p1: SEC_TYPE="msdos" LABEL_FATBOOT="LIBREELEC" LABEL="LIBREELEC" UUID="0602-0454" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="a0ebf7ce-01"
/dev/mmcblk0p2: LABEL="STORAGE" UUID="a7ecf32f-d897-4f8e-b760-03d219e31c88" BLOCK_SIZE="1024" TYPE="ext4" PARTUUID="a0ebf7ce-02"

    You can see that the /dev/mmcblk0p1 (partition 1) needs UUID=0602-0454 and /dev/mmcblk0p2 (partition 2) has a much longer UUID=

    a7ecf32f-d897-4f8e-b760-03d219e31c88 .. and in cmdline.txt there is a space between the boot=UUID=<string> and disk=UUID=<string> sections.

  • Official LE11 Test Images for Amlogic (Kodi-20)

    The HEVC decoder has poor memory and buffer management which impacts resource usage and seeking; the legacy of it never being finished by its original developer (and beyond making the unfinished code run, nobody really touched it since). My semi-educated guess is that HEVC doesn't release CMA memory correctly and then when you play media requring a different codec the new codec can't reserve enough CMA and things start to fall (and hence a clean boot works around the issue). It all buckets under "HEVC needs work" and I also confirm MPEG2 is not working right now (packets go into the driver, nothing comes out).

    S912's have always run hot so a good heatsink is never a bad thing. I've a VIM2 + heatsink which runs around 60-65ºC so I'd be wondering what add-ons you're using that chew CPU in the background (some do) to keep cores busy.

  • Vero 4K+ board bring-up and testing

    RE: Zero see https://github.com/radxa/kernel/p…ment-1013592761 .. although I'm not sure whether A311D (more compute, but also more power needed, more heat given off, etc.) is a good fit of the small package size. A sample is in the post so I get to have a play someone soon in theory. I do like the S905Y2 version as I can power it off the UART pins and it runs well except for the state of playback on newer devices (there are some problems). There's a plan for fixing things but we need to be patient while developers work through other items on a long board bring-up list .. and eventually they reach the subset of media topics we care about.

    4K and HDR works quite well on GXL/GXM devices although GXL internally processes at 10-bit but outputs only 8-bit (GXM can do 10-bit).

    Latest attempt at the IRQ splat with suggestions from maintainers - see if it works:

    WIP: arm64: dts: meson: add support for OSMC Vero 4K/4K+ · chewitt/linux@12d9c05
    The OSMC Vero 4K device is based on the Amlogic S905X (P212) reference design with 10/100 Ethernet. The Vero4K+ is based on the S905D (P230) reference design…
    github.com


    Code
    +&usb2_phy0 {
+       /* HDMI_5V also supplies the USB VBUS */
+       phy-supply = <&hdmi_5v>;
+};

    ^ also see if that works for the USB error?

    EDIT: I've pushed updated box/tar files with those changes.

  • Vero 4K+ board bring-up and testing

    Code
    [    2.037266] dwc2 c9100000.usb: dwc2_core_reset: HANG! Soft Reset timeout GRSTCTL_CSFTRST
[    2.039904] dwc2: probe of c9100000.usb failed with error -16

    Hmm.. I will bug maintainers for ideas on the IRQ splat - I also see it on a Bananapi-M5 board. This ^ also needs looking into.