The dtb files from Amlogic legacy/vendor kernels are not compatible with the mainline kernel (there are 3-5 years of evolution between them and many different drivers) .. but if you name the specific dtb that works we can see if anything stands out.
Posts by chewitt
-
-
I'd guess that the keys for your disc are not in the DB, so it cannot be decrypted.
-
I'm wondering what in the statement "not supported" was unclear?
-
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.
-
-
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.
-
-
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.
-
-
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.
-
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.