Hi,
So far, all the NameSpace that I saw for a service always represent a positive value for the orbital position.
So
19°2 East is represented as: 192 = 0xC0 (C00000)
-5°0 West is represented as: 3600-50 = 3550 = 0xDDE (DDE0000)
But it seems that Dreamset application is generating a ServiceName which support the negative orbital position in hexa value:
So
-5°0 West is represented as: 0xFFCE (FFCE0000) by Dreamset.
But this leads to problems for picons by service reference and mostly EPG data linkage since for the same channels on Western satellites we can have 2 differents namespace for the same channels.
For EPG data the service name reference always use the positive hexa representation, so my first idea was that it must be EPGimport that needs to handle both.
But thinking deeper on it, I now think that it will better if Enigma2 handle this since this impact both EPG and Picons by service reference.
So my questions are:
- Does the negative name space are really valid one according to "standard" of lamedb?
- If so, shouldn't Enigma2 turn those negative values into their positive equivalent, in order to have a unique and coherent representation of the namespace in the lamedb with one really unique namespace for every possible channels.
Dreamset can also be updated to generate the positive value (I am not the Dreamset developper and I never use it), but anyway this pinpoint a potential problem.
Pr2