I've succeeded in getting Chinese EPG (specifically from SG Starhub) on OpenPLi 2.1 & enigma2, and I thought I share what I found and did. I'm a newbie on the scene so don't take what I say as the absolute truth. I'm still investigating and learning.
Side note: I understand cnigma2 (created by
http://freedmx.net/?79) is a mod of enigma2 to support Chinese, but all I can find are .nfi binary images. Called me paranoid but I simply don't trust software from the scene without source code. (This is the reason I chose OpenPLi in the first place.)
-- Part 1 --
Now, embedded in the DVB streams is something called DVB-SI (service information), which I read up @
http://www.dvb.org/technology/standa...468v1.12.1.pdf.
Using dvbsnoop (see
dvbsnoop - A DVB Stream Analyzer Tool, Example: Event Information Table for EIT (event info table) examples), for a Chinese programme, I see SH broadcast two short event descriptors (see section 6.2.37), one for English and one for Chinese. The ISO639 lang code for Chinese is "chi".
For non-English (or non-Latin lang), the "event_name_char" and "text_char" are to be encoded as specified in Annex A.
In Annex A.2, it says that if the
first byte is less than 0x20, it denotes the encoding to be used, otherwise it is normal data.
SH violates this aspect. When the data is Chinese, it is sending it as UTF8
without putting a extra "0x15" byte (see table A.3) in front. Our STB, adhering to the spec, (including dvbsnoop) simply assumes it is normal data and uses Latin charset (ISO8859) to display it.
Example: The character "ju" is, as shown in
Unicode codepoint lookup/search tool is encoded by three octets: 0xe5 0x89 0xa7. If the STB is aware they're UTF8, it will display these three octets as a single character; if it doesn't it will display these three octets as three separate characters, which is the case currently.
-- End of Part 1 --
Bookmarks