--- a/xbmc/windowing/gbm/WinSystemGbmGLESContext.cpp
+++ b/xbmc/windowing/gbm/WinSystemGbmGLESContext.cpp
@@ -145,7 +145,7 @@ void CWinSystemGbmGLESContext::PresentRender(bool rendered, bool videoLayer)
}
else
{
- KODI::TIME::Sleep(10);
+ KODI::TIME::Sleep(40);
}
}^ If someone is compiling their own images and understands how to track CPU usage, that might be of interest.
Interesting. One of the contributors is ilmich and the other is known(ish) to me via Armbian. I was able to compile the driver and trigger probing on a Tanix TX3-mini with a small device-tree tweak to the SDIO node but the driver didn't load: http://ix.io/3Noj - it probably needs some firmware/config stuff adding - it's not clear what though.
NB: Existence of the driver is one thing. LE would want to see it being upstreamed to the kernel before we'd consider picking/backporting the upstream submitted patches to images. Community images are something different.
Here's an example of another panel device listed in that yaml file being added to a device-tree:
How well that transcribes to your (different) panel .. I can't say. I'd be asking the vendor/manufacturer for examples. The RPi forms are also probably a better source for help on that kind of thing than here - our expertise rather stops at "connect HDMI cable" 
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.
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.
I pushed the revised dts to my repo. I didn't change anything else with usb, but do you have that change?
deltasjimmy there's lots of prior art for overlays with the RPi boot files. Look in the Pi foundation kernel repo.
LE settings add-on > Updates > Firmware .. if any bootloader eeprom or USB firmware updates are needed they will be visible here and you can enable the update (it will then be done on next reboot).
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
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.
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.
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.
MPD Client is not working with Matrix KODI because of dependency issue
What dependency issue?
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:
/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.
Ahh, thanks for the correction
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.
RE: Zero see https://github.com/radxa/kerne…0#issuecomment-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:
+&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.
[ 2.037266] dwc2 c9100000.usb: dwc2_core_reset: HANG! Soft Reset timeout GRSTCTL_CSFTRST
[ 2.039904] dwc2: probe of c9100000.usb failed with error -16Hmm.. I will bug maintainers for ideas on the IRQ splat - I also see it on a Bananapi-M5 board. This ^ also needs looking into.
