Posts by chewitt

AP6352S is a Broadcom BCM4356 device. It's hard to gauge what state support for that chipset is like on the 3.14 kernel but an educated guess is that it's using an older and mildly buggy hacked-into-kernel driver and outdated firmware. There isn't much we can do about that on the current codebase and it's not currently possible to run Kodi with newer kernels that probably improve things on S912 hardware (no Linux drivers for the Mali T820 chip). It's not the answer you'll want, but the best way forwards is using a cheap "proper router" as an Ethernet bridge.

Several LE staff have R1's and I have fuzzy memory of team chat discussing an unofficial firmware for the R1 boxes which addresses a bunch of issues with the official one. I think this is the source (from one of the TVH devs): GitHub - perexg/satip-axe: A custom firmware with minisatip for Inverto IDL-400s/Grundig GSS.BOX/Telestar Digibit R1 but Google for satip-axe and Digitbit R1 and you'll find more info on what it solves.

AVL6111 is an Availink chip. It's also used as the generic DVB device in the kernel device-tree to trigger driver module loading for a much wider range of DVB chips that usually includes other Availink chips (AVL6862 and AVL6872 are common) and tuners from several manufacturers; so most boxes that claim to have an AVL6111 actually have something else. All part of the fun trying to support Android crap.

There is proper Linux support for Mali utgard chips (M400/M450) so S905/D/L/X/W etc. are supported in current Alpha releases.

RK3229 has no Linux support from RK (see http://opensource.rock-chips.com/wiki_main_page) so there will be no LE images

No further support will be provided while you have piracy repo's installed.

Current S912 support depends on a hack using libhybris to work around the lack of Linux libmali blobs that is not acceptable to LE/Kodi staff for official releases; hence there are none (only community efforts). We are assisting and encouraging open-source alternatives to libmali that may allow us to start officially supporting S912 hardware in the future.

what wifi channels is the router using?

What wifi chipset is in the box? (and which driver is being used)

LE releases do not currently overwrite the factory u-boot installed on your device, so if your hardware is wired to support power-on events from the RCU waking the device this will remain working when you install LE. If the hardware does not support RCU wake events no amount of fiddling with u-boot will make it work. If you erased a working factory u-boot for some reason, the easiest solution is restoring the Android ROM/image, then reinstalling LE.

1GB is too small as you only have 512MB for /storage which is where the update file (.tar) and decompressed update files + Kodi data need to coexist at some point for the update to work. 4GB is a sensible minimum, 8GB or 16GB are better sizes to use. 1GB cards will be older and dog slow to use too.

No debug log = No problem

If you want to fiddle with the contents of /etc/fstab you're trying to locally mount remote NFS shares. Look at the sample systemd .mount scripts in /storage/.config/system.d for the correct way to handle mounts in LE.

It all depends on how the UPS signals the Pi to shut-down. If it's toggling GPIO pins or communicating via the network there's a dozen ways to do things and LE has all the Python libs that you'd likely want to use packaged into an addon.

Technically it would be a Kodi problem, but if you want things to scrape reliably you need to use "normal" folder/file names.

Create local filesystem mounts for the remote SMB/NFS shares; then both Kodi and MiniDLNA are using the same sources (independently.. no interaction between the apps). Look at the systemd .mount examples in /storage/.config/systemd

The ssh boot param still works. If set you cannot disable/enable the SSH service in LE settings. Note that if you want to use USB for /storage the USB needs to be correctly partitioned with EXT4 or another supported *Linux* filesystem. If it's FAT or NTFS the filesystem doesn't support unix permissions and contents of /storage default to 777 which means the SSH private key in /storage/.ssh isn't secured (it's world readable) and the SSH daemon will preventatively refuse to start.

Use pastebin.com or something similar. We prefer not to have log files in the forum and some staff (self included) will automatically ignore text files that are uploaded.