<advancedsettings>
<videoscreen>
<monitor>Generic PnP Monitor #1</monitor>
</videoscreen>
</advancedsettings>^ that content goes in /storage/.kodi/userdata/advancedsettings.xml (from https://forum.kodi.tv/showthread.php?tid=363060) but I have no idea what to replace "Generic PnP Monitor #1" with. Perhaps "HDMI-A-1" or have a look in kodi.log for the m_deviceName and m_displayName values logged for audio cards as I have a hunch it'll be based on EDID data.
boot (AMLGX) from an SD card so emmc is not actively in use and write ^ that file with "emmctool w backup-wp2.img.gz" and you'll restore the factory image to the box. The backup is a raw (dd) image of mine before I first wiped it.
Ubuntu uses Grub, which will boot LE fine once you add entries for it.
Amlogic legacy images are using 64-bit (aarch64) kernels and 32-bit (arm) userspace for compatibility with 32-bit only libwidevine that's needed for Amazon, Netflix, etc. - and these days most containers are published only in x86_64 and arm64/aarch64 formats which aren't usable from 'arm' userspace. So you will need for find and pull 'arm' versions of the containers.
I'm not sure if adding "video=DP-1:1920x1080M@60" will result in DRM (and thus Kodi) preferring DP-1 output over HDMI-A-1 or will simply force that output to 1080p and not change anything. It's a cheap trick to try though.
rkershenbaum I've added a note to the wiki to highlight this point: https://wiki.libreelec.tv/configuration/wireguard
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/servicesnoggin 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?
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?