117 replies to this topic

[WanWizard]

OpenPLi team would prefer its users to have a broken image rather than take this patch. And no one from PLi is going to fix it because as WanWizard says "there is not the will".

 

A bug fix is a bug fix, that is totally unrelated to what I was writing, which was about redeveloping and future-proofing the platform.

[DimitarCC]

We already discussed why url can not be used. (Because now it can be http://xxxxx/H6678HGY/123 and after 1h -> http://xxxxx/B8824OOB/123)

 

If you want to have EPG anyway you have to provide unique sref like 4097:0:19:8A0:16:70:10:0:0:0.

[luisteraar]

Most iptv streams in boequetes does not have epg

reference most entry's are

4097:0:1:0:0:0:0:0:0:0:http%3axxxxxxxxxxxx

 

your methode works for your provider but

not in general

Edited by luisteraar, 5 October 2023 - 15:53.

[WanWizard]

It is not a problem to assign a unique serviceref. But it will be unique to you, to that specific box, to that specific bouquet, for as long as nothing external changes that bouquet.

 

Until now, every IPTV plugin I've seen generates random servicerefs when generating bouquet files, and every generation they will be different.

 

So please show me how you are going to guarantee that you can maintain the stability and uniqueness while you have no control whatsoever over the value of it?

 

This can only be done if Enigma is on control of generating the service ref, and there is a fixed algorithm for it so it always generates the same service ref for the same input.

 

This is a prime example of where you run into the problem of Enigma consisting of antiquated DVB centered code, in which you try to hack or shoehorn stuff in that has no relation to DVB whatsoever.
To solve this properly, you need decoupling of a "service" from the underlying "service provider", which can't be done easily because although object oriented languages are used, nothing is designed and coded in a proper object oriented way, using composition and decoupling.

 

edit: this is not a new problem.

 

E2 has known alternative services for ages. If properly designed, you would have one service, and multiple service providers providing that service. Which would make things transparant for anything consuming that service. You could even have a service provided by DVB-S, DVB-C, DVB-T and stream, and when recording the service, Enigma could transparantly select the correct service provider. EPG would also be assigned to the service, only once, instead of 4 times. A service reference would also be irrelevant, because that is abstracted, it is a parameter of an underlying service provider.

Edited by WanWizard, 5 October 2023 - 16:02.

[WanWizard]

Most iptv streams in boequetes does not have epg

reference most entry's are

4097:0:1:0:0:0:0:0:0:0:http%3axxxxxxxxxxxx

 

your methode works for your provider but

not in general

 

That is not the point.

 

It is every easy to edit the bouquet file and change that to 4097:0:1:2:3:4:5:6 and thus make it unique.

 

Problem is it is only unique at that specific point in time, on your box, as long as it is not touched (by yourself or some plugin).

[DimitarCC]

But there are importers that most of the people use for the EPG to be imported from internet and stored in enigma epg.db.

But epg.db uses sref so my solution is not for my provider. it is general. That you make (or it is provided by your provider) a service reference for all of your streams one and the same (4097:0:1:0:0:0:0:0:0:0) its another story.

You can not expect in userbouquet in the sref to be defined the url for epg as well like it is in m3u.

enigma2  channel lists are not like m3u lists abd you cant define it like that.

[littlesat]

Here you get a point why it cannot work….

[WanWizard]

And so we are back to square one.

 

Because there is something out there that was created 20 years ago, nobody has the balls to change something in fear of breaking something. And so we continue shoehorning more and more crap in.

 

Fact remains the world today is vastly different from when the 7020HD was introduced and E2 was developed, and E2 hasn't evolved with it. And like in nature, if you don't evolve and adapt, you become extinct.

[DimitarCC]

 

 

So please show me how you are going to guarantee that you can maintain the stability and uniqueness while you have no control whatsoever over the value of it?

 

 

Nobody can guarantee that as you said because enigma is not in control of that. And i dont think we have to guarantee that at all.

 

And yes the uniqueness will be for you and for your box. The point is once you define it for you it not changes and selected track will be stored.

 

About the plugins that generate random srefs.... Well with that plugin you can not use EPG as well because on next generation you still will be binding EPG to old sref.

 

So anyway enigma2 has its limitations that as you pointed out will be very difficult to fix right now in the clean way. But at least with my proposal we will fix the case with not changeable srefs in bouquets.

 

About that third-party plugins/importers that generate random refs well that is completly different story. If you want to fix that, can be made integrated extendable infrastructure that will get that dynamic lists from your provider and generate always the same sref in the bouquet. Since that will be extendable in python you can add implementation for the grabber and bouquet generator for your provider and to ensure that srefs will be always the same.

 

That infrastructure can be all in the python, even realized as system plugin (ofcource it will require some changes to servicelist and infobargenerics as well and minor changes in c++ but then it will be completly generic and will work with every provider that provide m3u lists.

 

If you make a quick look to DreamOS there is something like that made as new type of service reference that can work with custom python provider specific implementations.

 

I also have such my own implementation working on top of modified PLi enigma2 but even not dare to discuss it here because as i know you guys it will take ages.

 

However this thread here is for something different lets not deviate to another enigma problems and limitations.

Edited by DimitarCC, 5 October 2023 - 16:24.

[DimitarCC]

 

Fact remains the world today is vastly different from when the 7020HD was introduced and E2 was developed, and E2 hasn't evolved with it. And like in nature, if you don't evolve and adapt, you become extinct.

 

I agree with that. But because PLi dont evolve and adapt because of different reasons we developers (in particular I) try to propose some changes and new functions even by workaround or on top of what is already there so at least PLi to not extinct.

 

But as i can see there is great resistance to that. Looks like PLi dont want to adapt at all. Or at least i got that feeling.

[Huevos]

As pointed out above there are 2 types of provides, those that offer and epg and those that don't. This system work fine with providers that offer epg.

[WanWizard]

But as i can see there is great resistance to that. Looks like PLi dont want to adapt at all. Or at least i got that feeling.

 

I don't call hacking all sorts of junk in because it can't be properly added due to an outdated design and architecture "evolving". I call it "piling more shit on".

The status quo today is that some think we should stop adding more crap to the spaghetti, and start cleaning up and modernize, as it is the only way for this (and any E2) project to survive.

 

But those who think that can't do it alone, and others can't be bothered, don't want to spend time on it, not in their personal interest, not interested in the project as a whole, are afraid of the consequences, and lots of other excuses.

 

And thus it is whats called "chooing between the plague and cholera": either way, the project will die, either due to inertia, or due to a collapse under its own weight in crap. Like you see already happening with other images that don't have many issues accepting everything thrown at them.

[DimitarCC]

I dont force anyone accepting this. But i think it will be usefull for all users out there strugling with that tracks selection issues. Everyone have its own thinking, but mine is it is better something to work than to not work.

[WanWizard]

Again, I have no issues with bug fixing. Let that be clear. New functionality is a different matter...

[luisteraar]

Correct
I am thinking in  different direction
enima2 has good stuff dvb tuner handling and streaming.
Everything written in C
Now have a web server on the stb and i am working on html5 streaming using the enigma2 api.
I could need help, I have to learn HTML and JavaScript, but I'm making progress.

[WanWizard]

That might work for you, but 99.9999% of the users want or need a UI on the box.

 

A redesign was already proposed 10 years ago, where the current codebase would be split: a backend system in C++, dealing with all hardware, tuners, CI, recording, a proper database for all data structures (epg, channels, etc), etc, and with a well-defined API. On top of that, you could build something HTML based using a web engine with C extensions (like the way HBBTV is implemented) to access the underlying API.

 

It would make UI work much simpler (there are a lot of CSS / JS developers out there), it would allow for headless operation (like you would like to use), it would allow for seamless networking ( the UI on hardware A, the backend on hardware B ) and distributed services (like which recording runs where, take CI availablity into account, etc).

 

It has been pitched a few times, but no developers were interested, as it means a proper project, run like a proper project.

 

Which includes commitment, willing to also code stuff you're not personally interested in, dealing with project planning and issue trackting, working towards a common goal and with a predetermined design, atc).

 

It collides with the current " I " culture.

[luisteraar]

The UI is then not on the box but on the player

webbrowser tv player android player etc.

Recording etc can be done remote.

Weakness is chanel list stil paython/lamedb

[DimitarCC]

I suppose you have to open separate thread for that UI stuff. I said several times this thread is for different thing.

[WanWizard]

The UI is then not on the box but on the player

webbrowser tv player android player etc.

Recording etc can be done remote.

Weakness is chanel list stil paython/lamedb

 

Read again what I wrote.

[luisteraar]

I'am a fan of KISS

 

keep it simple and stupid