Posts by buzzmarshall

Anyways.. read what you posted in that information as it proves my point, as your still missing the idea of what data is being sent from one device to the other.

One last attempt... for example: with any of those methods your referring to that doc explains it ...

say im screen sharing on my phone and want to share that display on my tv so i open up a pdf on my phone and am reading it and cursoring thru the page, you will see the identical screen now shared on the casted to or mirrored to display. or say i am using a file browser to hunt for a file on my phone i will now see that as well on the shared display.. the data being sent to the mirrored or casted to display is not the same as a audio/video stream... ya i quess you could start a movie on the phone in full screen and you would see it on the other display but now while thats running move your cursor around the screen and you'll see it do the same thing on the screen... Now i am sure that if one were to look at the actual movie files data on the phone your not going to find that information of the cursor in the data contained in the movie's data, not even in the wrappers that handle the packets that create the stream.

how anyone defines the word "Steaming" is really meaningless without understanding the data thats contained in the packetized data that creates a stream. and thats my point... as unless i misread your original inquiry about wanting to stream audio/video from your local network to your other devices which implies your wanting to stream a typical audio/video file... If you really want to understand more about streaming you should spend some time reading the DVB spec's as it covers most of the protocols and specs involved in transmitting media wether its from a sat's downstream or from internet feeds and cable's the information needs to be packetized and control via the accepted standards and understanding that may help your realize that just because something is sending wired or wireless information of any type to another device there has to be a spec or protocol to how that data is organized but not all things are the same.

to most peoples mindset Streaming implies a audio/video stream even tho something like your cell phone operates on sending and recieving data people really dont say they are streaming their phone calls.

As i said i think your misunderstanding the term streaming and the technologies involved in how those devices you keep referring to work.

I think you're intermixing the concepts of media data stream and mirroring or screen casting when they are really 2 different things.

Streaming a media file requires a application or server daemon to handle streaming the file according to one of the accepted streaming protocols which means on top of some stream control code its also actually sending the audio/video data stream and theres no reason someone could not create or embed a daemon on LibreELEC to do that.

Things like ezcast are mirroring the display data from one device to another display device or many devices. In other words its got a dongle on one end and another dongle at the other end that plugs into the hdmi input so that when you run the dongles application on the sending device it controls the hardware dongles that talk wirelessly to send the screen data from the sending device to the receiving device dongles. The wireless mirroring signal is not from what i understand the same as a media stream that is audio/video and my quess is that its probably proprietary to dongle manufacturer.

TV's that play back media from a usb device plugged into it do so because the TV's firmware has some type of built in media player.

Don't get me wrong as i am not saying you can't do something i am just not sure how to help as i think your mixing the concepts and its making it hard to give you the answer you expect.

If you want to stream media then you need to setup something as a server to serve that data up to the network, and have it on some device such as a capable router or a NAS box.

Someone please correct me if i am wrong but from what i understand about the Ezstream product thats how it works.

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.