81 replies to this topic

[jpuigs]

@Huevos, there is a problem with special characters (spanish ones, f.i.)

look at the picture , radio channels are really named:

 

RNE Cataluña

Radio 5 RNE

Ràdio 4 RNE

 

 special_char_problem.png   237.09KB   6 downloads

 

It happens with your original plugin.py file too.

 

[jpuigs]

Or add a different screen with more detail at a color button after you see the overview of just scanned services...

 

Please, check this one.

 

 plugin.py   39.23KB   8 downloads

 

The problem I don'r know how to fix, is what I told in previous post => Names with special chars.

I think that the dvb list output format should be converted to ??? UTF-8 ??? ISO 8859 ????

[Huevos]

 

Or add a different screen with more detail at a color button after you see the overview of just scanned services...

 

Please, check this one.

 

plugin.py

 

The problem I don'r know how to fix, is what I told in previous post => Names with special chars.

I think that the dvb list output format should be converted to ??? UTF-8 ??? ISO 8859 ????

 

Can you give me the transponder details.

[jpuigs]

It happens with more DVB-T signals than DVB-S.

 

But you can look at:

Astra 19º 11156 V 22000 5/6  , channel named: M. Cine Español

Astra 19º 10876 V 22000 5/6  , M. FÚTBOL

Astra 19º 11317 V 22000 5/6  , M. ACCIÓN

[Huevos]

Proper way is to read the (optional) character encoding from the SDT. 98% of the time it would be latin-1 or missing.

 

Once you have that you just decode and then encode to utf-8.

 

The following patch assumes the encoding is latin-1.

 

https://github.com/H...4cb0de4492d23cc

[jpuigs]

works.   Thanks,

I thought it was something related to UTF or/and ISO8859-1, because if you look at the modified code (you'll see that there are 3 commented lines (#) , which I made to save into a file the "screen" output, and that file showed those regional characters correctly.

Then I looked at lamedb file, and inisde it I saw that names for those chanels were encoded to UTF8 ¿?

 

I supose that when scanning (manual or background), the scanner will do what you say: read (if found) the character encoding on SDT, decode according to it, and encoding to utf-8 to be inserted into lamedb file.

 

 

@littlesat , will you now apply to openpli ?

Edited by jpuigs, 13 December 2017 - 01:16.

[Huevos]

works.   Thanks,

I supose that when scanning (manual or background), the scanner will do what you say: read (if found) the character encoding on SDT, decode according to it, and encoding to utf-8 to be inserted into lamedb file.

 

 

@littlesat , will you now apply to openpli ?

Yes the scanner in E2 but not in ABM. Should be added but all the current providers use the western alphabet so that was never needed. And yes, everything is utf8 encoded before being written to lamedb or bouquets.

[Huevos]

works.   Thanks,

@littlesat , will you now apply to openpli ?

I doubt it because the reader is not native in E2. That was the whole point of this thread. i.e. making the TSID, ONID, and OrbPos available in the convertor (real ones, not fake ones from lamedb). That way this could work without the code in Satfinder, and just by editing the skin.

Edited by Huevos, 13 December 2017 - 10:08.

[littlesat]

As far I remember Huevos patch requires ABM to parse the transponder information...A separate .so file (and probably more) is used here.

To keep structure in the software I think we should only these kind of work-a-round patches

I think the transponder information 'parser' should be embedded into the E2 binary... (with also using the helpfill libraries that are already included).

[WanWizard]

All the so file in ABM does is enumerate the NIT or SDT in a python list, I guess for performance purposes. All the processing is done in python.

 

The source of that so is included in the ABM repo. I think if not already present it would be handy to include a generic method in E2 that can be used.

 

See https://github.com/o...lib/dvbreader.c

[Huevos]

All the so file in ABM does is enumerate the NIT or SDT in a python list, I guess for performance purposes. All the processing is done in python.

 

The source of that so is included in the ABM repo. I think if not already present it would be handy to include a generic method in E2 that can be used.

 

See https://github.com/o...lib/dvbreader.c

More or less, except the output is a Dict.

 

But what I wish were possible is TSID, ONID, and OrbPos were available in the convertor. Right now SNR, AGC, BER, tuner masks, etc. are available and possible to push to the display just by editing the skin. It would be nice if this was also available for TSID, ONID, OrbPos too.

Edited by Huevos, 13 December 2017 - 13:59.

[WanWizard]

I meant "a list of data", not the Python data type, trying to make it understandable for non-programmers. Technically, you're absolutely right.

[jpuigs]

As far I remember Huevos patch requires ABM to parse the transponder information...A separate .so file (and probably more) is used here.

 

Not 100% true.

As I said in previous posts I do not have ABM installed, I just "took" the .so file, and placed it in the same SatFinder folder.

Then I changed on line 22

from Plugins.SystemPlugins.AutoBouquetsMaker.scanner import dvbreader

to just

import dvbreader

and edited skin xml file to include new yellow button and TSID and ONID values.

 

That's all.

[littlesat]

But you still have the seperate so file...

[jpuigs]

... and what's the problem ?

[littlesat]

When the so is interrogated in the binary of E2 satfinder can use it, ABM can use it, and anywhere else it can be used without adding a separate .so.... it can be used as kind of 'dvbsnoop' to do even give more details in different places.... 

 

Having a separate .so is so like the old DMM plugin time where DMM was not willing to add usefull stuff in the E2 binary... so the plugins had to work-a-round stuff....

To parse TSNID, ONID etc... I thought also a lot of intelligence is already included in E2 by using a specific library. So some of the code does not need to be duplicated in python.

Edited by littlesat, 13 December 2017 - 15:20.

[Huevos]

... and what's the problem ?

1) There is a lot more in the .so than is needed to get the info we want here.

2) If done in enigma the data would be pushed on change (like tuner mask), and would not need polling in Satfinder.

Edited by Huevos, 13 December 2017 - 16:23.

[littlesat]

1. Yep you;re right. But for e.g. other scanning (also fastscan) special libraries are also used to do some encoding...

2. I think pushed on change is also better then polling...

[WanWizard]

That is why I said that it would be logical to have low-level "scan" methods in E2, since the result is clearly required in different places. Including the traditional scan.

[jpuigs]

So, the right thing would be to take the necessary parts of dvbreader.c and include them into Enigma 2.

Who will do it ????