Posts by chewitt

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

Quote from NTM-3D

So if you are buying an RPi5 for this fork go with the 2GB version, even the 1GB version should work if you can find it.

The RPi5 1GB model will not handle 4K media properly due to the RAM size so unless it's a dedicated 1080p/3D device, the 2GB model is our minimum recommendation.

I pushed a set of updated images to my test share. Kernel is 7.3-rc5 and Kodi is v22-rc1.

Known issues are limited to:

- GXBB support for HEVC/H264 is capped at 1080p pending further research into HDMI stability at 4K

- GXBB/GXL/GXM have multi-threaded bwdif software deinterlacing (still a nice improvement on bob)

- MPEG1, MPEG4 and VC1 are software decoded until we author the kernel UAPI(s) to implement around

Otherwise all the important stuff: H264/MPEG2/HEVC and VP9 and 10-bit/HDR where hardware supports it, and pass-through audio, are working on GXBB, GXL, GXM, G12A, G12B, and SM1 hardware. If you find media that refuses to play, or glitches/crashes during playback, we'd like a sample file to investigate.

Image name changed from "AMLGX" to "Amlogic" so do touch /storage/.update/.nocompat before rebooting.

Enjoy

Quote from johnny depp

Is this ‘compression’ also backwards compatible?

No .. but Yes

Older images will not recognise filename.tar.zst as something valid to import, but run unzstd filename.tar.zst and you end up with filename.tar which they do recognise, so it's not a big deal.

Kodi logs aren't going to capture any useful information for a WiFi issue. The problem is way below Kodi in the software stack and you'd need ConnMan and IWD in debug mode to capture anything in the systemd journal.

All of which is moot when the most likely cause requires 10 seconds of effort to run one CLI command, and then reboot.