Posts by chewitt

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.

Yes, correct. It's now zstd compressed and saving you space.

Quote from adamosborne83

Will the nightlies work on Ugoos SK3 powered SoC RK3588S2-DV and 8/128 GB on board?

I don't think so. I've not seen any mention of RK3588S2 support in the upstream kernel (only RK3588/RK3588S). The SoC differences are likely minor, but as there is no u-boot defconfig or board dts in the kernel for that box, LE will want to see those pieces in-place before offering support. NB: AFAIK there is no 8K support for RK3588 at the moment (in the to-do list, but not at the top) and DV will likely require some proper reverse engineering. I wouldn't rush out to buy one just yet.

Test the modprobe file please.

LE 12.2 or LE13 nightly? .. If on LE12 still, update to LE13.

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

If you run that ^ over SSH and then reboot, does this restore previous behaviour?

This should functionally effect a revert of https://github.com/LibreELEC/LibreELEC.tv/pull/11785 which is a direct feature/capability change for the wireless stack that would have rolled out in RPi5 nightlies around September 19/20.

HiassofT FYI

Quote from ht2tweak

I went for 4GB to be safe, have enough headroom for heavier skins, larger movie/TV libraries.

Heavier skins tax the CPU, GPU, and I/O performance, not RAM. Libraries do impact on RAM.

An NVME HAT with a small M2 drive is a nice upgrade.

dale I'd guess some changes are needed in the kernel. I'm currently up to my neck in Amlogic things but will add it to Claude's worklist once I circle back on Rockchip topics.