117 replies to this topic

[DimitarCC]

This is for remembering the last selected audio or subtitle track for IPTV services.

I know there is a plugin for AutoAudioSelection but it relies on rules only and can not remember the actual user selection.

 

Where is needed that? Well for IPTV services that are DVB compliant and have multiple audio or subtitle tracks. Now it can not behave like the real DVB service regarding audio and subtitle user selections.

 

This change fix/add that functionality.

here is the PR https://github.com/O...igma2/pull/3786

[luisteraar]

If it is a real dvb (mpeg-ts) stream handle it as it in enigma2

change then in userbouquet 4097in 0

[DimitarCC]

In userbouquet  4097 have to be 1 i think.

But even if you do that it will not handle it like real DVB service. It will not store the chosen audio or subtitle track and when you zap away and return back it will select default tracks.

[WanWizard]

Those are stored in the lamedb, so that only works for channels registered there.

 

Until now, nobody has been brave enough to improve that system, in fear of "breaking compatibility".

[DimitarCC]

Thats why i try to not touch lamedb. Instead i use a separate storage file so there should be no compatibility issues.

[luisteraar]

It would be possible to give a iptv stream a service reference that is

stored in lamedb.

Then settings wil be remember.

Handel iptv as a stream from a tuner.

[DimitarCC]

As @WanWizard stated no one is brave enough to modify the c++ code and extend lamedb to store the streams as well. Thats why i propose a different approach but it seems is not well accepted

[WanWizard]

There is no mechanism for a consistent service ref for a URL. Tools like JMX even generate new random service refs every time the channel list is imported from the IPTV provider.

 

The root cause here is the fact the entire design of the "database" is wrong, and it is missing a proper API. It needs a complete redesign.

 

But doing that will break "settings" compatibility with other images, ipk's with bouquets, and all bouquet editors.

 

So nobody is willing/daring to work on this, so everyone resorts to extending the junk that is there...

[DimitarCC]

I agree. That needs a complete redesign. But since you also said its unlikely then why dont stick with my approach that doesnt break anything.

Ofcource if you use importers that generate bouquets it is very likely that there always will be different serviceref. 

Thats why i had different idea instead to import the stream urls and generate serviceref everytime that to be fixed in the  bouquets and by m3u identificators (e.g. tvg-id) to pull the url real time.

I have my own implementation for that and with my local provider and zero4k box works very fast with no slowdowns like somebody claimed.

[WanWizard]

I can and will never agree to making bad code worse, only because nobody can be bothered. Either do it well, or don't do it.

 

It creates a vicious circle, the more spaghetti is created, the less appetite there is for major changes, so more spaghetti is added. And with every cycle, it becomes harder to break away from it.

[DimitarCC]

Well but now even when someone will to have appetite for spaghetti you put a salt in them and making it impossible to eat.

So well when we look the prespective that will not be touched another 10-15 years.

Well i can and will not stay at same place another 15 years. Ok if you dont agree to put anything like that in the image i am fine with it just state it clearly in the right way.


If i was at your place i would state that this will not be implemented ever since you have not developers to do it in the "right way"

[WanWizard]

The way it is going it is not going to last 5 years. If you're lucky.

 

Technology goes fast, the world changes every day. And E2 hasn't changed in over 15 years, it is now an old fashioned end-of-life relic.

 

If i was at your place i would state that this will not be implemented ever since you have not developers to do it in the "right way"

 

Unfortunately that is the case, yes. But the same applies to all other image developers. They all fear big changes, for different reasons. And nobody wants to commit time to a large project, often ego's get in the way.

 

DVB reception is dying, and the antique codebase can't handle the alternative (there are plently of much better and cheaper alternatives).

[Huevos]

The way it is going it is not going to last 5 years. If you're lucky.

5 years? Almost the whole of the planet's broadcast tv uses this system.

[WanWizard]

We'll see what the state of things are in 5 years time.

 

Beginning of the year I was still sort of hopeful, now big providers like SKY no longer install dishes, but instead push you onto their "we want all control" TV or their "otherwise we grab all control anyway" streaming box.

 

Fact remains we're stuck with a hopelessly antiquated platform, which is ill equipped for CI modules and streaming services, and nobody is going to change that.

[luisteraar]

dvb-s-c-t is not dead.
Big new thinks need to be programmed
in a stable language like C.
nobody knows C anynome and use
a intepretor language like bacic or python.
java and html5 is now also interesting
for ui.

[WanWizard]

If you say so.

 

And the programming language used has absolutely nothing to do with it.

 

These are the issues:

• everyone is doing her/his own thing
• ego is more important than group effort
• nobody wants to be "told" what to do, nor when to do it
• there is no appetite to work together on a commit goal
• there is no appetite to make a long term commitment for a large project

And that is true for every image team out there.

 

A project like this needs a good project team, professionally setup and managed, working towards a single goal with a single agreed design.

 

It will never work with an "I decide what I do when and why, and nobody else" attitude.

[DimitarCC]

And how that will happen when everything that is offered got denied? No one will want to work in a team that nothing that he offer got accepted. or got accepted years after that.

That's discouraging and that developer will just leave in my opinion.

[WanWizard]

"Offering" something is a prime example of the " I " culture. If you develop something without discussing it up front, without knowing if it will fit, you are opening yourself to disappoinment.

 

And it works that way in most serious projects, open source or otherwise. Try dropping a 1000 line patch into a project like OE or the linux kernel...

 

Normally, in an application development cycle, you start with requirements, followed by architecture, followed by design, followed by implementation. With everyone working on a common goal, on tasks defined to reach that goal, even if those tasks are not their personal favorite. The project is more important than the person.

 

But as that is not the common attitude of todays developers, the chances of creating any succesful project of some size are slim.

 

Only those where you have a handful of dedicated people pulling the project along may be able to attract some outside help that accept they can't control the how, what and where, all other projects will fail and/or slowly die.

 

And unfortunately, OpenPLi is no exception. I've been trying, but I don't have the technical in-depth expertise needed to lead, and nobody else seems to be bothered. And that includes everyone currently committing...

[DimitarCC]

Definitely OpenPLi can not attract me as a developer that will commit myself to the project when i see everything i offer is not accepted.

And currently the "I" culture is more like the OpenPLi culture. Since everything that OpenPLi members doesn't use is not needed.

Isn't that example of "I" and nobody else.

 

 

 Try dropping a 1000 line patch into a project like OE or the linux kernel...

 

hmmm here we talk about 90 lines of code. Who speak for 1000? If the linux kernel developers was so picky for 10-20-30 lines of code the kernel will never evolve. 

Edited by DimitarCC, 4 October 2023 - 21:03.

[WanWizard]

You show exactly what the problem is.

 

If you contribute to a project, any project, you need to know up front if your contribution is accepted or not, of risk disappointment. You didn't know, went ahead anyway, and are now disappointed.

 

Also, you don't seem to understand that with any project, it is the owners of the project that dictate in which direction the project goes, and decide whether or not what is offered aligns with that direction.

 

What you can definitely blame OpenPLi for, is to not have the plans to define that direction and to clearly communicate those plans. And that is because the people currently developing for OpenPLi can't be bothered too. It is that simple.

 

But the day we accept that OpenPLi will be the next OpenATV, bloated, instable, slow and unusable for most people, is the day I quit.