61 replies to this topic

[doglover]

The Crossepg provided in OpenPLi does not import XMLTV files anymore.

I am not sure where it is taken from (probably OE-Alliance)

This version has not been updated for a long time.

 

The version on E2OpenPlugins:  https://github.com/E...plugin-CrossEPG

has been adapted for reading xz files.  However I am unable to make an ipk from it, or otherwise install it on a receiver.

 

I am getting several questions about importing EPG with the ais of CrossEPG.  And I am unable to answer them, by the lack of a working version.

One of the problems is that Updating the Rytec sources doe not seem to work anymore. In python file which is suppose to do this, some files are being read which holds the data.

These files are still present and up-to-date  (although they contain the .gz references at the moment)

 

My questions:

 

1. Update crossepg_rytec_update.py so it works again.

2. Provide a bitbake recipe which I can run in the OpenPLi building environment, so I can build a working version of Crossepg.

3. Maybe updating also the version on OE-Alliance

 

Lack of answers, will results in me complete abandoning Crossepg.

 

Willy

 

[WanWizard]

Currently, the entire setup of the E2OpenPlugins repository system is mess, which is due to the fact that the recipes for all these plugins are public too (in the E2OpenPlugins/e2openplugins repository), which is unmanageable because it introduces "hardcoding" at several layers in the bitbake system. This has resulted in all plugins being about 4 months old, no matter what was changed in the repositories and to the SRCREV pinning.

 

Erik Slagter and I are busy reviewing this system, in order to get this back under control. It will be addressed in 6.1., as we don't know the choosen solution yet, we can't say if it can be safely implemented as a 6.0 hotfix, that depends on the impact of the change.

[doglover]

I am not asking for inclusion in OpenPLi.  Far from it.

If I could ditch Crossepg I would.  However it is around, and I am getting questions, and I cannot answer them, because I cannot install this plug-in.

A bitbake recipe would help (one that works)

 

I tried the recipe in E2OpenPlugins/e2openplugins for Crossepg - big failure.

 

Willy

[WanWizard]

It is already in OpenPLi:

Package: enigma2-plugin-systemplugins-crossepg
Version: 0.8.2_20170420
Depends: curl
Status: unknown ok not-installed
Section: base
Architecture: mipsel
Maintainer: OE-Core Developers <openembedded-core@lists.openembedded.org>
MD5Sum: 580bae4171a8fa8ebcad8829f96c7a6f
Size: 605250
Filename: enigma2-plugin-systemplugins-crossepg_0.8.2_20170420_mipsel.ipk
Source: git://github.com/oe-alliance/e2openplugin-CrossEPG.git;protocol=git
Description: systemplugins-crossepg
 systemplugins-crossepg

the problem seems to be it's an old version, looking at the date in the filename.

 

edit: same version in release and develop. And I haven't figured out where this comes from.

[WanWizard]

I've just been kicked under the table.

 

Appearently we don't build CrossEPG, due to the fact it contains a binary, and quite a few libraries, without source code, and no clue what is in it and what it does. Skaman doesn't seem to want to share his code.

 

So the ipk is in the third-party feed, no idea who has built it, how, etc. The fact that it doesn't have a maintainer doesn't really help.

[Lost in Space]

I'm pretty sure that I always build my CrossEPG binaries for my OpenEPG Plugin directly from the sources which are available = keep on searching, not everything has to be in your e2Open git.

 

BUT OpenEPG Plugin uses only the load from ts stream/mhw part of the CrossEPG binary, for the xmltv sources loading in DreamOS we use ONLY latest EPGImporter.

 

This completely prevents the current problems and mess-ups and both solution are under control.

Edited by gutemine, 16 October 2017 - 19:39.

[Lost in Space]

For this basic functionality without xmltv you  need only these 4 files:

 

crossepg_downloader
libcrossepg.so
crossepg_dbinfo
crossepg_dbconverter

 

And these still build even from teh e2Open sources available.

 

Plus the binaries for the mhw extracts ... if needed
 

Edited by gutemine, 16 October 2017 - 19:53.

[WanWizard]

If you can point us to a source location that has everything available as source, that would be great.

 

The E2Open version isn't maintained at all (I've got a major cleanup planned for that stuff),, the E2open recipe for CrossEPG even uses the OE-A version (https://github.com/o...plugin-crossepg). And that one comes with a bin directory with binary libraries and an so file of which I have no clue what it is, what it does, and why it has to be there as a binary blob only.

 

edit: Indeed, binaries. So where is the source of these three files and that lib?

[Lost in Space]

Well. I can give you only some hints, not a complete solution:

 

Look at the Makefile - it also shows how to fill the bin directory.

 

I'm building the binaries without x-compile directly on my arm and mipsel box in a locally installed debian, and there it works to build everything I need.  make clean gives an empty bin directory and make a filled one

 

And yes, you have to follow the pointers to the origin to get really the latest sources, but this is tricky and needs some string pulling.

 

But keep in mind that the sources for the binaries are also borrowed, which means they have hardly changed in the recent years, except the mhw binaries, but some of them have their own developers in the countries where they are needed for getting epg, hence these chaps are more motivated.

Edited by gutemine, 16 October 2017 - 20:17.

[WanWizard]

Thanks, will do.

 

This is all very new to me (haven't done any C or any compiling in almost 30 years ), so  learning all the time. I have found the sources of those binaries.

 

I have to say the way that repo is setup. it's just a confusing mess. The binaries are the result of a make, and shouldn't even be in that repository.

[Lost in Space]

The person who checked it in just did it Q&D but you should be able to find your way

 

If you want to test the binaries after compiling you may check my OpenEPG Plugin for a dramatically simpler way of using them ... and yes there is also an ipk available which is able to load epg.dat instead of the epg.db for which I built it.

 

The original CrossEPG Plugin python part is so scaring that I instantly decided NOT to make it work under DreamOS and instead just borrow the working binary parts and wrap them on my own in a much smaller and simpler plugin ... still doing the job.

 

I don't want to blame the creator of CrossEPG for this, it was just my personal decision NOT to fix so many obvious things, but better create my own buggy EPG Loading from SAT Plugin.

Edited by gutemine, 16 October 2017 - 21:04.

[WanWizard]

I think we can agree on that.

 

When I am really bored, I might have a look at it to see what everyone is raving about, and if that is justified, convert it to sometime more usable. But only then...

 

So far I haven't seen anything that an image can't already do, one way or another.

[Abu Baniaz]

The only benefit of CrossEPG is for OpenTV EPG readers. As most of Sky UK is not viewable, best to tell people who want to use Rytec EPG data to use EPG importer.

 

Trivia:

There were many posts over many forums stating that libcurl is required, but nobody wanted to add it to dependencies for PLI, the building of it was then dropped because it is bad. I provided versions of CrossEPG that work on the PLI feeds. After much pleading, it was added to the PLI feeds. This is essentially the OEA version, with a basic box branding, removed dependency on Enigma2, removed the dependency on GCC version so it uses whatever version is on an image.

[doglover]

The only benefit of CrossEPG is for OpenTV EPG readers. As most of Sky UK is not viewable, best to tell people who want to use Rytec EPG data to use EPG importer.

 

 

 

That is what I am always saying to people.  But firstly there are really stubborn people around, who want to stick to Crossepg.  And keep on asking questions.

Secondly there are still images around which do not offer EPGimport in their feed.  Like BH (BlackHole).  OpenBH has it included though.

 

Willy

 

PS: @gutemine:  what you are suggesting is outside of my knowledge. 

Realise, I am not interested in reviving Crossepg.  I just want to answer questions.  At the moment this is not possible.

[Matrix10]

Sorry Willy,

 

Unfortunately, not everything is right.

The problem is that EPGimport does not work properly on VU + based images (BH ,Vti ...)

and not the desire to use and  offer EPGimport in the feed.

 

So the problem is the  VU + coding with EPGImport.

 

On the other hand, why not to use CrossEPG

when CrossEPG works 100% on BH image and  EPGimport not.

Problems were related to configurations files and links (changes on Epg servers) and not CrossEPG.

 

Of course it would be best if all images can use the same one EPGimport Or even both.

 

Rgd MX

 

 

Edited by Matrix10, 17 October 2017 - 11:06.

[WanWizard]

Would it then not be better to have a look and see WHY EPGImport doesn't work on these images? What is the definition of "properly"?

 

Unfortunately I don't have a single VU+ box at hand to have a look myself.

[Matrix10]

Would it then not be better to have a look and see WHY EPGImport doesn't work on these images? What is the definition of "properly"?

 

Unfortunately I don't have a single VU+ box at hand to have a look myself.

 

I'm not a coder already a user

 

Slow

and loss of epg

 

We do not change base VU + coding and python/lib files .

(Maybe VU + to change)

 

CrossEPG is very fast on Black Hole image.

[Abu Baniaz]

I hear vu+ coding is also incompatible with Virgin EPG patch, this is very similar to coding for Bulsat. So, surely Vu+ should do some changes in the EPG system to catchup with other images.

[doglover]

On the other hand, why not to use CrossEPG
when CrossEPG works 100% on BH image and  EPGimport not.
Problems were related to configurations files and links (changes on Epg servers) and not CrossEPG.

 

Oh yes.  Blame it on me.  When I cannot check anything out.  And this is exactly the reason I started this topic.  So I can check this out.

And I will not install BH or VTI on one of my receivers.

 

Changes:  Oh yes everything should stay the same.  Then no progress can be made.

I am (was) willing to coöperate and solve the problems.  But the problems to obtain a working version do not help to increase my interest in finding a solution.

 

Help me to a working version of Crossepg for OpenPLI  (the one in the OpenPLi feed is outdated for XMLTV import).  But even you Abu Baniaz does not seem to be able to provide me with it.

 

Willy

Edited by doglover, 17 October 2017 - 12:53.

[doglover]

 

Sorry Willy,

 

Unfortunately, not everything is right.

The problem is that EPGimport does not work properly on VU + based images (BH ,Vti ...)

and not the desire to use and  offer EPGimport in the feed.

 

So the problem is the  VU + coding with EPGImport.

 

The imagebuilders of BH and VTI are not interested in including EPGimport.  Are they to lazy, or are they incompetent.

 

Willy