Posts by chewitt

Your method backs-up and then restores "all the crap" from OE into the new clean LE install. There is no cleaning benefit

The add-on description in the Kodi GUI states "ProFTPd is a secure and configurable FTP server with SSL/TLS" so i'd take a wild guess that it supports FTPS, which is not SFTP, and which leads my inner security nerd to caution that the box should not be exposed to the public internet unless you know what you're doing.

There is a community add-on for FTP, which will never be added to official builds because it is not a secure protocol, unlike SFTP which has been supported in our codebase since ~2009 ish.

From the logs you've give us it looks like the correct drivers are loaded, Xorg is running, something is being output. If the result is still a black screen I have to guess it's an issue with connectors/cables or something funky about the TV itself. If I had local access to the box to experiment I could test a bit more, but remotely.. I'm out of sensible suggestions. Have you tested with it on a different TV?

I wouldn't accept this as an addition to the LE add-on repo because there is no clear active/upstream maintainer (most of the forks are dead for years) and this is not an LE specific add-on, so it should be submitted (by the creator, or an active maintainer) to the Kodi repo not ours. NB: Some of the other GitHub forks have more recent commits than the one you found, which might solve your problem.

Pulseaudio - LibreELEC

You need to (re)configure Pulseaudio to receive audio and output via alsa (not via Kodi, it all happens in the OS layer underneath). In the default configuration Kodi will only send via BT to speakers, not receive.

Yes, it's a sucky arrangement.

systemctl stop kodi.service
mv /storage/.kodi /storage/.kodi-old
systemctl start kodi.service

that gives you a "clean" Kodi instance; i.e. it resets guisettings.xml which might contain info on the old display settings. The same process can be used to revert the change if required. No guarantee this will work, but you never know.

"Add-on" packages are built for installation via a repo or local install from zip. So you need to modify the package so that it is built as a normal package (no as an add-on) and installed/embedded into the SYSTEM image.

Add it as a dependency to an existing package. There are some 'virtual' packages in packages/virtual/ that are easily used for such things.

two things:

a) cp /etc/x11/xorg-nvidia.conf /storage/.config/xorg.conf .. then edit the file so modedebug is "true" and reboot, then "cat /var/log/Xorg.0.log | paste" again so we can see debug output. There is a single GPU detected, but maybe something is wonky.

b) wget 96-nvidia.rules -O /storage/.config/udev.rules.d/96-nvdia.rules .. then reboot and see if the card prefers the older 340.xx driver instead of the 357.xx one.

Please run "lsmod | paste" and share the URL; let's see if there is more than one GPU detected. If there is and the BIOS doesn't provide options for disabling one of the cards we can blacklist modules to prevent them loading and confusing Xorg.

Pi Zero is kind of "minimal spec" for running Kodi and is not ideal for a Kodi workhorse. There are some caching improvements that should improve the GUI navigation in large lists (e.g. library views) due in LE 8.0.1 (with Kodi 17.1). From personal experience an RPi3 with a faster clock speed and more RAM is very daily-useable; although in comparison a 3.5 year old Intel/nVidia box I have is still miles better (was 4x the price of a typical RPi3 kit at the time I acquired it though). Yatse is nothing to do with LE, if that doesn't work it's not our problem

The 3.10 kernel used by the WP1 does not support many of the internal functions needed for docker support. We managed to backport missing things to enable support in the 3.14 kernel used by WP2/Hub but it wasn't simple and 3.10 would be a huge amount more work (and after the 3.14 effort nobody is volunteering). There are no plans from Amlogic (or LE staff) to bump the kernel used by MX chipset devices to anything newer, which means there are no plans to bring docker support to WP1.

It looks like everything is up and working .. run "/usr/lib/kodi/kodi-xrandr | paste" so we can see the Xorg modes available. You can also switch modes by running "xrandr --output HDMI-1 --mode 0x1be" (where 0x1be is a valid mode shortcode). You might need to see if other modes are within range of what the monitor will handle?

Code for the update back end is not public and for several reasons there are no current plans to change that. If you'd like to explain your interest in more detail we may be able to answer questions.

It's pretty unusual for devices to truly brick, but it's not impossible, and I can totally see some of the less scrupulous manufacturers using lower grade eMMC or NAND chips in their devices to save a few cents in the rush to make the cheapest box.

If installing on another machine results in something that boots .. do CTL+ALT+F3 on the "hung" screen and you should see a local console (because it hasn't hung, it's just not showing output). At the console run "cat /var/log/Xorg.0.log | paste" and "journalctl -b 0 --no-pager | paste" and share the URL's generated. You should also be able to do "ifconfig" and see the IP address and then SSH in to the box.

Pastebin a debug log so we can see the format of the media coming in .. although it sounds like it's software decoding.