Posts by chewitt

The realtek device probes first and iwd sees this as phy0 and the internal Broadcom chip as phy1

Then I see Jun 26 09:44:20 KODI-Kitchen iwd[382]: NEW_INTERFACE failed: Too many open files in system

After this point I only see ConnMan mentioning wlan0 which has the MAC address of the Broadcom chip. The "Too many open files in system" failure is unusual and normally indicates an internal bug that results in a process leaking file handles; then at some point the OS hits the 'ulimit' value (in LE, this is 1024).

The first thing I would do is bump up to an LE13 nightly which has newer everything to see if that magically fixes some underlying issue in drivers or iwd or connman. If that doesn't fix it, then this should raise the 'open files' ulimit:

echo "ulimit -n 1000000" > /storage/.config/autostart.sh

Then reboot and see if that changes anything? (if no, share a log again).

Quote from tp3580

Has support for this adapter (RTL8192EU) been removed?

The original RTL8192EU vendor driver was dropped in LE11, but in doing that we switched over to the in-kernel RTL8XXXU driver and that remains enabled in the kernel config so LE12 'should' be the same as LE12.2 (other then the kernel being newer).

With the onboard WiFi enabled (so you can access) connect the USB WiFi stick and reboot to get a clean boot log, then SSH in and run "journalctl | paste" and share the URL here so we can see if anything interesting is logged (or not).

Quote from marnal

i have no uart so i cant tell you anything else about it.

I've added https://wiki.libreelec.tv/hardware/raspb…omposite-output to the wiki

Quote from jcjefferies

Is there something else I should be doing?

Sharing a log file?

NB: These days we are not too enthusiastic about adding patches that we can't drop in the future with a kernel bump, so if there are things in Issues/Forum threads that work (meaning, they need to be tested and confirmed first) someone needs to submit them to the linux-media mailing list. As long as there are signs that patch(es) will be merged upstream we will be happy to pick/backport the changes until some future kernel bump drops them. Firmware is more easily handled as we mostly have our own collection(s) and can add things to our own repo.

Also note that I'm unable to test any form of DVB hardware (as no DVB-T/DVB-S feeds) so I depend on being told what's needed.

#include distroconfig.txt
include distroconfig-composite.txt

Edit config.txt on the SD card and change the includes to disable distroconfig.txt and enable distroconfig-composite.txt ^

That should be the only change required.

video=HDMI-A-1:1920x1080M@60D

Append that ^ to kernel boot params in exlinux.conf and the HDMI connector will be forced to 1080p at start. That sometimes prevents the kernel from attempting some odd/unsupported mode.

As the issue is reported on multiple OS and different versions of Kodi, it's not a LibreELEC specific problem. You should continue to support the Netflix add-on (and inputstream.adaptive) devs as that's likely where either the issue or the solution lies.

Updating to the latest nightly image will remove the "systemd-userdb-load-credentials" error message.

Quote from e123enitan1

Please what could result in the failed message, does it have anything to do with my box or its LE issue?

It is harmless (nothing to do with your issue) and fixed with this: https://github.com/LibreELEC/LibreELEC.tv/pull/10506

Kodi uses a 'compromise' but safe default for software deinterlacing. It's possible (with patching) to make it use other deinterlace algorithms that ffmpeg supports, but older ARM SoC boards like S905 don't have CPU grunt for the fancier ones that give better results. The S905 hardware has a dedicated deinterlace function, but software support for that only exists in the Amlogic vendor codebase that Kodi and LE moved away from. Older LE/CE images are more feature complete.

DRMPRIME is a zero-copy rendering path (nothing to do with Amazon); meaning we read the video stream and then all processing stages through Kodi, FFMpeg, and kernel drivers; exchange a pointer to the original data in memory instead of reading it from RAM, changing it in some way, then writing back to RAM again. It's more efficient, but it's use requires the kernel hardware decode drivers which are not perfect. The only alternative is to disable hardware decode and use ffmpeg software decode. Playback start and seek on HEVC media then works great, but unless the video bitrate is extremely low you won't have enough CPU grunt to handle 1080p media. If you only need to play SD or 720p media (or have faster hardware like S922X/A311D) it's an option though.

Nobody is working on the hardware decoders for several years now, so I have no expectations of improvements coming. For some users AMLGX works good-enough. For others not-good-enough. I am not a driver developer so I'm merely keeping the status-quo until either someone appears to do work, or the hardware dies out. S905 is now a decade old so the later is more likely.

udev rules; you'll need to place a modified version of the default mount rules in /storage/.config/udev.rules.d that detects your drive and then applies different config to it, and reboot for it to be overlaid (and thus overwrite) the default file.

The upstream hardware decoders aren't perfect but much depends on the source media. Some users have collections that will fail miserably. Others will find it's surprisingly usable. You'll need to experiment with a spare SD card or eMMC module.

Quote from jsprenkle

Hello, any suggestions how to prevent corruption when the power fails?

Disabling the write cache helps. Mounting read-only helps. Using EXT4 or perhaps BTRFS (with more advanced journaling) instead of NTFS also probably helps. Using hardware RAID helps. We do not support software RAID; there are too many variants and tools and we prefer to avoid the bloat incurred. No filesystem is corruption proof so if you truly want to prevent corruption, prevent the loss of power (Yes, get a UPS).

If you all "know better" .. https://github.com/xbmc/xbmc is eagerly awaiting your contribution

You're welcome to test, but I suggest stopping Kodi and copying /storage/.kodi to /storage/.kodi-backup first so you can revert back to LE12.2 in case of any issues; Kodi does not support downgrades so upgrading to LE13 nightlies is a one-way process. It's best to pick a nightly image as I haven't built images for older boards for a while; my testing focus is on newer ones.

The ability to turn on from CEC probably requires support in (mainline) u-boot and for the device to be in a suspended state so there's some level of power to detect things on the HDMI connection. I've no idea if that's implemented or not. I'll ask the main Amlogic u-boot custodian, but an answer might take a while as I know he's currently on vacation.

Quote from thomaz

PLS, HEAD DEVS OF LIBREELEC/KODI. THINK ABOUT MY IDEA!!!

Your idea requires all media to be adapted to a different refresh rate. This requires excessive CPU resources. The idea also breaks the concept of a zero-copy video pipeline which something that Kodi has long-worked to implement because it's the most efficient way to process high-bitrate and large filesize media. In short; the idea is a load of hooey and dead in the water