33 replies to this topic

[Huevos]

Does OpenPLi have any plans to add OpenTV EPG direct download so CrossEPG is no longer needed. I seem to remember one of the team mentioning it a while back but can't find the thread now. Would be a good addition, especially for people using 13E and 28E.

[littlesat]

When someone offers us a good patch. Is the fasted way to offer this...
I suggest it is always better then to put the efford into a plugin...
We're duchman an we can't even watch these specific channels....

Edited by littlesat, 22 November 2014 - 23:47.

[Huevos]

We're duchman an we can't even watch these specific channels....

You're in the footprint of both these satellites. I'm in Spain and I watch them.

[WanWizard]

The last time this was discussed it was appearent that the entire EPG reader code was a big mess, and would need a major overhaul first.

And it would probably benefit from a proper storage system instead of a "lame" db and xml files...

[littlesat]

We're indeed in the footpront, so we can do it.... But it needs also time. We're open source. The algorythm is know from the plugin and that seems also to work. Unless the epg stuff is wierd in openpli it would be nice that someone makes it within this wierd code. Months ago we get something for cable uk I did commit, whe same can happen with this. Code is known from the plugin, how you can add it is known fromthe uk cable....

In the first place it was not a good idea to make it within a plugin....

[Rob van der Does]

The last time this was discussed it was appearent that the entire EPG reader code was a big mess, and would need a major overhaul first.
And it would probably benefit from a proper storage system instead of a "lame" db and xml files...

IMHO the two are unrelated.
As it is now people use Cross to add the Open-TV info; that would be the very same 'mess' as when E2 does this directly, only more convenient for users (and probably more reliable as well).

Edited by SatKiekerd, 23 November 2014 - 09:25.

[littlesat]

Crossepg is even à more mess Then adding it to e2.. Indeed structuring the epg is off. topic. As I said making it à plugin was from the bigginning not à voor idea

[WanWizard]

No, it is not unrelated.

 

E2 works with readers to get EPG data, with is already quite complex, adding more readers just makes it more complex. Which means a lot of the dev's time goes into dealing with that complexity, which is why until now it hasn't been done.

[Huevos]

No, it is not unrelated.

 

E2 works with readers to get EPG data, with is already quite complex, adding more readers just makes it more complex. Which means a lot of the dev's time goes into dealing with that complexity, which is why until now it hasn't been done.

Well to me it doesn't make any sense that E2 has a built in mechanism to display the EPG data, but needs a plugin in order to retrieve it.

[WanWizard]

It doesn't need a plugin, we can agree on the fact that E2 has to deal with stuff like this.

 

Problem is and remains that a lot of code in E2 is crap, and it's in C++ which not to many people seem to dare to "attack". So instead of working on the problem, people hack around it with python and plugins. Making it an even bigger pile of crap.

 

Fixing this is a big undertaking however, and changes like this seem to be impossible since we became "OpenPLi", and there's pressure to make sure there's a working image every day.

 

We need to find a way to get the old PLi quality back into OpenPLi.

[Huevos]

It doesn't need a plugin, [...]instead of working on the problem, people hack around it with python and plugins. Making it an even bigger pile of crap. [...] changes like this seem to be impossible since we became "OpenPLi", and there's pressure to make sure there's a working image every day.

 

We need to find a way to get the old PLi quality back into OpenPLi.

Well you can't have your cake and eat it. Typical response on the OpenPLi forum when asking for a new feature is "when someone provides the patch you can have the feature". It is a shame if you think the code so many people generously provide is a low quality and dragging the image into oblivion.

Edited by Huevos, 24 November 2014 - 02:41.

[WanWizard]

I don't see why not. It worked pretty well in the old E1 days.

 

And I didn't say the code people provide is of low quality, on the contrary, I am extremely impressed by the work of people like yourself, IMS, Dima, etc.

 

What I would like is to change the current way of working, so that we can have longer development tracks with more collaboration (like the excellent work now going on with gstreamer), so the overall quality of the Enigma2 core can be improved. For that to happen we need to remove the pressure of having to work in public and create a working build every night, because you can't simply have that when you do major overhaul work.

 

One of the things begin discussed is the option to return to public and developer-only repo's. Bugfixes happen on the public repo, public images become tested and stable again. On the developer-only repo development can testwork can happen, and once a feature is complete and tested, it can be merged with the public repo.

 

I think it is a mechanism that gives us much more happy "end-users" (they get a stable environment again), and gives developers, people like yourself, much more room to "play".

 

If we can manage to improve the Enigma2 core significantly, there is a lot less need for plugins. Because let's face it, as you correctly mentioned, most of them exist to add missing E2 features, or work around limitations of the E2 codebase.

[Huevos]

It's in C++ which not to many people seem to dare to "attack".

I think, apart from being C++ being a lot harder to read than Python, the main reason people don't get involved with it is because it needs to be compiled, or the image built. At least with Python you don't need to compile and if there are errors in the code they are found and corrected in a jiffy, which is much easier for people like me who have zero professional coding background.

Edited by Huevos, 24 November 2014 - 09:30.

[WanWizard]

Absolutely true.

 

Understandable, but from a "team" or "product' point of view not necessarily a good thing. As they say, it's a lot easier to build a house on a solid foundation.

 

The current E2 core code is still more or less the same as when DMM fumbled it together. In the past, PLi only made a leap forward when we decided to disconnect ourselfs from the old code, and put core improvements before DMM (and now other teams to) compatibility. You can see they struggle as well, with the Goliath disaster, and the poor results after a long time developing for the 7080HD.

 

And a solid core with a good API makes it easier for plugin writers as well. Currently there is no API, you can access everything from Python, with green screens galore as a result. In a good architecture, with a well defined API and a shielded core, a plugin should never be able to bring down the system.

[Erik Slagter]

<rant mode>

BTW it's not that Python is easier to read (let's agree to disagree on that point...), it's just the C++ code in enigma2 that seems to have been written with primary objective to be as obfuscated as possible. It's completely counterwise to the goal of C++. They have using extensively features of C++ that are not needed (at that point in the code) and only add complexity, whilst at the same time, features that make easier understanding of the code are not used. This is unfortunately something that seems to come with C++, programmers using exactly the "wrong" features. I tend to call it "C plus classes" with is fundamentaly something else than C++.

</rant mode>

[athoik]

It's not just "C plus classes" it's a mixure of different coding styles make it hard to read.
In some places you get size_t in order int. std::string are only used to convert back to c_str()
There are no try catch exceptions.
Some files are really huge with many classes inside.
There is no unit testing! (that would really solve a ton of issues!)
There is no documentation!

[littlesat]

And unless it gives you the impression it was made on an attic developed just the night before final release we still strugling with it with pleasure....

Edited by littlesat, 24 November 2014 - 16:35.

[Erik Slagter]

It's not just "C plus classes" it's a mixure of different coding styles make it hard to read.
In some places you get size_t in order int. std::string are only used to convert back to c_str()
There are no try catch exceptions.
Some files are really huge with many classes inside.
There is no unit testing! (that would really solve a ton of issues!)
There is no documentation!

Well the last line, yeah, it's a known problem...

But for the rest, indeed, I totally agree. It almost looks like they have been trying to "impress" someone with their C++ "skills". The interface to python doesn't make it quite much clearer as well. This may also be the reason they're not using try-catch. And indeed, if you use it sensibly, it can save a lot of code and complexity. Also the code is "rich" on global variables which are modified "everywhere". Not to forget global class instantiations which make them (constructor) being called "out of nowhere".

And indeed, yes, the many classes-implementations per source file is very annoying. Also it looks like some of the implemention of some classes is in one source file and another part is in another file (together with various other classes, grmbl). Also lots of implementation code in header files, which I think is horrible...

[Erik Slagter]

And now it's time for on-topic (or open another thread )

[Huevos]

And now it's time for on-topic (or open another thread )

Yes. PLi is what it is. There are commits and new features being added all the time so I don't really understand why this request should be any different.