Posts by chewitt

Compiling the plocate binary from sources and then storing it in a 'bin' directory for use should be simple (including precompiled blobs would be rejected if you ever wanted to include this in the LE binary add-on repo). The sources use the meson build system and important things like specifying a non-standard DB location at compile-time appear to be supported already. If the add-contains compiled binaries I don't think script.plocate.search is correct naming (script.* is really reserved for things that are only scripts; normally Python scripts). Something like tools.plocate would be more appropriate. There is no need to have the binary built separately from the add-on; we only do that for e.g. add-ons like "System Tools" and "Multimedia Tools" where multiple separate binaries are being packaged.

LE supports udev rules being overlaid from /storage/.config/udev.rules.d at boot time, so the add-on can run a setup (b)ash script that detects presence of a known-name .rules file and create it if missing, but as you noticed there is no "uninstall" function in add-ons so if the add-on is removed the rules file becomes orphaned. You can probably add some udev logic to check for presence of the add-on bin directory first, and if not found skip the rule so orphaned rules files do no harm. It's messy though, so:

Or you can use a systemd service to run a script that creates or updates the DB before Kodi starts. The negative: using systemd not udev means you lose the ability to trigger an update to the database when a USB drive containing media is connected. The positive: you have simple systemd packaging that aligns with how most binary add-ons are already being started/stopped and packaged for LE use (so lots of prior art in our buildsystem). IMHO most users with portable USB drives full of media will have them connected to their HTPC device before boot so the loss of the connect drive feature isn't such a big deal. NB: plocate also ships with an example systemd service so you can use that with a minor tweak (the buildsystem can patch the sources) to add a kodi.target dependency.

Honestly no idea what the issue is, and there is really nothing to configure when DHCP is used (as default) and the design of the OS (everything inside a read-only file) rather prevents users from messing with anything that's important.

If you have the backup I would soft-reset and then not-restore the backup, but untar the file to somewhere on /storage and then selectively move back the bits of Kodi config and recordings that you need. Kodi is rather simple so a simple "stop > move files around > restart" process is all you need. Move things in small chunks and if the internet dies, you narrowed the problem down.

From my perspective:

a) User shows up with 11-year old hardware

b) It's AMD hardware from that era when their driver support has always been a bit lacking

c) User tries the "Linux is complicated" excuse and shows no initiative

d) User hasn't provided the information requested

So, yes SSH requires an app installing because you're using a retarded OS called Windows that cannot do basic SSH without needing something installed. And here's a video on how to SSH into LE:

Provide the info requested please. It's not hard.

Routing works but presumably the DNS server isn't responding so resolution doesn't work and there aren't fall-back addresses that can be used. You can set IPv4 details manually to override things but that's a workaround and you need to look at the router or the details being issued via DHCP.

Reboot the router. Reboot the HTPC device?

Share the contents of the modified extlinux.conf file.

Run "amixer contents | paste" and share the URL so we can see the audio card/controls and current configuration.

It's called 'Calibration' and it still exists. You might need to enable advanced or export mode in Kodi settings (can't remember as it's been a few years since I used it). Remember that you need to calibrate each resolution/refresh combo that you will use, it doesn't auto-apply the same change to all.

Do you have a TV card? .. system logs will show tvheadend state and any errors. Look there (or share them with the build-in paste function).

I'm not going to spoon-feed changes. If you edit the files you can see the format. The only difference will be adding a share and it will use "smb://server/share" format instead of a local "file://path/to/share" entry. There's also this thing called Google and the Kodi wiki. Inexperience and/or age do not limit initiative.

smp logged the same issue here: https://github.com/xbmc/xbmc/issues/23699

The log in this thread also shows the same issue (no insights in the threads, only whinging):

Post

RE: Libreelec 11.0.3 on Nuc7i3Bnk - Graphics Problems

(Code, 242 lines)

Boronsbruder

December 22, 2023 at 6:44 AM

Does bumping ffmpeg to 6.1.1 help? .. I'm expecting 'no' but it would be good to eliminate the idea.

Can you also enable ffmpeg component logging in Kodi settings and then regenerate a 'bad' log. I'm wondering if ffmpeg will show more internal info.

BIOS updates are always a good thing but updating some ancient old laptop to be a marginally less ancient old laptop probably doesn't achieve anything.

Have you tried setting the whitelist to 1080@60 and enabling 3:2 pulldown in video settings? .. It might need advanced or expert mode enabling to see all the options.

I'd also see if things are different on a newer TV that has more display modes. This looks like an old HD-Ready set which only has one weird 1080p mode available. Or perhaps try the VGA output.

Quote from guerrero2694

There is no DTB available

That's because S905W2 chips are based on a newer Amlogic hardware generation (S4) that is not supported in the upstream Linux kernel that LE uses. Amlogic engineers started to submit support for S4 devices, but they have low experience with kernel standards so each subsystem they submit is initially full of low quality code and takes a large number of rework/resubmit iterations before it comes up to scratch and can be merged. Progress is .. slow.

CE have images that should work on the board (AFAIK) but for help with that you need to post in their forum.

Quote from deimos

I've decided to use this an a opportunity to refresh my micro soldering skills and attempt to transplant the eMMC

You need to be a whizz with a hot air gun to do that, and you need to read/write content from the chip to 'fix' things which will be a major undertaking. I'd go find/test a bunch of Android ROMs first, as the chances of success will be a lot higher.

The patch resolves a specific issue with the 16K page size in the RPi kernel. It doesn't change any of the other stupidity that is seen with NTFS devices. If the filesystem is marked dirty for any reason you still need to clear that from Windows.

If you are asked for a log - assume the request is for a debug log and for the entire log file, not just the small snippet you think is useful (often we need to see and understand the configuration too).

^ Quoting from the wiki article that you didn't read, resulting in a series of log snippets that tell us nothing.

Try again..

Quote from sam-y

LE doesn't use Grub

LE uses grub for 32-bit boot environments, which was a thing for a while when Intel "stick" devices were popular, but it's not the normal bootloader for sure.

There's a drip-feed of bindings changes and other unimportant things to DRM code; nothing of any real meaning was changed in aeons. I also have an N2+ running here for boot testing LE changes and I'd notice kernel splats (none seen).

I've moved the post into its own thread as the UART log shared shows the system boot from SD card without any errors (and thus whatever the issue is, it's not the same thing the C2 thread is about). Something goes wrong when it boots the kernel. The splat suggests something with the HDMI driver (so something in the display chain).

Can you successfully boot from an eMMC module to prove it really is SD related (which it almost certainly isn't)?

Can you successfully boot this image? https://chewitt.libreelec.tv/testing/LibreE…droid-n2.img.gz