Posts by chewitt

The main user-experience issue is that Linux has no "fsck.ntfs" equivalent to the "fsck.ext4" tool, so when errors occur the OS has no way to self-recover and continue. Similar issues occur with EXT4 filesystems, but we check the filesystem before mounting during boot and fsck if necessary, which clears dirty flags in most scenarios and allows a dirty drive to be mounted read-write.

The workaround might be to self-compile an LE image that disables the in-kernel NTFS3 driver and revert to NTFS-3G, which should give the same experience as older releases. We aren't interested to do that in official releases because we are keen to keep moving forwards and continue supporting in-kernel driver development. The number of user issues here is overall quite low - despite the impacts users often being rather vocal.

You need to set SMB min/max to v1 as the default connection is v2. If you configure SMB min v1 and max v3 it continues to connect at v2 which is not supported.

Quote from Reddog

unless I'm missing something glaringly obvious

The most likely explanation is a difference in the performance of the SD cards. I'm using an NVME drive on the RPi5 and it's 25-30 seconds from typing "reboot" to looking at an updated Kodi home screen.

In recent releases LE changed from using the long-proven but rather slow "NTFS-3G" drivers which run under FUSE/userspace (hence the slowness) to newer and much faster (but less proven) in-kernel drivers. Hence there are some scenarios with "old releases didn't flag problems, newer ones do" as the drivers being used are completely different. The in-kernel ones are maturing without any major issues, but some users see problems with the filesystem of removable USB devices being marked dirty. There are no "fsck" drivers for NTFS filesystems so "fixing" that generally needs the drive to be reconnected to Windows. One of the major differences between Windows and Linux is that Windows will keep trying at all costs to mount a broken filesystem and make it accessible to the user, wheras Linux bails at the first sign of an issue and either refuses to mount the filesystem, or will force read-only mounting to prevent further damage.

I didn't read the log file any further than the banned add-ons. It's probably a self-inflicted problem:

Official:Forum rules/Banned add-ons - Official Kodi Wiki

No support in this forum (as per forum rules you clearly didn't read).

Quote from Phil2011

The main issue though is at 4K in RGB the display loses sync constantly

That sounds like a textbook case of not using 4K60 "certified" cables. Resulting in insufficient bandwidth and sync problems.

I use subs a moderate amount (Mrs H is not a native English speaker) but I don't recall any struggling with files on RPi4 or RPi5.

Up to you on what version you use, but LE12 has quite a few improvements for RPi4/5 hardware over LE 9.2.8. It's hard to guess at what "weird resolution" means so better to share a Kodi debug log.

Use the latest nightly https://test.libreelec.tv/12.0/RPi/RPi5/…-0803b93.img.gz as it has mesa changes necessary for the RPi5 2GB model (which was released shortly after 12.0.1 shipped).

I've picked the change and will send it upstream alongside the next batch of changes for Amlogic images. It should be in LE13.

I'd use the RPi5 as the main device as it's a nice bump on the RPi4, and recycle the RPi4 as the Tvheadend server (as RPi3 is working with pihole and doesn't need speed). No idea on what USB tuner(s) device to use though, as not a UK resident.

I'm running an NVME drive on my own RPi5 and the speed difference over a fast SD card is not some "oh wow, that's so amazingly fast" gain, it's a more marginal improvement. The difference between gen2 and gen3 speeds is even more marginal and if you are perceiving there's a difference I'd argue it's more placebo effect than something you can see/feel in the user experience. If you do want to test things, iPerf can be installed from one of the tools add-ons.

This is the custom /storage/.config/xorg.conf that I used to use with a GT520M: https://chewitt.libreelec.tv/xorg.chewitt

The main point is "NoEdidModes" to ignore what the TV reports over HDMI and then hardcode the modelines. The original reason for doing this is to increase the accuracy of the fractional rates (23.976, 29.97, 59.94) as Xorg default calculates to 2x decimal places and this results in occasional skipping, and increasing this to 4x decimal places with fractional rates improves modeline accuracy. It will not eliminate skipping, but it will happen less frequently - to a level where it's rarely noticeable.

The modelines in that file are based on what I saw reported on that specific TV, so no guarantees they will work on your TV, but you can crib the format and experiment with likely values that you see in the systemd journal with Xorg started in debug mode.

I'd guess that you haven't forced recovery boot mode so the box is still looking for kernel.img and dtb.img files that don't exist in the AMLGX image. Read: https://wiki.libreelec.tv/hardware/amlogic

You're probably better off posting Tvheadend questions to the Tvheadend forum.

Quote from wizardly_jennings

it looks like the web site sorts ascending by default and I might/probably have been grabbing an old nightly.

I had a hunch that might have happened. If it's any consolation you're not the first sort-order victim

See if the latest LE13 nightly has support?