EPG Import mod from Dorik1972 Support Thread

There are 442 replies in this Thread which was already clicked 53,841 times. The last Post () by jazzyman.

  • 1. you may select all known options to download and choose "load EPG only services in bouquets" that make the job.

    2. do not understand what you mean. EPG is in local language of provider, so you would like to use some google translate or so. simply export and try to make translation, which probably destroy sense of information

  • 1. you may select all known options to download and choose "load EPG only services in bouquets" that make the job.

    2. do not understand what you mean. EPG is in local language of provider, so you would like to use some google translate or so. simply export and try to make translation, which probably destroy sense of information

    Indeed I select bouquets option but prior this step you have to select the resources for download, you have over 102 xmltv files, which group you have to select, at least limit it to your available sat.


    For the second point, yes, I was refer to such kind of translation, there are a lot of efforts to translate epg data by almost all kind of plugins, so why not to translate the incoming data at origin?

  • 1. Add option to select the downloaded epg based on sat not on country? For example, if user download know what is the languages, countries etc, just select the sat he had, hotbird 13 as example and the plugin automatically select the best resources match with his selection.

    Who forbids you to create your own source file with the set of EPG sources you need ?


    2. Epgimport is the first step in epg data collection, and working mainly as background process, so it is possible to add automatic translation option to incoming data prior store it in epg.dat? So user can select a specific language and the system translate. (may be this is not working idea but it just idea)

    No. And why it will not be implemented I explained to you on another forum thread. I won't repeat myself - read it again in the HistoryZap thread

  • For the second point, yes, I was refer to such kind of translation, there are a lot of efforts to translate epg data by almost all kind of plugins, so why not to translate the incoming data at origin?

    What don't you understand in the answer already given to you on this subject? - RE: History Zap Selector for OpenPli (6.x-9.x) © Dorik1972

  • For the second point, yes, I was refer to such kind of translation, there are a lot of efforts to translate epg data by almost all kind of plugins, so why not to translate the incoming data at origin?

    To translate EPG info in HistoryZap I have done everything that is acceptable ... Including translation in SecondInfoBar in any image on any skin - RE: History Zap Selector by ©Dorik1972 . What else is missing and what is the need to translate the entire EPG ... from which you will only view what you will view and not all 500 000+ records that may be contained there

  • Who forbids you to create your own source file with the set of EPG sources you need ?

    I am not looking for a new source, I am thinking in new filtering way for the current sources,


    No. And why it will not be implemented I explained to you on another forum thread. I won't repeat myself

    No needs to repeat it, just expect to find different mechanism, you said epg.dat is temp and dynamic data file, so I turn my mind to previous level, may be it wrong but again it thought to share, may be lead to different thinking way.



    from which you will only view what you will view and not all 500 000+ records that may be contained there

    For this reason I suggested new filtering way such as sat filter, but anyway it look bad idea,

  • I am not looking for a new source, I am thinking in new filtering way for the current sources,

    Do you understand exactly how this works? Filtering some value is always a search in all records ... Yes! There are mathematical algorithms to speed up the search, for example, the half-division method... But everything that can be applied in terms of speeding up the import of EPG events is already applied in this plugin



    No needs to repeat it, just expect to find different mechanism,

    I have already explained to you ALL possible mechanisms including the local option ...

  • Hi, since a few days ago I started to experience problems with the old EPG import 1.0 the EPG was not loading correctly as it appeared and disappeared as I was passing over the channels, then I uninstalled the old EPG IMPORT plugin and the satellite EPG was back to normal.

    And as I found this thread with the modified and improved EPG IMPORT I downloaded the *.deb 1.9.1 version but actually and although my decoder says that it was installed correctly, the plugin doesn't appear.


    My decoder is a DreamOne, Dream-Elite 7.1 based on DreamOS oe2.6.


    How can I install the "EPG Import mod from Dorik1972"?

    Thanks for the help and best regards to the forum.

  • pepsik Is there some function built in which removes every whitespace (line breaks, tabs, multiple spaces, ...) from the "desc" (description) key from the epg xml file? I've tested "thousands variants" to bring in some new lines/line breaks/paragraphs into the description but no chance - they all get removed when I view the epg info after I imported my epg.xml source with v1.9.1 epgimport_mod


    (using pure2 v7.3 image)

    Edited once, last by jagg ().

  • Is there some function built in which removes every whitespace (line breaks, tabs, multiple spaces, ...) from the "desc" (description) key from the epg xml file? I

    In this plugin - no ... But in e2m3u2b when importing EPG all descriptions are "normalised" and there are removed unnecessary spaces, tabs, and all "unnecessary" HTML characters.


    You should also take into account that different images also contain "normalisers" of the output text of descriptions in their renderers for the used skins ... That way, any additions you make to "paragraphs", "indents", etc. can be "excluded" by the renderer code of the skin you are using when you output this information

  • I've asked because this happens to all sources I import with epgimport (my source XML, rytec).


    But when I'm not using epgimport to get the epg infos but using EIT-EPG - in these epg descriptions from EIT there are line breaks/paragraphs (!) which makes reading longer description texts or acters listings etc way more easier.


    So how can EIT have it in? When skin renderers cutting this out shouldn't this also effect EIT epg infos?


    Thanks

    Edited 2 times, last by jagg ().

  • in these epg descriptions from EIT there are line breaks/paragraphs (!) which makes reading longer description texts way more easier.

    The thing is that EIT-EPG contains several fields to describe the event

    1) Short description (usually contains information about the director, actors, category of the programme, etc.)

    2) Long description - this is the "plot description".


    What you see is what you think of as "paragraphs" or "indents". ... Because that's how they're rendered in the skin you're using.


    The XMLTVs that are used for EPGImport mostly contain only a description ... and it's almost always planar and without any dropdowns or paragraphs ...


    But, I repeat, everything you see on the screen is in 90% of cases the logic that is implemented in the skin you are using

  • What is 'short description' exactly (tag name)?

    I know that enigma2 uses only these tags from the epg XML file: title, sub-title and desc


    Is 'short description' you mention above an extra tag?

  • Is 'short description' you mention

    If we are talking about EIT(Event Information Table) and EPG, it is not me, not Enigma2, but the standard is ETSI EN 300 468.:beaming face with smiling eyes: Please google and read the following sections of this standard:

    5.2.4 Event Information Table (EIT)

    6.2.15 Extended event descriptor

    6.2.37 Short event descriptor



    If we are talking about trying to interpret data from XMLTV when transforming it to conform to a standard ETSI EN 300 468 then the values of the following tags are treated as:

    sub-title = short description

    descr = extended descriptor


    But once again I want to emphasise that everything you see on the screen, in that shape and form, depends on the skins you use

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!