Posts by chewitt

The persistent folder is /storage/.kodi/userdata/ which is combined with /usr/share/kodi/userdata in the read-only SYSTEM file

Perhaps schedule a systemd service to run the command after the network is up and before Kodi starts?

Link from the add-on issues tracker (which doesn't look that active): https://github.com/fayer3/plugin.video.zappntv/issues

It's not clear what release you are trying to install or what device-tree file you are using, and LE/CE vendor kernel images and LE upstream kernel images have completely different boot arrangements.

The issue is likely to be something with either wifi drivers or wpa_supplicant. Experiment with an LE11 nightly as we now use iwd instead of wpa_supplicant. Any change? NB: Reporting isses with no system logs means we have nothing to investigate from.

Hard to comment as I'm no particular expert on RK hardware. Ping knaerzche ^

ekerose There's no need to force SSH from uEnv.ini but that shouldn't affect anything. Perhaps ensure you can connect before you change the password first. Also check you didn't enable key-only auth in settings as it will still prompt for a password if enabled; but you can only auth with a key so the password (even if correct) will always fail. Users are sometimes confused by that setting/config.

In terms of video issues it's hard to comment without seeing exactly what you're trying to play, which needs a full Kodi debug log.

Quote from Schaagi

Is there any option that allows faster operation even if the NAS is off?

No. Kodi wants to access sources on startup, so you will always wait for the NAS to spin up .. unless you leave it on.

search works here

Run "dmesg | paste" and share the URL so we can see the full boot log. Also, ensure you are using the rk3399-nanopi-neo4.dtb device tree which should be in /usr/share/bootloader on the current image; do "mount -o remount,rw /flash" to make /flash writeable and copy the dtb file and edit extlinux.conf to use it not the M4 device tree.

Is LE or the head-unit the playback device? (where is media read, what is controlling playback) .. What's the OS/capabilities of the (factory, aftermarket?) head unit in the car?

Having started on the path of "bad storage" I'not sure it's a correct diagnosis. LE packages the userspace side of the OS into a single squashfs file (SYSTEM) which is decompressed into a virtual (read-only) filesystem in memory. This means that to successfully decompress the SYSTEM file we have to read all the data for SYSTEM from boot media. If there are bad blocks the decompression of SYSTEM and boot fails; LE is not the same as a conventional distro where a bad block impacts only the specific file(s) written on the bad block.

NB: As we decompress SYSTEM into RAM on systems with >=1GB RAM, you can get similar effects to bad boot media with bad RAM.

It's not clear what kind of hardware you're using, but I would deliberately unplug the SSD and boot from an LE image on SD/USB media to rule out RAM or boot media issues. Also, boot logs (dmesg) would be informative.

I'd guess the boot media (SD card?) has bad sectors and that file can no longer be read, which breaks Kodi. Or the filesystem got messed up, but that will normally be fixed automagically on boot, so an underlying storage issue is far more likely. SD/USB media doesn't last forever and even HDD/SSD die eventually. My $0.02 is to backup essential data while you still can.

Create /storage/.config/firmware/brcm and put the firmware files from the DietPi image in the folder and reboot; they will be overlaid onto the /usr/lib/firmware/brcm location and used instead of the embedded files. If that fixes things, great. If not, I would try repeating things with an LE11 nightly image which has newer kernel and drivers (Linux 6.0) to see if that changes anything.

Kodi supports upgrades but not downgrades. If you are very familiar with key files/folders and where things are, and there are still older DB files around it's not hard to move add-ons out of the way (the thing that causes most issues) .. but it's not guaranteed. If you're not so familiar with things you're generally better off doing a backup, clean install, then selective restore of essential things from the backup.

You may want to experiment with the RPi removed from the case. We see lots of random weird bug reprots from Argon One users caused by bad connectors and such. And yes it might have worked fine in the past, but.. that's not always a relevant observation.

laurent734 LE probably needs to use ConnMan with the built-in DNS proxy to avoid DNS leaks at source; but we deliberately don't use the DNS proxy because it means Kodi GUI (correctly) shows 127.0.0.1 as the system DNS server and then we drown in annoyiing user support posts that point fingers at "networking is broken, it shows 127.0.0.1 not my real DNS server" posts from users. The workaround is to force traffic using iptables (read a few posts above).