Posts by chewitt

Quote from frankvw

Until ntfsfix is included again with LE using a Windoze box to clear the 'dirty' bit on the NTFS partitions is your only option, I'm afraid.

The ntfsfix utility has never been shipped with LE, and I've closed the pull-request that proposed adding it because it's an incomplete tool. From a support and data integrity perspective it's better to inconvenience users by forcing them to use the right tool (chkdsk.exe on Windows) than not-quite fixing the problems a filesystem has and risking data loss.

noggin thanks for confirming. I've sent the change to the LE repo for merging.

We have noticed that "noobs" images are not being built/published correctly .. it's being looked into.

I don't know the exact mechanics, but I suspect Zomboided's add-on is tracking the execution of add-ons and enables/disables the VPN as required. In that scenario the VPN is started and all traffic is being routed down the VPN tunnel. This is a little different from your use-case where you want to route traffic for specific add-ons over a different VLAN. You could conceivably do something similar to detect the add-on and change the default route, but this results in all traffic being routed over the second VLAN. The only way you can send traffic for a specific add-on (only that add-on) over the second VLAN is to use routing rules; but as noted that will be rather challenging to maintain due to the dynamic nature of how streaming services operate.

diff --git a/packages/network/bluez/package.mk b/packages/network/bluez/package.mk
index 9170f27418..0dd5ebef4d 100644
--- a/packages/network/bluez/package.mk
+++ b/packages/network/bluez/package.mk
@@ -62,6 +62,8 @@ post_makeinstall_target() {
         -e "s|^#\[Policy\]|\[Policy\]|g" \
         -e "s|^#AutoEnable.*|AutoEnable=true|g" \
         -e "s|^#JustWorksRepairing.*|JustWorksRepairing=always|g"
+    echo "[General]" > ${INSTALL}/etc/bluetooth/input.conf
+    echo "ClassicBondedOnly=false" >> ${INSTALL}/etc/bluetooth/input.conf
 
   mkdir -p ${INSTALL}/usr/share/services
     cp -P ${PKG_DIR}/default.d/*.conf ${INSTALL}/usr/share/services

noggin https://chewitt.libreelec.tv/testing/LibreE…h64-11.80.0.tar contains ^ this patch based on information from https://github.com/bluez/bluez/issues/696 and https://github.com/bluez/bluez/is…ment-1854599254 which reads like the same issue.

Which LE release/version are you trying to install?

Have a read here: https://wiki.libreelec.tv/configuration/edid

I've used Synology NAS boxes for years. I started out with the cheaper consumer ones but switched to Intel CPU models to make future updates from e.g. 4-bay to 6-bay easier. They aren't the cheapest, but I appreciate something that has regular updates and the few times I've interacted with their support and engineering people they were good. I could easily build something myself for less, but I greatly value being able to just hit the update button and benefit from someone else's maintenance effort instead of it all being my own responsibility.

LE is designed for HTPC hardware that has a single active video output device and Kodi detects the available audio hardware ONLY on first boot so this is linked to the display device. Laptops have two output devices; the LVDS/eDP internal screen and a VGA or HDMI output to the TV. As we do not run under a Windowing system that allows you to live-switch between monitors/outputs you need to edit the kernel boot params in /flash/syslinux.cfg to add config that disables output to the internal screen.; leaving one active device (to the TV) and everything should work as normal.

Running "tail /sys/class/drm/*/status" will show you the names of the connected devices. Adding "video=LVDS-1:d" to boot params will disable the "LVDS-1" device. Change the name to suit what's on your system. Run "mount -o remount,rw /flash" to make /flash editable first. Ensure you add to boot params on the same line (not just in the same file).

If LE 11/12 work and LE 9 does not the issue is simply kernel version and lack of driver support for the hardware. Fixing that in LE 9 will either need patching the kernel to add new device IDs, or patching the kernel to backport actual drivers. In both cases this will need building a custom image and I don't see value in that when newer releases work.

LE 11/12 have no general issues playing media over an Ethernet network. If you previously added hacks for cache tweaking, remove them. If you are using WiFi, try using Ethernet. If you are using NFS, try using SMB (or vice versa). Or start with a better description of the problem than "troubling issues" and provide debug logs.

Just for testing switch the source from NFS to SMB and see if the issue repeats.

Can you link the issue?

If you add "video=HDMI-A-1:1920x1080M@60" to kernel boot params in cmdline.txt (on the same line, not just in the file) does that make any difference?

Read post #3 again.

I've reported the warnings to the repo owner: https://github.com/jwrdegoede/rtl8189ES_linux/issues/106 .. but don't hold breath.

You should be able to run the image from SD or USB cards. It still boots from eMMC, but the boot routine is modified to search for LE files on SD and then USB devices. In past testing I've found that some vendor u-boots struggle to init USB support and thus cannot find the device to boot from, but those seem to be the exception not the norm.

Quote from powerarmour

Here's a question to any fellow Pi 5 testers, are there actually any media files that a Pi 4 could play that a Pi 5 can't?

Nope. RPi5 handles more than RPi4 which handles more than RPi3; except for 3D which neither RPi4/5 support.

You have banned add-ons installed. So no support in this forum.

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

I'd use an RPi5 board. It's probably cheaper, uses less power, and not a large performance difference.