DM920: Picon display infobar dvb-t

  • As discussed in dm900/920 section it seems that there is a problem showing picon of dvb-t channels using default skin dreamOs.
    The problem is related to namespace of dvb-t channels which is different from default 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.


    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


    I attach enigma2.log created with


    journalctl -f -u enigma2 > /data/enigma2.log


    before changing channel.

  • I have now found some time to check also the plugin.py from EPGImporter Plugin.


    It uses the below Channel Filter logic to assure to load EPG data only for Channeles that you have in use on your box:

    Code
    def channelFilter(ref):                                        
       channel = ServiceReference(str(ref)).getServiceName()                           
       if len(channel) > 0:                                                               
          print "[EPGimport] found channel %s" % (channel)                                
          return True                                                             
       return False

    And NO, this is not the original one, but their code with Fake Recordings to find out if a channel is existing was so ugly, and would not work here either.


    The problem is that it looks like the ServiceReference class is NOT ignoring the values after :EEEExxxx


    This means it returns ONLY a Name if the xxxxx are the ones that you call 'strange' (but we explained that they are usefull) if you pass the EEEEE00000 and instead you have xxxxx in your lamedb it will faill and not return a ServiceName and hence these Channels will be ignored in the import.


    The question is now if I should spend time to build uply workarounds at various places (and I try to avoid to change EPGImporter Plugin as much as possible) or if Ghost would be so kind :red_heart: to make the ServiceReference Class which probably uses an eService* from closed soure C++ part of enigma2 internaly for the lookup also so clever to return the proper Service name if EEEEE00000 is passed.


    Probably there are more cases like this, but this was the first and obvious that I found and yes, I can reproduce the Problem caused by this also with my local DVB-T2 channels.

    6 Mal editiert, zuletzt von Lost in Translation ()

  • Feel free to change, but there are more places like this in the code.


    The problem is that the original EPGImporter code is that ugly:


    grep try: *.py | wc -l
    57


    This means I would need to rewrite a good part of the plugin, which I'm simply NOT willing to do, especially after the discussion I had around the source files.


    The current Version of the plugin for DreamOS that I had to create now 3x despite my complaints that somebody else could do it better contains only the bare necessities of life to make it work with DreamOS and the original work was ONLY done to proove that it is realtively simply to adapt the actual loading part to the epg.db of DreamOS. Which means the epgdb.py instead of epgdat.py is the only really contribution from my side and as it works as it should I would like to stop here


    All the Rest I did only when it was really needed (or so ugly that I could not stand it - ike their channelFilter).


    Therefore feel free to fix or change it and I probably can add some help and guidance, but I'm nor really motivated to do it myself.


    Technically as Ghost pointed out it should be sufficient to fix nothing but copy the EEEExxxx also to EEEE0000 channels in the lamedb, then because of the internal trucating of the dvbnamespace the load should work and also the EPG should be shown for the channels with the EEEExxxx dvbnamespace.


    But is your decisions, I only checked the code to understand what happens and what is needed to make it work.

  • Thanks, because as I explained it is not just a problem at the place I pointed out.


    A Q&D workaround only for the example I posted owuld be to add 2 code lines like this:


    if channel.find(":EEEE") if not -1:
    return True


    But the you will hit the next place and do more and more patches, etc...


    At the moment except the epgdb.py there are only a few and they are is not difficult to find, just search


    grep dpkg/status *.py | wc -l
    4

    • Offizieller Beitrag

    To patch automatically all 0xEEEEXXXX to 0xEEEE0000 .. or to try it makes no sense. With that I break the functionality that should be achieved by using the namespace. What I can offer is an eDVBDB.getInstance (). SearchReference (int tsid, int onid, int sid, int dvbnamespace, int dvbnamespace_mask = -1) function ... so that you can then look over the mask to see if there is a matching channel, currently the function is not exported to python. There will be a new tarball in the days. There I can take it in then.

  • yes this would be nice, because then the code cange would be simplier. As it was pointed out - the problem was ignored for such a long time, now it doesn't matter when it takes a few days more.


    BTW it is now almost X-mas time and we ALL should do other important things :smiling_face_with_heart_eyes:

  • What I can offer is an eDVBDB.getInstance (). SearchReference (int tsid, int onid, int sid, int dvbnamespace, int dvbnamespace_mask = -1) function ... so that you can then look over the mask to see if there is a matching channel

    Nice and useful.
    +1

  • To patch automatically all 0xEEEEXXXX to 0xEEEE0000 .. or to try it makes no sense. With that I break the functionality that should be achieved by using the namespace. What I can offer is an eDVBDB.getInstance (). SearchReference (int tsid, int onid, int sid, int dvbnamespace, int dvbnamespace_mask = -1) function ... so that you can then look over the mask to see if there is a matching channel, currently the function is not exported to python. There will be a new tarball in the days. There I can take it in then.

    @Ghost
    Any news about the new method SearchReference?
    Thanks

  • To patch automatically all 0xEEEEXXXX to 0xEEEE0000 .. or to try it makes no sense. With that I break the functionality that should be achieved by using the namespace. What I can offer is an eDVBDB.getInstance (). SearchReference (int tsid, int onid, int sid, int dvbnamespace, int dvbnamespace_mask = -1) function ... so that you can then look over the mask to see if there is a matching channel, currently the function is not exported to python. There will be a new tarball in the days. There I can take it in then.

    Ok. searchReference is in the last enigma2 commit.
    @Ghost could you do an example of call searchReference?
    All function parameters are int while I suppose ref in epgimport is a string.
    I tried to convert the various parameters got splitting the ref to int with int(X, 16) but I got this error:


    OverflowError: in method 'eDVBDB_searchReference', argument 5 of type 'int'


    Thanks

    Einmal editiert, zuletzt von spinmar ()

  • you have to unterstand what part of the servicereference is representing what ...


    Look for example at the Q&D code of my epgdb.py used in EPGImporter and OpenEPG Plugin:

    Code
    channel = ServiceReference(str(service)).getServiceName()
    ssid = service.split(":")
    # convert hex stuff to integer
    self.sid=int(ssid[3],16)
    self.tsid=int(ssid[4],16)
    self.onid=int(ssid[5],16)
    self.dvbnamespace=int(ssid[6],16)
  • Could be the unsingned vs. signed integer problem when you have a cable reference with FFFF0000, for this I included in epgdb.py:


    Code
    dvbnamespace=int(ssid[6],16)
    if dvbnamespace > 2147483647:
         dvbnamespace -= 4294967296
  • I wrote a test plugin to try searchReference method (I prefered to do this before changing EPGImport plugin) but as I wrote above I always get OverflowError.
    This is the code of plugin generating the error:


    Code
    ref = '1:0:1:218C:4:13E:EEEE0204:0:0:0';
    ssid = ref.split(':')
    sid=int(ssid[3],16)
    tsid=int(ssid[4],16)
    onid=int(ssid[5],16)
    dvbnamespace=int(ssid[6],16)
    if int(ssid[0]) == 1 and (dvbnamespace & 0xFFFF0000) == 0xEEEE0000:
            if dvbnamespace > 2147483647:
    		dvbnamespace -= 4294967296
    	channel = eDVBDB.getInstance().searchReference(tsid, onid, sid, dvbnamespace, int('0xFFFF0000', 16))

    The ref is the a RAI HD channel of italian DVB-T.
    The call to searchReference generates a crash of enigma2:


    .............
    0xb4b6168c(sp=0xbec4bbd8) <PyEval_EvalFrameEx+24024>


    Traceback (most recent call last):
    File "/usr/lib/enigma2/python/enigma.py", line 7790, in __call__
    return ret(*args, **kwargs)
    File "/usr/lib/enigma2/python/Components/ActionMap.py", line 51, in action
    res = self.actions[action]()
    File "/usr/lib/enigma2/python/Screens/PluginBrowser.py", line 48, in save
    self.run()
    File "/usr/lib/enigma2/python/Screens/PluginBrowser.py", line 52, in run
    plugin(session=self.session)
    File "/usr/lib/enigma2/python/Plugins/Extensions/Test/plugin.py", line 30, in main
    channel = eDVBDB.getInstance().searchReference(tsid, onid, sid, dvbnamespace, int('0xFFFF0000', 16))
    OverflowError: in method 'eDVBDB_searchReference', argument 6 of type 'int'
    -------
    ]]>
    </enigma2crashlog>



    I tried to change the dvbnamespace mask to -1 with same error.
    @Ghost: could you tell us how to use the function?
    Thanks

    Einmal editiert, zuletzt von spinmar ()

  • well first you should rewrite it in a way that it works as before:


    def channelFilter(ref):
    strref=str(ref)
    # channel = ServiceReference(strref).getServiceName()
    ssid = strref.split(":")
    # convert hex stuff to integer
    sid=int(ssid[3],16)
    tsid=int(ssid[4],16)
    onid=int(ssid[5],16)
    dvbnamespace=int(ssid[6],16)
    if dvbnamespace > 2147483647:
    dvbnamespace -= 4294967296
    dvbnamespace_mask = -1
    searchedserv=eDVBDB.getInstance().searchReference(tsid, onid, sid, dvbnamespace, dvbnamespace_mask)
    channel = ServiceReference(searchedserv).getServiceName()
    rrr = ServiceReference(searchedserv)
    if len(channel) > 0:
    print "[EPGimport] found channel %s %s %s" % (channel, strref, rrr)
    return True
    return False


    At least this gives no overflows :grinning_squinting_face:


    Then you add your code for dvbnamespace_mask instead of the -1


    dvbnamespace_mask = int('0xFFFF0000', 16)


    The you get the overflow error again because of the unsigned int vs. signed int problem and add this below:
    if dvbnamespace_mask > 2147483647:
    dvbnamespace_mask -= 4294967296


    Then you add a print of the dvbnamespace_mask and see that it is shown as -65536


    So a simplier version of the mask would be:


    dvbnamespace_mask=-65536



    Which at least gives code which doesn't crash ... but doesn't filter correctly either :kissing_face:

    Einmal editiert, zuletzt von Lost in Translation ()

  • The problem is that searchReference always produces an OverflowError.
    Before rewriting channelFilter I wanted to be sure that searchReference is ok and understand how it works.
    Thanks

  • No it doesn't it just also has the singned integer problem and something starting with FFFFxxxxx is simply above 2GB,


    Try the codechanges that I suggested above - and the -65536 as 6th argument :winking_face:


    But off course Ghost could give more insight here :grinning_squinting_face: I only hate to give up too early :smiling_face_with_halo: