Is anyone else seeing this?
Everyone running an LE13 image since https://github.com/xbmc/xbmc/pull/24899 was merged (10 months ago) sees the same. The timezone is now configured in the LE settings add-on. LE is/was kind of the 'odd one out' among Kodi platforms as the sole UI for the OS is Kodi itself. For e.g. Android, Windows macOS, and desktop Linux timezone is already configured separately in the OS.
docker run --name homepage \
-e PUID=1000 \
-e PGID=1000 \
-p 3000:3000 \
-v /storage/homepage/config:/app/config \ <= DEFINE WHERE /app/config SHOULD BE
-v /var/run/docker.sock:/var/run/docker.sock:ro \
--restart unless-stopped \
ghcr.io/gethomepage/homepage:latestAssuming I guessed the container right? (https://github.com/gethomepage/homepage) the docker run command ^ needs to define where the config location resides and this needs to be somewhere under /storage not /docker/homepage/path/to/config which doesn't exist and can't be created since almost all of the root filesystem is read-only.
NB: config.txt file is an RPi thing, but it's used for setting boot-time hardware parameters so wouldn't be of any use for this task.
Revert is merged.
2GB runs fine for a simple playback client device. If you want to run a load of container/server services in the background then 4GB or perhaps 8GB will be more suitable.
Either is fine.
No progress due to other priorities over the last week. Read: https://wiki.libreelec.tv/hardware/amlogic#install2internal
NFS shares will require you to compile a custom LE image that includes an NFS server (and we don't have a package for that in our buildsystem). LE is not a NAS distro, and we intentionally only support basic Samba shares.
One possible source of speed differences is the change from NTFS-3G (LE11) to in-kernel NTFS drivers (LE12) but in theory that should make things faster not slower. It's possible to install NTFS-3G drivers as an add-on from the LE repo and override the in-kernel driver to make a comparison.
I've been running LE13 images for the last 11 months on the family RPi5 daily-driver. The images are stable.
Windows is sometimes a bit crap with USB sticks formatted with multiple partitions. Use the "Tools" image under "Select Version" to download an image/file which will nuke the existing partitions so none exist. Once the device is blank/wiped you should be able to select the image you want and write it to the USB.
SBC is now recognized as the Sweet Potato- nice. However, USB doesn't work at all; no USB device work once Kodi starts.
The only issue I see in the log is something to do with spi-nor flash, but I've no idea what that could be. The description above sounds a bit like an inadequate PSU problem. There's no software interaction between Kodi and USB, but starting Kodi will require the GPU and HDMI bits to do something, which increases power draw, which might result in bad behaviour if the PSU is weak. What's the spec of the PSU?
RPi4 is great but the speed difference between RPi4 and RPi5 is noticeable (once you compare them you won't want an RPi4). Sell the pile of old stuff on eBay to fund an RPi5 + NVME HAT.
Bad curl update, it's already been reverted.
Please put Kodi debug mode, reboot so we capture a clean log, then play Jellyfish 10-bit HEVC test media (not pirated files), then pastebin the entire log (not snippets) with "pastekodi" and share the URL generated so we can understand the host more.
Also share the full debug log from the Arch box too, assuming it's also using a current/recent version of Kodi. Info on the graphics stack there (versions etc.) would be interesting.
It's probably an issue with a change the curl package. It's already been reverted so you can roll back to an earlier nightly or wait until tonights images are built and published.
It's unlikely that Avahi services have anything to do with a crash triggered by plaback of streams from an IPTV source.
Start with an update to a current LE13 nightly so you're using something under active development. Any change?
[ 0.000000] Machine model: Libre Computer AML-S905X-CCThat ^ confirms you are booting the wrong device-tree file. Just edit extlinux.conf to use meson-gxl-s905x-libretech-cc-v2.dtb and reboot. Working now?
Update to the AMLGX image from https://chewitt.libreelec.tv/testing/ as this contains 6.13 kernel and minor fixes. Please also ensure that extlinux.conf is edited to use meson-gxl-s905x-libretech-cc-v2.dtb as the current lepotato image defaults to meson-gxl-s905x-libretech-cc.dtb which is similar enough that the board will boot, but does contain some differences. As you commited the sin of providing a log snippet (always provide a full log) I wasn't able to see what device-tree was being used.
Assuming it's not something simple like using the wrong device-tree? .. create /storage/.config/autostart.sh with the content below and it will dump the systemd journal to disk 2 mins after booting:
(
sleep 240
journalctl -b 0 --no-pager > /storage/journal.log
cp /storage/.kodi/temp/kodi.log > /storage/kodi.log
)&You can then reboot and SSH in while things still work to run cat /storage/*.log | paste and share the URLs generated.