Strange dvb-t namespace

  • Hi,
    I'm using the latest unstable experimental image in DM920 with twin dvb-s and twin dvb-c/t2.
    I scan my italian dvb-t channels and all is working.
    But... we have a problem: the namespace of terrestrial channels.
    For example RAI 1 HD has service ref 1:0:1:218C:4:13E:EEEE0204:0:0:0 and you can see that it has namespace EEEE0204 whi is very strange (normal is EEEE0000).
    Why?
    The side effect is that epg import is not working on dm920.
    Rytec EPG Team wrote:


    "Try to find out why your receiver, makes these curious Namespaces (they are not normal). If you find the reason, correct that and you wil get EPG.
    But, I have no idea where you have to look for this. (probably in the /etc/tuxbox/terrestrial.xml file)"


    Where can I fix it?
    Thanks

  • this is intentionally to handle the possibility that you might receive on a location from different locations same channels, otherwise the servicereferences would be the same and would overwrite each other.


    when you live in the middle between 2 broadcast stations you would suffer without this DreamOS Feature. But DVB-T(2) normally has good EPG data, there should be no need for loading at all, simple EPG refresh plugin should do.


    BTW you seem not to use latest EPGImporter plugin either and ask for help at the wrong place...

    Einmal editiert, zuletzt von Lost in Translation ()

  • I download epgimport from your post on oozoon board.
    I supposed that it was the lastest version: am I wrong?
    DVB-T has no normal epg data in italy: in most of case only two events for channel.
    I tried epg refresh but it is not working well.
    How can I solve my problem?
    I'd like to use epg import.
    Thanks

  • @dhwz
    Can you explain a little more? :winking_face:
    I installed enigma2-plugin-extensions-epgimport - 1.0-r36.3: is it wrong?
    If EEEE0000 is used internally for epg and Picons for dvb-t is a problem because the namespace is EEEE0204.
    What am I missing?

  • EEEE0204 is only used for storing the service properly in lamedb, as gutemine explained we can propably receive two different frequencies with the same services. Thats why the frequency is calculated into the Namespace, if we don't do that one frequency is eliminating the services of the other frequency.

  • No there is something not clear.
    You and @gutemine are saying that EEEE0204 is only used for lamedb internally while for picon and epg is used EEEE0000.


    Example: Rai 4 (see screenshot).


    There is no picon in infobar while the picon is on fs:


    root@dm920:/data/picon# ls -la 1_0_1_2187_4_13E_EEEE0000_0_0_0.png
    -rw-r--r-- 1 root root 4375 Dec 11 22:00 1_0_1_2187_4_13E_EEEE0000_0_0_0.png


    If I rename the file replacing EEEE0000 with EEEE0204 the picon in infobar is showed.
    I suppose that I'm missing something.
    Can you help me to understand?


    PS: of course there is a sym link for picon:


    root@dm920:/data/picon# ls -la /usr/share/enigma2/picon*
    lrwxrwxrwx 1 root root 11 Dec 11 17:38 /usr/share/enigma2/picon -> /data/picon
    lrwxrwxrwx 1 root root 11 Dec 11 21:50 /usr/share/enigma2/picon_100x60 -> /data/picon
    lrwxrwxrwx 1 root root 11 Dec 11 18:43 /usr/share/enigma2/picon_130x80 -> /data/picon
    lrwxrwxrwx 1 root root 11 Dec 11 18:44 /usr/share/enigma2/picon_220x132 -> /data/picon
    lrwxrwxrwx 1 root root 11 Dec 11 18:44 /usr/share/enigma2/picon_50x30 -> /data/picon
    lrwxrwxrwx 1 root root 11 Dec 11 18:44 /usr/share/enigma2/picon_oled -> /data/picon

  • picon pickup depends on renderers which are often coming with skins. And no I didn't say that different serviceref doesn't matter.

  • Ok so for picons service ref is important and then the owners of dm920 have a problem with DTT because all picon packages use EEEE0000 ....
    I'll try to use epgrefresh to see if I'll solve my epg problem.
    I'll let you know.

    • Offizieller Beitrag

    Yes that's true. Even when querying the EPG database, only 0xEEEE0000 is used internally. And also the EPG collected on Air is always stored in the database for 0xEEEE0000.


    Say if an external tool collects and writes data to our EPG database it always have to use 0xEEEE0000 for DVB-T / DVB-T2 transponders.


    cya


  • @Ghost
    How can I log what happens?
    You are telling me that the problems I have in my dm920 are due to picon resolver and xmlimport engine.

  • @Ghost
    There is some problem in picon resolver because after the author of MetrixStyleHD skin told me that the problem is not in the skin, I tried to select Default FHD which is one of DreamOs default skin and I have always the problem.
    You have the test case in post 8.
    The picon with namespace EEEE0000 is on filesystem but it is not show in infobar.
    In share/enigma2 I have:


    root@dm920:/data/picon# ls -la /usr/share/enigma2/picon*
    lrwxrwxrwx 1 root root 11 Dec 11 17:38 /usr/share/enigma2/picon -> /data/picon
    lrwxrwxrwx 1 root root 11 Dec 11 21:50 /usr/share/enigma2/picon_100x60 -> /data/picon
    lrwxrwxrwx 1 root root 11 Dec 11 18:43 /usr/share/enigma2/picon_130x80 -> /data/picon
    lrwxrwxrwx 1 root root 11 Dec 11 18:44 /usr/share/enigma2/picon_220x132 -> /data/picon
    lrwxrwxrwx 1 root root 11 Dec 11 18:44 /usr/share/enigma2/picon_50x30 -> /data/picon
    lrwxrwxrwx 1 root root 11 Dec 11 18:44 /usr/share/enigma2/picon_oled -> /data/picon


    Let me know If you need something other information to solve the problem for dvb-t.
    Thanks

  • Probably I should have addet the Information here but now it is too late.


    DM920: Picon display infobar dvb-t


    The whole service Reference handling would probably need also some patching to be completely transparent, for example if I play a serviceReference with e2 and pass only EEEE0000 instead of the EEEExxxxx it will also fail when only EEEExxxxx is in the lamedb. But then we are back to what Ghost said ... it should be transparent ... but it is not ... everywhere, so there seems to be some more work to be done - not only on the picon lookup code :loudly_crying_face:

    Einmal editiert, zuletzt von Lost in Translation ()

  • Not really, as I explained in the other thread - it is possible to workaround in the EGPImporter code, but I prefer NOT to create more uply code as it has already. I tweaked it as good as I could without rewriting a lot, and then I decided to stop here and I don't want to revert my decision.


    Most DVB-T(2) Providers have good EPG Data, for example I had to unplug my DVB-T antenna to prevent from getting EPG over the air to be able to easily reproduce the loading failure.