Posts by chewitt

Probably the anti-piracy measures we added to the OS blocking write from those apps.

I'll comment that 'pictures' is the bastard unloved child of Kodi features, but it should generally work. Kodi debug log please.

You are making an incorrect assumption that any conf file placed in /storage/.config overwrites the equivalent in /etc. This only works for a very limited set of files and nsswitch.conf is not one of them. Make sure Kodi has been configured with the name of your workgroup and WINS server.

Make sure "adjust display to match refresh rate" is disabled, else passthrough is disabled an everything it output in PCM with the channel configuration you've defined (default is 2.0).

If you bothered to compare githashes on the version of atvclient we package and the upstream repo you're enthusing about instead of posting all over the place, you'd discover those changes have been included for a while.

Kodi auto-detects audio properties based on the underlying alsa configuration so a card needs to have drivers/overlay enabled in the Linux kernel and cards with an S/PDIF port need to have an alsa conf to ensure correct IEC958 detection. The older Mamboberry DAC+ model appears to use the same overlay as hifiberry cards, which we've supported for a long time, but I wasn't able to find any information on their website about set-up for the LS+ card. It's normally trivial to add support for new DAC devices - but we need more details. Perhaps (as their customer) you can ask them to contact us, or follow-up on this post.

No current support and those devices are not on our radar. You'll find that anything using an Allwinner chipset isn't so popular among FOSS developers due to that companies poor documentation and software support (although that's nothing unique) and history of GPL violations. Someone was making OE builds for the older models (which I guess you found) but I'm not aware of anyone doing LE builds.

LE 7.0.3 contains the older 304.xx driver needed for prehistoric nVidia cards, but we have never released an x86 (32-bit) build, although if you know or learn your way around our build-system it's still possible to manually re-add support and create one.

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.