Posts by chewitt

Quote from sunlollyking

What's the chance some of this work begins to get merged to master?

At the moment the chances are low because development is in the full-throttle rush of bring-up with everyone getting high on new frontier models doing previously unthinkable magic

I would encourage focus on the "insert disc, press play" capability that allows DV media to work on a broad selection of devices and distros with a simple user experience. Avoid the temptation to add lots of config options and display readout. Kodi maintainers are allergic to config options because most are workarounds for kernel drivers that do the wrong thing; and the correct albeit slower resolution for that is always fixing the kernel driver. Similarly, if metadata is useful for development, log it in a debug log instead of cluttering up the OSD.

LE (master) will be happy to start doing official experiments once we see engagement on upstreaming. I suspect that will take time, but we are not in a rush (least of all Kodi) and we prefer to see things done in a long-term sustainable way.

NB: I'm thinking to take an N150 box with me to the VideoLan developer conference in Rome next weekend as there's normally a show-n-tell session, although there's no guarantee the TV's or projectors in the venue will support DV.

Home > Addons > (Navigate to add-on) > Context Menu > Information > Uninstall

CroqueMr Kodi support for DRMPRIME is designed for ARM SoC hardware using direct-2-plane rendering. Although the GUI will allow it to be enabled with VAAPI decoding too, there a bunch of unresolved issues. If you have Intel/AMD hardware you need to be using EGL/VAAPI only.

I pushed updated images for all boards to https://chewitt.libreelec.tv/testing

The notable change is a reduction in CMA memory reservation from the 896MB value in past AMLGX images with stateful decoders to 384MB with the new stateless implementation, so use with low-spec 1GB devices should be good. The VIM1S is feature complete enough for general release (boot splash issue resolved). There are also some minor decode fixes that result from running fluster compliance tests; tnmeyer the green garbage in test2.mkv is resolves for me.

Quote from perpis

Does anyone have any idea why this is happening?

iMX6 support in LE is in a semi-abandoned state. Our assumption is that there are enough commercial users of iMX6 chips for media support to be maintained upstream without us needing to do anything. That assumption might be wrong and some testing might be needed; although the challenge will be finding anyone with time and hardware to do it.

I so have a Cubox-i in a cupboard somewhere (it last saw daylight around 2022) but I'm submerged in other things at the moment and can't promise I'll be able to dig it out any time soon.

NB: it would be interesting to see the "pastekodi" output after demonstrating the problem with Kodi in debug mode. Share the URL and we can maybe see more about what's going on.

ashi which device-tree file are you using in vendor kernel images?

I've pushed updated 'Amlogic' images to my test share. The notable change is initial LE support for the Khadas VIM1S board which uses the S4 (S905Y4) chipset. This required a whole heap 'o new tricks to be learned. It currently has the same capabilities as a G12 or SM1 board as we didn't start work on AV1 decoding yet, and the LE boot splash won't show until further work on u-boot video output gets completed. Aside from that it's a usable image though.

Minor kernel and Kodi bumps are also included but nothing that should be noticeable. No other changes (hopefully not regressions) as the last week was entirely spent on S4 bring-up

tnmeyer I can reproduce the green garbage with test2.mkv file. I haven't had a change to look into it yet, as have been busy with other things, but will do when time allows.

Remove the EDID workaround, then remove the RPi5 from the Argon case and test again. Does the problem resolve itself when not using the shitty connectors in the Argon case?

The obvious solution is updating to a current nightly which brings 14-month's worth of fixes/updates and an active repo, no?

LE13 or LE12.2 nightly?

If LE13, the only repo's we keep long-term are the release ones. Development repo's are version bumped periodically when either we or Kodi make breaking changes, and a month or so after bumping we normally delete the previous one to save disk space. The development cycle for K22 has been long and we bumped the repo a few times so the repo version for a nightly image more than a year old will be long gone. You have two self-build options: either revert the master branch to a similar date point to the image and build the add-on that you need. Or (as Cubox shows almost zero active installs and we disabled CI for it) self-build a current LE13 image and it will be able to access the current add-on repo (shared with all other 'arm' arch devices we support).

If LE12 or LE12.2 .. as long as the nightly is since the main release it uses the production/release repo (which still exists) and there is some kind of networking issue between the device and our repo that stops you from accessing it - or Kodi started before networking was fully up and the initial connect failed. Start with ensuring the boot delay is active in Kodi settings (or make it longer) and then doing a forced refresh of the repo a couple of minutes after boot.

ashi At the moment the demux driver is an ugly port of even uglier Amlogic vendor code with support limited to the ~3 devices that myself and rozpruwacz have (and I have WP2 with DVB-S/DVB-T modules). Some work on a clean rewrite of the driver has started, but needs to be revived and moved forwards. The goal is to make all the drivers modular so technical implementations of demod/tuner/demux can described entirely within device-tree without relying on a single/monolithic driver with baked-in known combos of chips, which is how the vendor kernel works-ish. It's probably not a quick task happening in the next few weeks.

For the sake of asking, what chips are in the Mecool box and can you point me at a device-tree file?

And if you put in the passphrase?

Complaints about invalid-key errors tailed right off over the last six months. So while there was never a eureka! moment that would allow a general claim of solving the issue (AFAIK nobody on staff has made one); the changes made that suggested they might have influence on the issue have either mitigated triggers, or perhaps everyone switched to Ethernet or started using other hardware or did something that changed their environment. Your guess on that is as blind as ours.

I'm interested to know if adding this and rebooting changes anything?

echo "options brcmfmac feature_disable=0x2000000" > /storage/.config/modprobe.d/brcmfmac.conf

Your optimism is noted, but to be crystal clear: If anyone shows up in this forum with a 1GB board and 4K playback issues we're going to auto-respond by pointing fingers at RAM size and investigate no further.

LE auto updates minor versions but never major versions (so won’t do 12 > 13 even when LE13 is released). The OS itself is no problem but addons can experience issues so we never force that.

You need to combine kernel with ffmpeg and alsa and firmware changes; it’s all tightly aligned. It’s all in my GitHub account, and the LE repo; I pushed changes to master last night.

Start with an update to LE13, then if nothing changed run journalctl | paste after demonstrating the problem and share the URL