Posts by buzzmarshall

sorry for the late reply...

think of it like this.... in the old days most of the hardware/peripheral setup was done discretely by including and compiling things like drivers and support firmware into the kernel, which basically kept a kernel almost unique to the hardware you were compliling the kernel for... or in the cases of most linux distributions they created kernels that included everything including the kitchen sink built in to allow their linux distro to run on a wide variety of hardware platforms without having to compile a smaller tighter kernel...

Over time as linux moved forward they now use a hardware database file (device tree or dtb file) that when used with loadable kernel modules allows developers to compile their basic kernel with supported modules that can be loaded in at boot time... so the dtb is a flattened database file that contains most of the hardware setting required by the device your running on...

So the dtb or device tree file can be swapped for different devices depending on whats in that device...

In some ways its kinda like winblows does with the HAL or hardware abstraction layer as a method of dealing with different hardware in a system...

WIth modern linux kernels the idea now is for manufacturers and developers to get their hardware/software support implemented into the mainstream kernel structure that way moving forward any one using a device already implemented in the mainstream kernel can adjust their overall implementation of a linux os on their device or product simply by adjusting their Device Tree File (dtb) which gets read into ram when the device boots up allowing the device to find and make use off all the peripherals employed on the device...

Theres more to the whole mechanism but thats a simplistic way of thinking about it...

Currently that is part of what separates LE from most of the other distro's originally forked from LE...

Forks like CE and AE and others are basically working off OLD manufacturer proprietary kernels to keep their forks running, tho currentlly some are trying to migrate upward newer kernel revisions by dragging pieces of the older proprietary kernel forward and trying to implement them in the newer kernel revisions with varying degrees of success...

Still tho they are not mainstream kernels in the same manner as LE is trying to accomplish...

Anyways hopefully i have not confused you, but the idea in the end is to make things easier from one device to another by allowing the Device Tree Database Files to simply be adjusted without having to rely on a manufacturer or vendors proprietary kernel to have all the hardware properly recognized by the device...

Its the way the bootloader is being implemented now...

Even tho intially both CE and AE were simple forks of LE things have somewhat changed with LE and how its implementing the initial bootloader has changed leaving CE different and being AE is to a large extent just another fork of CE those two are not implementing the intial bootloader setup in the same manner as LE...

Actually now that i managed to lay my hands on a H2 and build some of the distributions like LE and CE I must say its a pretty impressive little SBC and extremely flexible when it comes to peripherals and memory...

Anyone looking to get out from under the typical Arm gpu issues that currently plague pretty much all of the current Amlogic/Rockchip and other Arm SoC's the H2 is a serious device to look at...

Running emu's and kodi on linux on the H2 really flies and theres nothing that i can see even coming close to touching it currently...

Its just a bit of a pain to get still but well worth the wait if your willing to hold off for a bit till the distro chains get filled with units...

Boxes are just old so i don't really bother playing with them anymore, but i did update one to Kodi 18.4 on the weekend for a friend and then remembered what i had done to make them still usable...

If the box is a Maticom box then its their bootloader that is more then likely causing the issue, tho some did have crappy nands that were known to go bad but in most cases i have come across it was Matricom's crappy bootloader that would easily corrupt when messing with it and the video setup in it was for older resolutions which some screens don't pickup till the main firmware comes up (Android)...

I forgot that i had replaced their bootloader with my own along time ago which is why i was able to keep the system updated to begin with...

Couple of things to think about...

If your looking at staying within the Android box market and NOT a sbc then i would say i am not sure whats really out there cheap enough with 4 gb or ram that really has real stable firmware when looking outside of the normal installed Android that comes on the box.

If you specifically want LE and want to stay within the Amlogic realm then you will need to wait for awhile (as LE is in the middle of trying to migrate parts of their core up to the mainstream (linux) which has lead to them not really supporting Amlogic in their current development tree while this process is going on...

With that said tho... if your able to handle building their sources on your own theres no reason their current build can't be patched up to build a Amlogic using the newest Kodi (Leia) and on one of the older none 5 kernels... Its just not something i think any of the LE guys are going to do so you''ll be on your own... I know i have done it multiple times and i know others that are still doing it for their own purposes...

If you want LE without the hassle of building yourself then you probably need to look around here at NON Amlogic boxes to see whats available,,, Rockchip, Allwinner or Rasp maybe able to give you what you want...

Things are pretty fluid these days as people try and fix or find solutions to the GPU issues which currently plague the Amlogic and Rockchip SoC's when it comes to hardware acceleration to any Non-Android OS running on ANY of those boxes and there is no way of predicting if or when those issues will all be solved at this time...

If your trying to get out from under those conditions then you need to look at other things like the H2 which is a SBC or some other Intel based device thats not prone to the GPU issues...

In some ways depending on what you want to do it may be better to just stick with a older box that actually has Leia support that works for the time being till things...

Finally as others have said there are LE alternatives, but to be honest they aren't perfect either and if your a plug-and play type of person they can be troublesome as well...

It kinda comes down to how much playing around you want to do...

The shield is ok and pretty stable for what you get but the downside is its not really all that open to development...

Probably the best bang for your bucks would be a 4 gig N2 or RockPro64 sbc board as they are pretty flexible but the downside with both of them is they are still heavily under development when it comes to the hardware side of the GPU stack... Things are getting better with both but i would suggest to do a bit of reading on both before deciding which way to go as one is Amlogic driven while the other is Rockchip and depending on what your intent is the teeter-totter is not perfectly balanced...

As well theres the Raspberry 4 (i can't say much about as i don't own one). the same goes for the Allwinner driven devices...

The other option would be to look at something like the H2 which would get you out from lack of GPU hardware support issues found on both the Amlogic and Rockchip devices as the board is Intel based (more like a regular PC), but again its new and still being developed...

With the AE builds you may have to try a different more suitable to S802 file as the compiled in wifi maybe different....

The S812 and S802 are close in most ways but the wifi chipsets maybe different between them and even board revisions within the same SoC not always had the same chipsets...

You could try using a different dtb from within the same build with the file that your trying and see if that helps...

That is assuming your using the X8H and not the X8H-plus.... ( the plus is S812)....

Not sure your going to find a current regular LE anymore as that box if i remember right is a older S905 box and current Amlogic's not really supported in LE these days...

but with that said there should be some other builds around that work on the older S905's... You may have to look for a alternative build that has got the current Leia version of kodi in it and play around with the dtb files of that build to find the right one that works with it... I don't have any of that particular device but have a bunch of older original Netbox A95x which was the S905 (not the x) and compiled LE to run on them aways back and have seen builds by other developers make builds for other boxes with the same SoC.. you may just have to look around a bit.

with the limited info you've provided i would say this...

If your just trying to update Kodi on Android then you need to just find the newest Android version of Kodi and do it within Android like a normal app...

If your talking about the version of Kodi within LE then you will need to find the newest version of LE for your particular box and go from there...

Keep in mind the with Os's like LE the version of Kodi is integral to LE so to update kodi itself requires the whole OS to be upgraded...

Assuming your talking about using Kodi from LE then you'll need to know what box your using and start looking around here for the appropriate version of LE for you box...

I am not sure if this will help but there is another build called EmuELEC that is built from CE sources only without Kodi as its a games type of build and i am pretty sure that in his Amlogic-ng project he has incorporated qt-everywhere version 5.13... I know the buiild works because i have built both the Amlogic and Amlogic-ng and tested them on devices because his Emu's in it are some of the best working ones i have come across this year so far...

Just pointing that out as its a working example i know of that has no kodi in the build and is using QT-Everywhere... Its done by shantigilbert...

Quote from totalgaara

I come back with some bad news unfortunatly.

Video playback in youtube as ElBoluTony say work fine, like youtube.

The reason why we can"t play 1080p (and 720p, it's not pleasant...) is because the Netflix addons and the Amazon prime video extension use the CPU to "decrypt" windevine DRM protected content.

Our rock64 has only L3 Windevine, while we need L1. So that L1 is "emulated" and use a lot of CPU ressources, because the GPU is in this case : totally useless , that's why the playback is not good, Rock64 is not powerfull enough...

Don't know what we can do more, i love that device, but seriously i start to hate it, we can do nothing on it... Android TV, you can dream to use netflix or amazon prime video app, even if it was, it will be SD video playing because of L1 DRM

Unfortunatly on lLibrelec, we have a chance but the L1 emulation use too much power, don't know if it fixable

Display More

Well thats not exactly true.... Discussing hacking of DRM's i don't think is something allowed here but anyone that truly understands Arm's Tee and enough about emulating decrypt/decode routines would disagree with you... its more about no one wanting to take on the issues of messing with DRM protection out in the public domain...

i think part of the problem is small variations in the values that effect memory timing as there are now so many people playing with kernel/dtb settings that in some cases what works good for one is a problematic for others... theres still a lot of testing being done as some trying and migrate the kernels to mainstream and settle things out...

Personally i have 3 of the Pine boards and RockPros and each one of them act a bit different and it took along time to get the kernels and learning routines for the memory time down to the point that all the boards work pretty much the same... what i found weird was that all of my N2's are not prone to this same type of tempermental pickyness... not sure if its just in how RockChip implemented their vcc/timing for all the memory busses or if its something else... Don't get me wrong tho as i am picking on Rockchip tho as to be honest i actually prefer it to any of the Amlogic driven stuff, just a observation on my part as i spent a considerable amount of time building IDE's for both platforms as I use both platforms for control boards for other projects not simply just as media players...

Kodi on Android will always be inferior to Kodi on *unix but until full open source gpu stack for *unix is finished and out in the open, Android is still the only real avenue for acceleration using its blobs... Outside of the public realm there are private fixes but they still require custom blobs that are created by the ones creating the fixes... at least those blobs are working on current 5.3 kernels, meaning your not being held back by depending on blobs tied to the version of Android...

I agree with what vpeter says.... i know when i added/played around with QT i added it the same way using OEM and calling it to be included ain the build from the Projects option file by adding it from there...

I know both CE and LE have made changes to their build scripts since i did that a year or two ago but i think it should still work as i always use OEM when messing around... its either that or put it into a /packages directory within the Project file and call it from the options file...

hm... i am not sure anyone is producing their distributions like that anymore... the old way basically used the existing Androids recovery setup to take the older OE or LE update.zip file which then installed to internal flash... that update zip used to be produced by using the make amlpkg command when building the firmware which i don't think is functional in any of the current build versions from any developer that i have seen for quite awhile now...

Still tho there is no reason why you can't make a sd or usb stick that would flash directly to the box if that is what your intention is...

I think most of the developments i have seen take the position of creating a bootable system using LE or CE or whatever and then allow you to move it to internal once the user knows the system is working ok...

I never retain Android on any boxes as i install my own system so i may be off somewhat in my assumptions as i don't use LE or CE other then to keep up on both their respective toolchain/build setup just out of curiosity...

I have my own tool for building bootloaders for all of the known boxes which i keep on a sd card with my OS and then install directly to internal on the box, so i am doing things a bit different then current LE or CE...

cool.... i am glad you got that sorted out and at least got something working...

What you've got can be made to work on the newest stuff but unfortunately the older setup (like what you used) is not really the way anyone developing releases their packages anymore... if you noticed on the zip you used for the older stuff you can see the matched android recovery bin file that allowed the older openelec to install and being libreelec is really just a newer evolved version of OE making the switch from OE to LE works... Unfortunately it leaves you stuck at older 17,6 kodi which is starting to get a bit dated these days...

Most newer releases these days are using scripts to patch the existing box's bootloader and open up a lot more flexibility and even tho it can be made to work on most newer boxes can sometimes be a pain to make work on some of the older (S8xx) boxes and can lead one to having to put in a lot more time trying to find the magic combination for the particular box...

I am glad to see you at least got something going tho...

The method still works but unless your capable of producing the files in that required format i don't think you will find much of anything at current revisions using that method anymore as for public support most developers have moved up to the current method which is allowing alternative external boots and then migrating that to internal via the various install to internal scripts floating around...

What your asking about was more or less using the original boxes android's version of recovery and its update function back in the old days prior to the newer methods being currently used being known about out in the public...

I don't think you will find support for much of anything to do with acestream on this forum as it involves digital rights violations...

someone can correct me if i am wrong, but that is my understanding...

Raspberry's and some of the other discrete vendors products usually are much easier to work with as the hardware typically comes from the same source or approved sources where as the Amlogic boards have my clones and other substandard makers and distributors that really do nothing firmware wise other then pilfer code from the bigger mainstream manufacturers which makes firmware builds a lot more picky on the box your trying to mess with...

Things are better these days with the newer hardware then the older boxes but the same basics are still employed which is why come new boxes can still be touchy when it comes to making them work on anything other then the installed version of Android that is on the box when you buy it.

Deciding whether or not your trying to maintain or keep a way of restoring the original version of Android is the 1st question to answer as it can change how picky things can be... basically meaning if your willing to loose the Android off the box to run something like LE or CE then you really don't have to worry as much about the signed parts of the makers bootloader as all you actually need is a boot loader with the right device tree for the hardware your messing with... where as if trying to maintain the boxes Android ability's mean that whatever you do you need to make sure to retain the properly signed and matched parts of the original makers setup or you open up a whole new world of hurt...

Over time most none Android setups have gotten better and easier, as they basically are just altering the existing firmware bootloader to look for alternate bootloaders or bootable partitions while maintaining the matched signed parts intact allowing the original bootloader to be properly signed to load Android when you want... Even things like TWRP were created as methods of getting around the idea of having mismatched recovery bin files for the firmware your trying to load... Even with the newer hardware its still easily messed up if one totally erases the installed bootloader as the 2nd copy (backup) of the original firmwares signed parts are now gone which leads to having to find the original firmware and creating a proper boot stick or card to use something like Amlogics usb tool to try and reflash the original bootloader back into the box... Its either that or you need to setup a uart/serial debug rig to manually rebuild/repair the bootloader..

To a large extent most of the issues stem from all the clones and people destroying the original bootloaders trying things and then not being able to find the proper firmware for the box which leads to the seemingly never ending loop of hunting/trying different firmware files trying to fix things and in the case of the older boxes it kinda comes down to is it worth the time trying to fix it for hardware that is kinda getting old by the standards of today...

As well to be fare to the topic of the thread i will say that the builds here can be made to work on both S802 and S812 boxes as i have tested on both boxes awhile ago, so i know they can be made to work...