Posts by chewitt

Using an LE12 image put Kodi in debug mode, reboot, than run "pastekodi" after reboot, and share the URL.

It's a nice idea but the advice was wrong. The underlying OS only sees a shutdown event being signalled when the timer expires. The poweroff schedule/timeout is managed within Kodi so the notification has to be implemented and triggered within Kodi. This will also ensure the feature works on all distros and not just LE.

60 seconds of glancing at Kodi code suggests this is involved: https://github.com/xbmc/xbmc/blob…werHandling.cpp .. but I'm not a programmer, so you'll need to take the intiative.

Also see https://github.com/xbmc/xbmc/pull/23299 which is unrelated but will give hints on where to add settings changes. I'd suggest the time value for the notification (how many mins before timer expiry to pop something) is made a configurable item.

Quote from Shonk

Are there builds for S912 gxm_q200_3g

Use the AMLGX "box" image and pick the Q200 device-tree. Read https://wiki.libreelec.tv/hardware/amlogic because the install process is different from legacy images and other distros. WiFi will probably work as the SDIO bus supports discovery. BT will not work as it's a serial UART device and the Q200 device-tree assumes a Broadcom module. Read the current LE release notes to understand the general state of Amlogic support.

The upstream Linux kernel that LE consumes pursues technical standards and this sometimes results in compatibility issues when other hardware vendors implement things poorly. Problems are often resolved, but the changes often take time because Yamaha or the TV vendor will need to accept that it has a bug and then push corrections via firmware changes. It's also possible that the upstream kernel has bugs too of course, though crowdsourced testing via general purpose distros generally spots things.

The downstream Amlogic vendor kernel that CE uses contains hacks to bend 'standards' around the shoddy implementations of other vendors. Some will claim this is a benefit because it's more likely to result in a working result for users, but the hacking can be invasive and the long-term maintainability of the codebase becomes poor. So it's all great until it doesn't work, when it becomes impossible to fix the issue for one vendor/device without breaking support for another vendor/device.

It will be hard for you to pinpoint the problem without an intermediary device (HDFury or similar) to report exactly what is being sent to the TV with and without the AVR inline.

Great playback behaviour/performance with Kodi requires kernel, ffmpeg, and Kodi patches. The kernel patches are normally a mix of things that are already on upstream mailing lists and capabilities that are still work-in-progress. Over time LE accumulated several DRM maintainers and notable contributors as project staff, and we deliberately chat with folks from Collabora and Raspberry Pi who are involved with commercial work in the DRM/V4L2 ecosystem that overlaps with our needs: LE gains from their efforts to push code upstream and they benefit from LE/Kodi being media focussed so our devs/staff are good testers.

Our goal is to have zero Kodi patches (beyond basic distro packaging) but Kodi features for RPi currently depend on some kernel and ffmpeg capabilities which are not yet upstream, e.g. until the Red Hat sponsored 'HDR' working group met earlier this year the forward path for colorimetry and some related userspace bits were blocked pending decisions on how to implement; and as the ripple effects of agreement start to unblock things we are adapting and retooling where needed.

Upstreaming FFMpeg changes is the greatest challenge and we are mostly working through JC (who maintains ffmpeg and related things for Pi foundation) but the changes are often complex, the mailing list is opinionated, and the resulting merge rate is low so there's a large patch backlog. Kodi is using FFMpeg 6.0 currently and won't need to bump to 6.1 for a while, but I understand JC has now started work on that. One of the things we do for JC is test his branch over a range of SoC devices to ensure the changes for RPi don't break support for other SoC platforms (to help with upstreaming).

So as a general rule you should be able to pick and choose the media-related kernel patches LE has for Allwinner, Amlogic, Rockchip into a common 'arm64' codebase with FFMpeg 6.0 from JC and a few Kodi changes from LE. In our own codebase we still keep things a little separate to reduce interdependencies for individual SoC platform maintainers, but there are others that we chat with who are doing that; e.g. the developers behind MiniMyth (single image for all arm/arm64 devices) and Manjaro (similar..)

https://chewitt.libreelec.tv/testing/ <= Images are based on LE12 which has newer everything including a more recent kernel. The amount of change in the Amlogic kernel is low but that also means it's low risk to use (nothing is likely to be fixed or more broken) but we remove the doubt. And I block PM because far too many users seem to think I provide a personal support service. If you see a U9-H box for sale post publicly here and I will see the post, and can follow-up offline.

Use the LE12 codebase for all testing (LE11 and before are now dead/done) and focus on hardware matters because all effort made on updating old add-ons and such is pointless unless the underlying hardware works. Ignore ChatGPT, it's clueless for this task.

NB: If anyone has a second/spare U9-H box I'd be interested in acquiring it for testing. I've attempted to pick one up on eBay a few times, but I've either been outbid on the item (which is crazy) or sellers have refused to entertain shipping the device to the UAE.

Adding "textmode" to kernel boot params in uEnv.ini will boot to a text console (no Kodi) allowing you to poke around. Kodi logs aren't going to be of any use/interest. The systemd journal/dmesg are where any clues might show up.

NB: I've no interest in LE11 codebase for a long time now, so please use the images from my test share instead.

How/where have you configured the keyboard?

Upower warnings are harmless and can be ignored. You probably need to stick with an older LE release that's more era-appropriate for 17-year old hardware.

The family daily-driver systems here are all configured for continuous debug logging .. all part of the joys of being a staff tester.

If the location of media changed the existing DB content is invalid and you will need to remove the NAS sources, add the USB drive as a new source, and rescrape; which will re-download all the thumbs and info off the internet again. Or you need to run a tool against the existing DB files to update/correct the invalid file paths (from NAS to USB) .. but if the USB only contains a subset of the content on the NAS device that isn't going to truly 'fix' anything either. TL/DR: In 99/100 cases cloning a current install "to save time and effort" causes confusion and results in more effort as you start out with a half-broken setup. Start out with a clean install, add the USB drive as a source, and let is scrape. Unless you're on dial-up 28.8k internet it'll be done fairly quickly and everything will be correctly referenced.

I never had problems .. don't go too extreme.

Update to 11.0.4 or a current 12 nightly and retest, an upstream bug was fixed that may have stopped things working.

I'd start over with a clean install and just use the Videos view to nagivate the USB stick. Keep it simple.

This forum is dedicated to LibreELEC which does not run on the nVidia shield. Ask for Android support in the Kodi forum.

The old image doesn't support the firmware and bits needed for newer "RPi4" hardware, and while that's not an impossible task to solve it's not going to help with providing a future path forwards; only the newer codebase offers that.

I'm not entirely sure where to direct attentions, but RPi4 and thus probably CM4S has different USB hardware compared to CM3 so there are probably some device-tree changes needed.