Posts by chewitt

    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?

    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?

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

    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 :)

    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.

    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.