Posts by buzzmarshall

just in case i made a bad assumption of your understanding, i realized i should have mentioned that the example i used was for a wired connection based on the eth0 device name i used in the script. but if your talking about a wireless connection being your issue you would need to change the script to apply the command to the wifi device which probably will be something like wlan0.

if you can get to the boxes command line via ssh just issue the ifconfig command and it will report what libreelec sees as active interfaces and you can check to make sure of the proper device name to use in the script. theres no reason you cant put 2 lines in if you want to set (spoof) the Mac Address of both devices.

Strange as that should work, I run about 6 identical boxes from the same factory i buy from and new out of the box they all have the same MAC so i use that script on each of the boxes by installing the script and then just changing the last byte of the Mac Address in the each of the boxes script and thats worked for years with no probs. To me what your describing makes me inclined to think that something further down the startup chain is setting the address... could be a plug-in of some type or some type of anonymizer or who knows but something definately adjusting it. Normally the network stack will sence the hardware's mac and use it until you some how tell it to be something else. I quess you could start by finding out what the hardware's real mac is and then once LibreELEC is up and running go look in the Info/Network panel on the LibreELEC settings addon and see what LibreELEC thinks it is. if there the same then it would appear LibreELEC is picking the network stack up ok and its something else you've got thats running and changing it.

Hard to really say without more knowing more...

As well depending on where your noticing the constantly changing address my help figure it out as well... meaning if your seeing the change happen on the box then its probably on the box but if your seeing the change further out on your network then maybe you've got something setup in your router thats spoofing the real Mac to your routers Mac for routing control or something along them lines.

you can create a file called autostart.sh and place a line with

ifconfig eth0 hw ether xx:xx:xx:xx:xx:xx

replace the xx's with your mac address you want to set the box to.

put the autostart.sh file in the config directory and on rebooting the box that should set it to what ever you want.

if you already have the autostart.sh file on the box just add the above line to the end of the file you've got.

hm... not really anything i have ever messed with but my quess would be that to support something like Miracast it would be something that the underlying operating system kodi is running on wound need to support it, which is why Android probably works. Kodi basically is just another application that runs ontop of something else as a OS that would provide the hardware implimentation layer so in the case of something like LibreELEC or any of its forks my quess would be that the basic support would have to start there and then allow a running app such as Kodi to make calls to that layer thru a plugin coded up to handle that.

I may be off base on what i have said but that would be my initial thoughts on the idea and if someone that knows more about the idea please feel free to correct me on the idea as i really have never messed with any of that. I just no basically Kodi inherits its hardware calls from the underlying OS which in this case would be what LibreELEC provides.

To stream something in the manner your suggesting means that the box would have to have a streaming daemon of some type installed and running to handle the streaming of the media source on the usb/memory stick. I am not sure thats something available with LibreELEC as normally LibreELEC is handling Kodi which is really more like the client end. Some IPTV plugins i think may be able to somewhat do so because the plugin has the server end as well as the client end code in it. Theres plugins around that do have the ability but there not something i really ever mess with so i can't comment on that stuff.

As far as recording a incoming stream and being able to save it, theres a few ways of handling that which can be by coding the plugin to retain the read ahead caches and rather then pitching the data save it by writing the data to a file. Another way could involve writing code that peels the transport stream packet wrapper off and as it does so fudge the control parameters to tell the receiving device to treat the file as a download so save it without trying to view it.

Sorry i meant to say as well:

That maybe if your playing around with dvb and satellite streams then maybe it might be something to consider but to be honest because i don't play with dvb thru this type of box others may have a better informed opinion on the subject. I do know from years of sat hacking that the dvb transport packets and how the system handles decoding (especially if theres a CA involved) may require or perform better with more Sram

Being a long time xbmc / kodi developer as well as doing a lot of embedded controller development and reverse engineering over the years what my thoughts are would be this...

Having more Sram is always a good thing and when the choice was 1 gig or 2 gig i always told people go with the 2 gig based on the facts that with Android running so much crap in the background and with Kodi evolving and requiring a bit more memory for running in that 2 gig was one way to help eliminate all the old random lockups back in the older dual core days. With the debate between 2 gig or 3 gig or even 4 gig i personally don't think its that much of a real issue anymore as 2gig is easily enough to run kodi even if it is still just another app running under Android and with things like LibreELEC should be plenty for sure. As far as bigger flash area i look at it from a cost point.

Currently I think bigger amounts of Sram and Flash are being used by the marketers as really not much more then a way of trying to keep bringing to market new products, the few actual factories all sell oem and branded products and they all know that if things sit stagnate for to long the end users start to figure out just how many different brands and models are actually all the same other then things like cases and layouts so in between things like new Android versions they are all using the bigger Sram and Flash size as a method of recreating some perceived differences trying to gain a bigger part of the buying market.

You can see what i am talking about in the box prices. i remember when the 1st 3gig and 4gig boxes came out and what the dealers wanted in a price increase for those few 1st boxes over the normal 2 gig boxes flooding the market at that time. The increase was huge when put into perspective to the real costs in both time and parts so for a short period of time the few dealers selling those boxes were doing much better in the market, now after a year or so pretty much everyone is up to the same point again. I develop and build a fair amount of embedded boards all the time and have a pretty good idea of cost and time so it was not all that hard to spot what was going on.

Some will argue bigger is better while others say its negligible at best. Personally i look at it from a money point and tell people that if your buying a box thats got bigger on it because people are currently developing new software for that box and the price is not to bad then go for it. but if your just buying a box with bigger memory because some dealer says its better i would that unless your getting it for a real good price not to bother.

Kodi runs great with 1 gig of sram on this type of hardware and if your running LibreELEC or one of its forks 2gig should easily perform well and even with rom games some methods treat the rom emulator as stand alone making Kodi release its sram till it starts back up so until things drastically change my approach is why bother.

looks like they are making some good headway and making things more usable but "full media support" i think is still aways off. from what ive been reading trying to play catch up is mainline kernel support is getting much better but theres still a quite a bit of hardware support still missing and the level of trying to reverse engineer the userspace code is still going on.

on another note: as I am gathering source code and information trying to come up to speed on the subject of getting Amlogic support into the main stream kernel i keep seeing or reading about this idea of Amlogic and Baylibre having formed some type of relationship making Baylibre responsible for Amlogics linux development and support which makes me wonder why anyone would have to reverse engineer anything as Amlogic could simply supply the required information. Even if there was a licencing problem between Amlogic and Arm over binaries and Amlogic making that availble to someone like Baylibre theres no reason why Amlogic cant release the technical specs on the SoC as that Amlogics stuff. Having the full docs and reference design materials would drastically speed up the development of open source common parts.

anyways still reading and gleaning just something that makes me wonder as i catchup

without further investigation its hard to say and probably best asked over on Kodi's site, but as far as the xbmc reference a lot of the current kodi building setup still refers to xbmc and not kode persay... usually in the build structure if they start disseminating between the terms xbmc is the call while its usually a link pointing to the kodi directory. so its maybe posible for some reason the softlink was removed someplace leaving you pointing to a xbmc reference that goes nowhere. the vacant repository unknown messages would lead me to think its something along them lines.

but as suggested its probably to ask over there as i could be off base

to be fair to LibreELEC i would not really suggest or imply that one is really better then the other as CoreELEC is basically pulled from LibreELEC and CoreELEC will merge with LibreELEC' master which they actually just did not all that long ago.

I monitor and build both systems probably every other week or so by building the Amlogic S912 and some S905x projects on a couple of different Linux boxes ranging from 15:04 up to 18:04 as i refuse to use docker or any virtual setup ( im to old and old school, lol) i do it just to see where they both are and think in most cases the differences people sometimes see is more based on what box they are using and where the development for that box or derivative sits in each of the respective systems.

RIght now at this time i would say CoreELEC is working pretty good on the boxes that i test it against and the rom/game support is working great as well, while if i was on a Rockchip or O-droid platform its easy to see from their respective github time stamps that LibreELEC is has been more active the last time i looked.

LibreELEC was started and built off the older OpenELEC to better support other boxes and forks like CoreELEC took LibreELEC and did ithe same thing as the developer was trying to support what he wanted to do and theres others that do the same thing. Its hard and extremely time consuming to try and create a build system that can work on SoC's from different manufacturers and being pretty much all the coding is being done by people giving up their free time to help others creates different forks.

"better" or "worse" are terms i try and encourage people to understand the reasons why one may be considered ahead or behind when it comes to the differences when making comparisons. Coders in some cases can take things really personal as its their time and output that the public benfits from and its easy to in some cases upset people which ends up driving people away or going private and not publishing public stuff and this sport is no different then any other and happens all the time. Kodi is a perfect example of that and anyone that has followed the xmbc/kodi scene since the beginning is aware of what i am talking about.

To be fair...LibreELEC it is by far the most overall active and the people involved are a huge part of driving this part of the sport and depending on which coders are active at any given time tends to be a bit up and down based on the wide amount of SoC's its trying to support.

As suggested its best to actually test for yourself and see what works best for yourself at any given time as things change all the time.

Not sure if i am understanding you properly but let me take a stab at it...

Heres what i found from Leia and up.

At home at any given times 8 or more different boxes running and pulling from a common database on my network storage racks which contain probably well over 3000 movies and tv shows and thousands of mp3's as well.

With Leia i found the only way i could keep all the boxs (including new boxes i add as i test) it was important to maintain the same revision of Leia on all of them at the same time. When i set the whole thing up what i did was install mysqld as a service on a NAS drive and then took the running box on my benchtop and used it to populate the server database by letting it scan my media drives, after then i just included the appropriate entry's for each box to use the networks database.

Since Leia what i have found from experience was that the only way i could keep all the boxes in sync with the main database was to make sure all the boxes had the same revision of Leia on all of them. that way they all use the 60 and 107 databases, otherwise some of them fall out of sync.

And then while developing a new build i do it on my benchtop box and isolate it to its own local database until i know the build works right at which time i will update all the other boxes to the new build and then reinstall the new build on the test box only this time repoint it to the network database and let it pull those databases back to it... Now all my machines are once again on the same database and in sync till the next new firmware cycle is once again done.

I have been building Kodi since old days what is was still xbmp and xbmc and not sure if this is a bug or not but from experience know that was the only way i can keep a bunch of boxes properly in sync and it seems to be more prevalent on Leia then it was on Krypton.

Another thing to watch for is a Kodi issue and has to do with sharing a common database on a local network... Its best to make sure all the devices sharing the database are on the same revision of Kodi.

Thanx... Its been awhile since i paid attention to whats going on and where things sit. ( lately been busy developing a new embedded cnc control and motor drives) and because of that i am looking at getting back into to kernel stuff again so i thought maybe i would take at where things sit.

Earlier when some of us moved the older 3.10 stuff up to 3.14 we had to write a bunch of our own drivers so our kernel became heavily modded and so far out of the current tree we just left it like that because it worked and I have had no reason to go back and visit it but maybe nows the time to once again go and look see. At least on those platforms I have all the tech docs and register manuals and luckly Amlogics stuff is mostly contained in the /amlogic folder so between them writing or altering things to gain the missing pieces was a posiblity. My issue would probably stem from a partial lack of some of the technical docs in the newer S9xx SoC's... i think i have the main 912 docs but am missing the register set docs. As well i am not sure if JTAG is possible on the newer chipset as i have never pulled a chip and had a look at the bga connections to see.

I have been using Linux since Slackware 1st appeared back around 93 and writing drivers is something you had to do if you were going to start trying to interface with hardware, its just time consuming.

thanx for the info.

Interesting... Been years since i messed with Sat stuff and kinda thought Dreambox went by the wayside with all the other fta stuff after all the CAS's got locked up once again, and it became a sport that had to be played privately behind closed doors, just not safe to play with encrypted downstreams and CAS's anymore here in NA. The last time i messed with FTA was 100's which were based on STi' old 5100 chip and i still probably have a shed full of them and other NA dvb stuff... lol... kinda cool to see some still playing that sport.

Yes i agree and as someone that has spent huge amounts of time reverse engineering a lot of things over the years is NOT something that i would advocate. I just said that to prove my point about Amlogic and its greed and relying on none Amlogic employees to provide the proper support for the products they sell and make people understand where Amlogics REAL interest lies. As far as having Arm employees being involved thats all good but still theres only so much they can do without risking violating whatever there agreement is with the downstream companies that licence the ip-cores they licence out which is all Amlogic is really doing. Amlogic developes the SoC with the hardware they want and then licence the Arm core to use in it. I know from years of experience with others going down simular roads that its a fine line to stay on when it comes to reverse engineering intellectual property which is why i stay somewhat private these days... Since you mentioned the Panfrost stuff i have been playing catch-up and going over what they got cooking and your right it looks interesting.

on another note... just what exact linux revision are they trying to unify to as I am thinking about spending a bit of time going back and revisiting the kernel issue. years ago a couple of us move the old meson8m up to a custom 3.14 kernel which works good but now with the newer stuff i am assuming were talking about unitfing up in the 4.xx range ?

Quote from chewitt

S912 has a bright future. See YouTube for evidence. Panfrost still has some serious bugs to solve before we can think about public testing, but considering the infancy of panfrost code it's in good shape. The lead panfrost developers have publicly stated good Kodi support is one of their goals

I agree. which is why i invested so much time in getting all the sunvell boxes working. I run my own OS which i built years ago roughly based on buildroot and some of the early OpenELEC sources. Personally i still think my old original ENY MS8's run the best as even the newest kodi works extremely well and very rarely do i have lockups and when i do its almost always based on some plug-in i was messing with, Thats said, i really think there will be a bright future for the S912 SoC. What scares me is that by the time a lot of this gets worked out that Amlogic will have forced a new hardware revision and a lot of the unsuspecting public will by into it repeating the same cycle as the current level of support for the S912 boxes. I think people should just stick with the current level of S90x boxes but stay away from any of the x2 revisions now emerging. Just going over to the linux-meson site you can already see that most of the features on their comparision chart currently show a lot of the newer x2 SoC's as unsupported when comparing to where things currently sit with the S9xx units. The real sad part is that if Amlogic just licenced the MALI T8xx DDK none of this would be happening with the graphix end of those SoC's, for any serious codes tho, scour the net to find a bootleg copy of the DDK and they can see how this can be fixed, its just that soluction could never be released publicly because of licencing, but it does prove that things can be fixed. the other bad side to the DDK is it is revision specific but still for the amount of baseline system changes its still not a major investment for them. Producing low level drivers at this level is time consuming but now that you pointed out theres another group working thats a good sign... the last time i checked lima was a ways back and it had been abandoned and panfrost i wasnt really aware of tho i was aware of Neil and his work for quite awhile now...

Its inspiring to see where this goes tho.

Well let me say inspite of my thoughts on the current predicament of S912 ( or i should say anything maliT820 ) i not so sure i would say its at its end of life to be fair. Playing with linux on a box is always a game of catch-up when it comes to new boxes being introduced and better software being developed and released, so who knows but maybe by the time the next new generation is releases the current S912's will be in a better position.

The other part of the equation is what your expectations of the box come down to... meaning if your only interested in receiving leading edge technology driven streams then i quess keeping up with the newest may be the thing to do, BUT if your only looking for decent 1080 or marginal 4k streaming the current status of software like LibreELEC and CoreELEC (rom emu's) are not bad at all.

I maintain a small network of T95U/Pro and the T95K/Pro boxes running Leia and Krypton which work just fine. I've been using those Sunvell boxes since they came out. The missing software to truly using the boxes full hardware may be missing but is not preventing it from still being usable. It all comes down to what your needs are based on.

I have managed to compile both LibreELEC and CoreELEC from their most recent Leia rc4 commits using the S912 project and both systems actually run fairly well. short of a few cosmetic things like the front display not working but bluetooth, wifi, ethernet, and audio all work fine with the right dtb. CoreELEC and the rom emulators are fun to play and bluetooth Ps3/4 worked right out of the gate. The only real adjustments to get basic operation was to setup the remotes that came with the boxes. So to be fair (even tho i am not a Amlogic fan anymore ) the boxes are workable and who knows but things should get better over time with the graphics support.

My normal usage is 1080/720 streaming from on line sources or streaming from my network storage array in the house where i maintain a rather huge collection of media. Even 4K is not to bad if i pull from a source with a decent connection. My tv's are all basically running 1080 or 4k but nothing really high end so for my purposes they work ok. I just have a problem with a company (amlogic) that would introduce a product and not even licence the ip-cores for part of the product the pushed on the downstream market so i have a issue with recommending something like that to others.

So truly your requirement or needs should be the thing to think about.

Also keep in mind that the x2 SoC's are once again another NEW gpu ... Not Mali T820 this time but Davlin Mp2's. and my quess is that Neil and the guys at BayLibre aren't gonna drop their current efforts on fixing the existing used GPU's in favor of moving onto another new GPU entry into the mix right off the bat.

Also just to qualify what I said above, all of my boxes are running on Linux as Android has been removed, so if Android is a requirement for your needs then its best to ignore what I have said and rely on others here that have actual experience running on Android and LibreELEC.

Hope that helps take a bit of the negative edge i put out there on Amlogic and the S912 based units as they can be as usable as any of the others if your running the version of Android that comes with it. I just don't use Android in any way as i see it as the source of buggy boxes in most cases and i only require media playing and some game roms.

As

Quote from chewitt

There is zero support for S905X2 (and Y2/D2 or S922) and that's not likely to change for some time.

Listen to chewitt... the x2 is a totally different animal and not as simple to to migrate as a lot of dealers will lead you to believe.

I had a X96 MAX Amlogic S905X2 sent to me as a sample to play with and there is no way i would ever tell anyone to buy it.

At this point in time this is just another example of Amlogic throwing a few nice additions to hook buyers but whats the point if the boxes run worse then most of the currently supported older boxes. Even Android 8.1 which is on them performs poorly and locks up and with 4gig of sram you would think there should be no issues with lockups, to be fair, maybe with some playing and shutting off some of Android's running garbage the box might run better but that's not something i would waste my time on as i believe Linux is the only way if you want real solid Kodi use.

The 4 gig Sram and 32g Flash are nice features but if they cant make the box run solid on their own version of Android its probably gonna be awhile before the public sees something like LibreELEC running unless your a serious hacker and able to do your own codiing.

And its not just one bad box i had sent to me as I have had a few sent to me and they all act the same way.

Personally I would advise people to stick with whats currently supported by asking people like Chewitt and the other coders around here and not be fooled by the misleading marketing that seems to drive this sport. Lots of dealers sell this stuff but very very few handle software other then what they can pinch from others... Stick with what is currently supported and known to work.