Posts by buzzmarshall

    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.

    i could be wrong but was under the impression that is the same as the xaomi unit and had some weird app that you could fish the bindings out to get working but under android the app controlled it... I looked at a couple of them for a local dealer last year as they came with some millet tv box he got off bangbad but wanted to work on a bunch of oem boxes he bought from ENY. It seemed to be some kinda propriatary link that i never bothered wasting that much time on...

    try googling Openhab Xiaomi Mi IO Binding as i seemed to recall someone mentioning something about being able to pull the bindings from the Android app that it ran thru.

    i maybe wrong but it sure looks like one of the the xamomi remotes tho...

    Ya that is true for sure. Under the circumstances tho i think its good that the python3 push is happened concurrently with LE and the others efforts in moving up to mainstream tho rather then having them consecutively and to be honest am glad to see the move, I quess now it will up to the add-on devs to start looking into moving forward in their respective projects as well as things move forward.

    but your right it may be bloody for a bit.

    For the sake of cheapness there is nothing wrong with the S912's other then the typical lack of support for some of the boxes hardware features when running under Linux (LE). It just means more things need to be done in software. I have good 4k tv's in the house and typically stream most incoming stuff in 1080 without any issues, as well i have a huge storage network which everyone in the house streams local content from and even some of the 4k stuff still works good enough for our use. I would suggest tho whatever you buy try and get at least 2g of ddr.

    Some of the newer x3 boxes like the A95x3-f3 because of the newer mt7668 chipset have no wifi-bluetooth in LE or any of the other current forks at this time. The other ones you mention you might need to do a bit of checking to see if they are in the same boat as i seem to remember some of the Tanix boxes were using a old no longer support wifi chipset. I quess you would need to figure which exact box your looking at and then just check and see if theres anyone bulding for them and what issues if any people were having with them.

    clarkss12...

    I did mess with one that one of our group guys got back in Dec and eventually got a modded LE 9.2 build using the generic project mostly working, but to be honest it was a big waste of time as the guy that owned it had nothing but trouble with the device pretty much right outta the box... Windows 10 kept crashing and the box ran hot which i suspect was at least partly to blame why Winblows was really buggy and locked up and crashed a lot.

    He got the unit because we've been looking around for awhile for a SoC without the typical Arm GPU and the Intel was appealing and we figured we'd loose winblows anyways as really we were just looking for a better board for Linux and LE.

    After some tinkering I got LE working by 1st making a full linux distro run on a modded kernel on the box, we used the kernel tweak learned from that to tweak LE's kernel and got it working...

    Thru all of this tho the box still had heat issues and kept crashing so we stopped and he tried returning or getting it swapped out but ran up against a wall with Customer Service as they didn't like the idea of messing it with.

    In my normal job I do a lot of mb repairs on Macbooks and a variety of other low level boards as i do reworking and repair as well as design and consult on custom boards and I've seen a lot of poorly made crap over the years and the board in his box was manufactured poorly with things not down and poorly oriented before going thru the oven. The sad part is its not the 1st time i have seen that kinda poor quality come out from Beelink before. Its just disappointing to see a supposed Premium maker as they claim produce bad boards in the same manner you would expect from some knock off clone shop charging half the price, I did consider pulling the chip and reballing it but for the time investment it was not worth it, but i am sure that will be the last Beelink product he buys.

    Anyway...To your point.. If your up to building LE git sources you should be able to build the Generic project and work out from there as i am not sure if anyone else has really gone down this rabbit hole yet...

    Tigro... Sorry don't mean to hijack your thread so i will shut now... Chewitt and Da Flex i think have probably helped so i need no say anymore.

    Not that its really any of my business but still i will throw it out there as a lot of people looking for the easy way end up with things that they may not understand what its capable of doing or being used for..

    Indigo is something you may want to rethink as it can cause issues...

    Not looking to open a discussion on the topic as its probably taboo here (for good reasons). just thought i would advise caution in regards to it... as there are safer methods to accomplish what it does...

    Sorry if i am out of bounds saying so...