29 replies to this topic

[Pr2]

Hi,

 

I follow the section Rytec of this board and many times due to CrossEPG bugs the advice is to uninstall CrossEPG and replace it with xmltvimport and each time this indeed fix the problem of the end-user.

(exemple: CrossEPG doesn't take into account the namespace to write the EPG data in memory so this lead to conflict between channels).

 

So questions:  

 

- Why Openpli feed still propose CrossEPG if we know that this gives issues?

- Why not remove CrossEPG and leave only xmltvimport (perhaps with a kind of redirection from CrossEPG to xmltvimport in the feed if possible)?

 

Pr2

[Erik Slagter]

It seems that crossepg features some Sky UK channels that xmltv doesn't.

 

You do have a good point though.

Edited by Erik Slagter, 29 October 2013 - 20:17.

[Pr2]

I can also add that CrossEPG uninstall doesn't work, people needs to go and delete manually the CrossEPG folder in /usr/lib/enigma2/python/Plugins/SystemPlugins otherwhise they have a gsod after trying to uninstall CrossEPG.

 

If channels are missing it should be discussed in the Rytec section, I guess it is just the source that are missing.

Edited by Pr2, 29 October 2013 - 21:30.

[gorski]

It seems this is not exactly black and white: http://openpli.org/f...port-mod/page-2

 

Problems with XMLTV Import, too... And big ones, with running out of memory etc.

[WanWizard]

That link is about some custom EPG import stuff, not about the XMLTVimporter? It's the most efficient solution, as it hooks directly into Enigma, unlike the plugins that fiddle with epg.dat style emulations...

[gorski]

Indeed, that looked like that initially... but then...

 

Maybe I got the wrong end of it all in Alien2...

 

But in 500HD it was also getting bad...

[Pr2]

Come on Gorski don't come with link to thread that has nothing to do with this thread.

 

Alien2 is not officially supported by Openpli anyway, so don't come here with bugs on non supported devices.

 

Every EPG importer can lead to memory problem if you try to load too many things in memory, remember that the EPG is stored in memory and not in the epg.dat file which is just a cache file written when E2 is set in stand-by and read when waked up.

 

Pr2

[gorski]

Maybe I am reading it all wrong...

 

I think I read reports saying that original and modded versions of XMLTV Import had the same problem (running out of memory)...

 

I tried original and modded versions in F500HD, XP1000 (BRDCM) and Alien2 (SH4).

 

Maybe I will try both of them, all over again, with OpenPLi images, as well as...

 

Then we'll see...

[Rob van der Does]

1- Cross can be used for reading the proprietary Open-TV EPG as is used by Sky-UK & IT.

They have a habit of keeping their EPG very actual (so many people set Cross to every hour or so), while XMLTV-importer has only one actualisation per day.

2- Cross uses a huge amount of memory during the import/parsing process. This is the main reason that Cross gives problems on several hardware/images. Using a swap-file will help most of the time

3- Using Cross for anything else then Open-TV on 28.2E & 13.0E isn't a good idea; the XMLTV-importer does a far better job then.

4- Cross doesn't work 'in the background', but claims a tuner.

5- Cross is being written again from new as we speak. But it may take some time before the new version can be released.

 

 

As PLi already supports a large number of EPG-formats, and Cross is open source, by far the best option would be to embed the Open-TV EPG format in PLi as well. That way the system would be as stable as possible, and EPG-data would always be up-to-date (provided the box is tuned to Sky every once and again).

[rtzhjgg0]

As PLi already supports a large number of EPG-formats, and Cross is open source, by far the best option would be to embed the Open-TV EPG format in PLi as well. That way the system would be as stable as possible, and EPG-data would always be up-to-date (provided the box is tuned to Sky every once and again).

[littlesat]

by far the best option would be to embed the Open-TV EPG format in PLi as well.

I agree.

But for us Dutchmans Open-TV EPG is not really interesting, especially when there are free plugins available who do the job and Reytec EPG is a good alternative.

 

Possibly someone of interest is willing to offer us a good patch. Please note OpenPLi is Open - Sources to emulate Open-TV EPG are also open. Someone who really use it on a daily basis can better code it.

[Rob van der Does]

by far the best option would be to embed the Open-TV EPG format in PLi as well.

I agree.

But for us Dutchmans Open-TV EPG is not really interesting, especially when there are free plugins available who do the job and Reytec EPG is a good alternative.

 

Possibly someone of interest is willing to offer us a good patch. Please note OpenPLi is Open - Sources to emulate Open-TV EPG are also open. Someone who really use it on a daily basis can better code it

Not sure who 'us Dutchamans' is, but PLi is used by an international user-group.

 

And speaking for myself I must say I watch more English then Dutch TV. So for 'this Dutchy' it would be welcome (and I'm pretty sure I'm not the only Dutch guy to whom that applies).

[WanWizard]

Indeed. Make that two.

[pieterg]

There are several epg readers waiting to be included in e2, but my personal opinion is we should first sort out the epgcache, before adding any more readers.

[Rob van der Does]

I know you find the present EPG-cache not optimal (which is probably correct), but adding extra readers won't bring in more EPG-data (only from a different source).

Or is it about manpower-planning?

[pieterg]

Bit of both.

Adding new readers means a lot of code duplication, at the moment.

[SpaceRat]

Actually, there are people that highly prefer CrossEPG over xmltv-Import.

Me for example.

 

I've noticed many times that the Rytec XMLTV files contained some kind of data that made E2 crash, while the XEPGDB repacked Rytec data of the same day didn't cause the same crash.

Also, from a technical point of view the idea of having millions of STBs parse raw xml data, rather than pre-packing them once (into XEPGDB format for example) sounds stupid.

 

So as long as XEPGDB repacked Rytec data is available, I'll keep using that.

[gorski]

Sadly, from my experience (EX-YU channels, mainly), XEPGDB is seriously incorrect way too often...

[Pr2]

...

I've noticed many times that the Rytec XMLTV files contained some kind of data that made E2 crash, while the XEPGDB repacked Rytec data of the same day didn't cause the same crash.

Also, from a technical point of view the idea of having millions of STBs parse raw xml data, rather than pre-packing them once (into XEPGDB format for example) sounds stupid.

 

...

 

Did you report the Rytec Data data that made crash your E2? I never encountered so far this problem. And if you really encountered this problem please report it so Rytec team can check what happens... but perhaps that the crash that you have came from... CrossEPG...

 

millions STBs don't parse raw xml data, the xml data is structured it just "send in memory" the data that you need to have.

XEPGDB is also send in some way into the STB memory, so no difference it is just the format that is different to achieve the same goal. So what is the advantage of XEPGDB?

You always need to have a source to feed the internal EPG, the format of the source file doesn't matter.

So in both case millions STBs need to download the data somewhere and process it...

[Rob van der Does]

And the problem is the way Cross handless the data-parsing process: that's a very memory hungry process (compared to XMLTV-importer) and low-spec boxes (such as the Solo) can't handle that without an active swap-file. And even then it's quite often a problem.