Posts by chewitt

Test installations are $free

The core OS is in awesome and super-reliable shape since we moved to mainline u-boot and modern kernels. Unfortunately the one thing we need to work well (hardware decoding) is in pissy shape .. and until there's a eureka moment on seeking/flushing support with GBM/V4L2 images aren't so usable. Raspberry Pi (also using stateful decoding) is now stuck at the same point so I'm hoping their considerably larger gene-pool of talent (Amlogic's is woefully small) will figure out something and then we'll be in better shape.

All you need(ed) to do is/was boot the LE image before trying to copy media to the drive. If the 32k partition contains /storage/.please_resize_me boot scripts detect it, remove the 32k partition, and a new one created at 100% size.

You're either unlucky with choice of discs or there's something up. Can you share the OS and Kodi logs? (cat /path/to/log | paste and share URL)

I can't find "gxm201_1g_2GB" in anyone's sources but both kszaq and CE kernels (3.14-nougat) show the same Ethernet config with Q201 devices using internal (rmii) PHY which is the same as the mainline kernel Q201 dtb. You'll need to share the "dmesg" output from the box for me to look any further into the problem. If the WiFi works you can probably get online to share logs from within the LE settings add-on (or CLI).

I'd guess they aren't deleted by the TVH client as it didn't create them and doesn't know they exist. You could ask the Kodi developers who maintain the add-on the add functionality (via the suppport thread in the Kodi forums) .. or you could create create a shell script that runs via cron to delete the files at regular intervals.

Check whether the root allows access from anything other than localhost?

Add "debugging" to boot params and the console on CTRL+ALT+F3 will exist.

I guess you're using the LE 9.0 images? .. the only thing I can suggest is installing the mainline kernel images on Index of / (AMLGX) but while stability in the core OS is overall improved on the legacy kernels they are still "work in progress" for video and the test images are best used with AMLG12 hardware where the devices have enough grunt to disable hardware decoding and still have good 1080p (not 4k) playback.

Most NUC devices are technically capable of playing software decoded Netflix streams in 1080p (and in the past this was possible) but in the last year or so Netflix has implemented DRM changes that restrict Kodi (on Linux) to the SD versions of their content. Feel free to show Netflix DRM the middle-finger and use another service.

honentan You can either a) provide the information that I asked for (the device-tree filename you are using), or b) provide unrequested info about a Bluetooth node that is present in 99% of Amlogic legacy device-trees that has nothing to do with Ethernet. It's entirely your call what you share (free speech and all that) but only one of the two results in me taking any further interest in the problem.

NB: In legacy Amlogic devices 99.99% use a broadcom chip so we can use upstream and well supported brcmfmac WiFi and brcm BT drivers instead of the out-of-tree hackfest known as "dhd" that provides WiFi/BT in the legacy kernels. The mainline kernel does not use any of the drivers from legacy 3.14/4.9 kernels (which is a good thing).

NB: Kodi reports the wrong free-RAM size but this is cosmetic in Kodi and the OS is capable of using more. It's been corrected in Kodi master.

There is zero interest to add the bloat from perl to the OS, but I'm sure there are Docker options for doing that.

I haven't got a clue about that stuff.. sorry.

On a PC there are underlying code mechanisms to verify and play BR media and Kodi will leverage those frameworks. There is no equivalent on Linux (there are no Legal or certified players for Linux) hence libaacs exists and attempts to plug the gap. Unlike Windows where everything just works, libaacs depends on someone making the effort to dump the keys for a disc and submitting them to the database

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.

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?