Posts by buzzmarshall

    hm... last time i looked the redbull model was a phone not one of their android tv boxes.


    Wechip ouch... talk about bottom of the line... once i bought a couple of cartons of oem boxes from them and i never made that mistake again,,,


    anyways i never heard of a tvbox from them called Redbull unless i am misunderstanding something.

    The only current way that i know of is to build a emulator to emulate the widevine functions which in the case of the 4g sram devices would probably run. The issue tho really comes down to, doing so out in the open community i highly doubt is something Google would take lightly.


    If one is good at RE stuff and proficient in using Ida Pro there is enough info via researching the Patent Offices to create a working emulator. It also helps if your familiar with how Conditional Access systems work.


    I agree with Chewitt says as in time hopefully google will release 64bit version which can be extracted and used as currently is being done. I think widevine will be around for awhile seeing as Googles a major player and companies that big tend to like to keep building on stuff they've already dumped a pile of money into.

    wowwow...


    As for the Eny M8S (n200's) for some reason Datrh's seems not to make a actual working img... It works great on all the minix devices but the older Eny's for some reason always ends up with a corrupted file system or can't find the proper partition. The compile goes ok and it produces a img but the image always comes up with the filesystem corrupt message or it can't find the partition its looking so it never expands the system on install. The wierd part is that happens when using a linux box to create the sdcard yet if you use windows and libreelecs sdcreator to create the sdcard it will get past the above mentioned errors and do the install but then it runs really unstable...


    I gave up trying to find the issue with datrh's repo on these old n200 based boxes and made some mods to his build setup and made it work and have been testing it for awhile and it seems fine.


    I just finished updating it to Leia 18.7.2 and once i am done a bit of testing if you want a copy to try, let me know and i will upload it someplace... Its intended for the original Eny M8S using the n200_2g device tree...

    No x92 devices here but i do have a bunch of Sunvell T95 U and K pro's that I use for S912 development and they work ok using the q200 based dtb's and give me all the right peripherals. Currently i am building against a slightly modded LE Master as well as Chewitts Amlogic-master and other then some issues with playback loosing its position when jumping around in the video its watchable and wifi and bluetooth both work. I am sure it will get better in time.


    A few of us decided to commit our time to hevc so the S912 and the S812's now working on mainstream kernel have taken a back seat for the time being.


    As far as what Androids on the boxes i couldn't say as i never boot Android on anything so as a Developer i am kinda off the beaten track as i work under constraints that never care about Android as i always remove it and commit Linux or LE straight to internal storage.


    I still see the S912's a totally viable device if you not really looking for a SBC and want to cheap out so once all this crossover to mainstream and moving up in python stuff gets worked out i think it will still have decent place in the market based on its falling price.

    humantoz... If you have access to a linux box you may want to try and format and partition the WD drive under Linux as i have had issues with some WD's that appear ok in Winblows but acts weird under Linux... LibreELEC is actually Linux and Windows isn't exactly the same at partition or low level.


    I know the WD's will work as i have over a dozen 4terabyte wd drives in my network but usually if i buy a used drive from someone that had it on Windows i have issues with them on my devices... Usually running Linux fdisk at cli or use gparted will partition and format getting rid of the errors.


    If you've got no Linux box just use one of the Live Distro's on a usb stick on your pc to just boot to a live non-installed version of Linux and use gparted or fdisk within that environment to repartition the drive.d


    Sounds like when hooking up the wd on a running system LE is able to find the drive and mount it ok but when booting up theres something in the WD's partitioning that LE don't like resulting in the hangs...


    Not sure if thats the issue but based on trying to use Windows formatted drives in a Linux box thats giving me greif thats were i would start...

    Thanks, what I meant was a source for the 30% speed increase for LE (as in any real comparison been done? or were does the 30% number comes from?)

    I am not sure if anyone has really done much comparing. I know i have been playing around with 64bit userland for a while and even tho it sounds good find there are still issues with some of the support packages and things that kinda make it not worth the effort at this time, but i quess i should also qualify that by it all comes down to what your wanting run as something are still locked into 32bit.


    The only thing that i can think of thats gone the 64bit way would be something like OSMC as i think i have seen others talk about it, personally tho i have never played or even tried OSMC and am repeating what others have said to me.

    I've no S805 devices so i can't speak to them, but currently do have Eny M8S (m8m2-n200) devices now working on a build modeled around LE Master running the 5.6.0-rc4 kernel but still have a few issues to fix and i am sure there are a few others working in the same area as well.


    Currently i have put that part of the project on the backburner while a couple of us are working on trying to fix up HEVC support in the v4l2 and ffmpeg sources as hardware support is a issue with all the Aml devices so it makes more sense for now to put our efforts in those areas. But i do believe support for some of the older devices has turned the corner and not that far away.

    i realize this probably is not the thread to yap about this stuff...


    but briefly i was of the same opinion till some others pointed out to me that because the Mali IP is actually common to all SoC's licensing it that because other SoC's using those IP's are going the stateless way is why i asked... i realize there is a lot of things that need to be changed to implement it but just wasn't sure..


    once again thanx for the input.

    Chewitt... thanx for that bit of info as it clears up a few things i wasn't sure about.


    As well i have been looking at Maxime Riparts work over on Bootlin and the stateless stuff they have apparently somewhat working on some of the Allwinner SoC's and Rockchip as well. So that kinda had me wondering what direction was better to look into "stateful or the newer stateless" and didn't want to go in a direction that was opposite to where everyone here is working towards.


    Dafna Hirschfeld's virtual driver setup is kinda interesting as well... anyways i digress.


    thanx, once again.

    Chewitt If you don't mind can you expand on the "changes the V4L2 stateful code path in ffmpeg needs to solve those things" statement a bit?


    Are we talking about just straightening out some bitstream path issues within the current v4l2 and ffmpeg sources or are we talking about creating a better HEVC Userland API that would expose via the V4L2 Stateful codec Api?


    Ive been researching the current v4l2 API as well as looking at some of Hans Hans Verkuil and some of the other Collabora work as well as some of what raspberry's coders have done up till now. Sorry if the terminology is off as i am trying to get a better understanding of how the pieces fit together as well as where the issues and bridges to still be crossed are.


    If the question warrants being asked someplace else please let me know and i will ask there


    thanx. buzz

    I would say HK's quality seems to have gone a bit down hill since the HC2's... I have 4 N2's pretty much since they came out and have been happy with them but when the HC2 came out i grabbed 2 for a couple of projects which i ended up having to re-flow the boards because one was DOA on arrival and the other kept rebooting once it got warmed up. The re-flows seemed to fix the issue but looking at the boards under a scope makes me wonder about the original temp profile the boards were produced with.


    As for the Khadas boards i have a pair of Vim2s and a pair of VIm3s and have had to re-flow one of the Vim2s and one of the Vim3s as well.


    Being a repair/design tech with the proper shop equipment i do a lot of board level work and am well aware of manufacturing process's and dealing with bad pcb's and mounting issues its not all that uncommon on the cheaper boards to see these types of issues as it may pertain to just a bad run of boards, which is one of the reasons i try to stagger my purchases just to see if its just a single bad run.


    Khadas with the prices they charge tho concern me as one would think at those prices QC would be good enough to prevent buggy products over poor soldier profiles from ending up many miles away in some poor end users home.


    Personally I have no ties to any manufacturer, nor am I like some others that have been gifted devices and may or may not have biased opinions, I am just relating my own personal experiences with both of these device manufactures, nothing more, nothing less.

    Not technically impossible, but also not as straightforward as you assume as Kodi has a number of dependencies and reverting Python2 > Python3 is more than a simple package bump. I have a suspicion that once you chase down everything for that .. you're basicaally back to our LE 9.2 codebase which is Python2 based.

    Part of my current messing around has been based on using LE' master branch and the AMLGX devices and creating a build based around the last Leia build and to be honest with all the regression that needs to be done i am not sure its really worth all the effort.


    I am somewhat in agreement with smp as i think it would be less work to just fix up the required plugins you want to be python3 compliant.


    Being of the never quite mentality tho still has me somewhat embedded in the idea.

    Very nice and encouraging...


    I noticed your new device in the project files yesterday and wondering what you were up to... very cool...


    Ive been following Martins stuff for a while as well while i have been trying to revive the Meson8m2 into a project i have going here that is a mix of your amlogic-master and the LE masters but have taken a break from while i learn more about the inner workings of the LE build system and the whole git thing. Being a tech guy i get the idea of the newest and neatest but still like the idea of some of the older boxes as just simple kodi boxes minus the Android crap so i am glad to see you guys messing around...


    once again... cool...

    Currently you'll find depending on the device that a few of the alternative distro's overall that operation is more stable or better because they are still based on the old proprietary kernels and source code which for the time being is still fine for a lot of users. Eventually tho those old proprietary sources will fall by the wayside as Kodi itself is more interested in moving away from that crappy code as it changes to more current api's that are better supported in the mainstream (none-proprietary) kernels looking forward to the future.


    Things are changing constantly in those directions as Matrix agenda is also the python3 jump off so there is a shorter list of working plug-ins but that is changing all the time as well...


    check the hxxp://linux-meson.com site for a rough idea of the status of which device is supporting what or checkout the irc channels where the dev's are working for info as well.


    I have been built Bables AML-ALL and his AMLGX projects as well as LE's master AMLGX projects and find that the images created for S912's seem to be a bit more stable when playing back on the LE Master AMLGX or Bables plain AMLGX then the AML-ALL build. basically the sources in those builds are really close but for some reason i find quirky little things with the AML-ALL build such as when a movie ends it hangs the box at a black screen and you need to reboot it and a few other small anomally's.


    Just to qualify things i am as well only testing with playback of locally stored media from my network boxes and am basically running at 1080p with stereo out into a 4k tv, and i am not really using much in the way of plugins other then youtube and this cbc pluging i am trying to fix up.

    Is there a particular reason to change the MAC address? Normally each device should be manufactured with a unique address anyway.

    One would think that you'd be right about that but that is not always the case.


    Every time i bring in a bunch of OEM boxes from the factory for some reason they are usually always all on the same mac address.


    I have always used a autostart script similar to what Iridium posted for years when i try and run them on my internal LAN otherwise they conflict even tho they all have different static ip's and a properly populated host file for my LAN.

    Seems kinda pushy and bold for some normal user to decide how important someone else's community is and make demands like that. Its their house and their rules so i would suggest you find a better way if its important for you to be here.


    Just my 2 cents and sorry for my blunt reply but you may want to rethink how you present yourself as this is a helpful and usually friendly environment the team try and create for everyone.