Posts by chewitt

GXM box devices normally come in three configurations with a low-end device having internal PHY ethernet and the mid/high-end device having extneral PHY ethernet. The Q201 device-tree is for internal PHY only so if that doesn't work try the Q200 which has external PHY. If neither of those work you'll need to try other GXM device-trees. TL/DR .. supporting "board" devices is simple, but "box" devices are always a lottery.

NB: If the WiFi works, SSH in and share the URL from "dmesg | paste" .. maybe we can see more.

Install NOOBS or PINN on the Pi and you have a boot time menu for selecting the OS to boot. It's not possible to control booting into the OS tho.

In theory the data is sat there on the eMMC storage and could/should be readable to make a backup *but* the data is on an EXT4 partition that cannot be read under Windows and I'm not sure 5Ninja's ever released Linux drivers/tools for mounting the storage.

An old IT saying/proverb states there are only two type of computer users: a) those who back-up their data with religious conviction, b) those who haven't lost all their data in a mishap yet" .. which is kind of true.

I shifted my DB stuff into a central MySQL DB some time ago as I'm hopping between different test devices all the time, but that's also another good way to make endpoint devices a bit more stateless.

cp /etc/connman/main.conf /storage/.config/connman_main.conf

^ edit the file and uncomment "# EnableOnlineCheck = false" and reboot. I'm not 100% certain, but I think this will prevent the error if there is no network connected.

This is only seen when services fail. If nothing fails you only see the LE version info. So fix the network-online check (connect Ethernet or allow calls to ipv4.connman.net or ipv6.connman.net) and all will be good.

As the Slice has no USB or SD Card boot and the device is not booting (or booting far enough for SSH to work) the only real option is to reinstall the OS by flashing from a PC over the USB connection.

WeTek Core is ARM (32-bit) using Linux 3.10 and Play2 is ARM64 (64-bit) using Linux 3.14 and DVB drivers are compiled using an arse-backwards process for a specific arch and kernel. TL/DR .. you cannot take the CE add-ons from their 3.14 image and use them on an LE 3.10 device.

You've tried it with a USB flirc receiver?

Two options:

a) Disable the "auto-share removable media" option in LE settings and then manually add a config section to the samba.conf for the drive/share.

b) Format the drive so the OSX parition isn't present, then we won't auto-mount it.

Flirc + "any IR remote you want to use" is always a winning combination.

cp /storage/.config/samba.conf.sample /storage/.config/samba.conf

^ edit the list of shares and reboot to effect the change

That's for Amlogic legacy kernels which we no longer develop. I'm talking about the mainline kernel codebase.

It would be best to post the Q in the Kodi forums where the scraper developers hang out.

Quote from mattlach

I've also never quite understood the difficulty in adding NVDec, considering Kodi uses FFMPEG for playback, and FFMPEG supports NVDec. But that may be a question for another thread...

In the last 2.5 years Team Kodi has been slowly and successfully driving the Linux codebase towards common standards (GBM/V4L2) and away from vendor-proprietary interfaces (VDPAU, Amcodec, iMX6, OMXplayer, etc.) so there is low interest in adding another nvidia vendor proprietary interface (NVDEC) to Kodi. It's probably not hard to do, but someone has to do it, and even if it's done it's unlikely to be accepted into the codebase.

Amlogic should auto-detect HDMI vs CVBS output and configure itself as required. I've never tested it (as I have nothing that takes composite input) but the DRM driver supports it.

The arm32 container probably works (we use 32-bit userspace on RPi4)

I've no idea what a "regular" RPi is but if you add facts like model number to the question; the Zero thru 3B+ models do not support 4K and the 4B does support it. And "no log = no problem" .. because we suck at blind guessing what user issues are.

Most of the team still regard x86_64 as the "true" Kodi experience and is still the best for GUI (due to raw CPU performance) and will be the first to properly crack HDR support. That said, ARM devices are now approx 85% of our userbase (75% is RPi of some kind) and whlie ARM means there is usually some kind of compomise somewhere, they're increasingly capable devices.