- experimental support for MtkChannelList.xml (which is part of several MediaTek based Google TVs, e.g. Philips formats 120 and 125)
- Philips formats 100-125: improved decoding of non-latin characters (turkish, cyrillic, ...)
if(majorVersion==1||majorVersion==2||majorVersion==30||majorVersion==45)// || majorVersion == 11 // format version 11 is similar to 1.x, but not (yet) supported
Onka does not update chanLst.bin (which isn't required when only DVBS.xml is modified since that file has no checksum in chanLst.bin)
Nevertheless a user reported that swapping DVB-S channels 1 and 2 with Onka on a TV that uses this xml-only format 110 worked for him.
There seem to be 3 different flavors or the "100" format:
There seem to be 3 different flavors of the "100" format:
One has only .xml files in the channellib and s2channellib folders, does not indent lines in the .xml files, has a fixed number of bytes for channel and satellite names (padded with 0x00), has no "Scramble" attribute and values 1 and 0 for "Polarization".
And a version that has dtv_cmdb_*.bin next to the .xml files, uses 4 spaces for indentation, only writes as many bytes for names as needed, has a "Scramble" attribute and uses values 1 and 2 for "Polarization".
While the first seems to work fine when XML nodes are reordered by their new programNr, the latter seems to get confused when the .bin and .xml files have different data record orders. This is still under investigation.
DVB-T and DVB-C share the same number range, so they are treated as a unified logical list
Version 120 and 125 (MediaTek platform for Google TVs) contain an additional MtkChannelList.xml file, which is also used by other brands.
This file contains both a readable channel list as XML as well as a base64 encoded Java serialized Blob containing a cl_Zip compressed/encrypted binary channel list.
A separate Loader module is used for this file to keep data in-sync.
var favNumber =ParseInt(child["FavNumber"].InnerText);
//var favNumber = ParseDecimal(child["FavNumber"].InnerText); // this is a Decimal like "1.5" when the previous "0" was moved behind "1", which makes the new list start at 1 instead of 2
if(input==null||!input.StartsWith("0x"))// fallback for unknown input
returninput;
// according to https://github.com/PredatH0r/ChanSort/issues/347 Philips seems to not use UTF 16, but instead use locale dependent encoding and
// writing "0xAA 0x00" to the file for an 8 bit code point. At least for the favorite list captions. Congratulations, well done!
// The Philips encodes names is a complete mess.
// Each character is represented as two bytes, with the low byte first and the high second, but this isn't utf16.
// All observed files have the "high" byte always as 0x00
// If looking only at the odd bytes, this can either be encoded in some random locale, a valid utf8 sequence or 1 byte characters mixed with big-endian utf16 double-bytes characters.
// according to https://github.com/PredatH0r/ChanSort/issues/347 Philips seems use a locale dependent encoding for favorite list names,
// writing "0xAA 0x00" to the file for an 8 bit code point. Congratulations, well done!
// In version 120/125 umlauts in channel names are encoded as 1 byte CP-1252/UTF16 code point + 0xFF as the second byte (i.e. for "Ä" it is 0xC4 0xFF instead of 0xC4 0x00)
// Also: 0x62 0x00 0x65 0x00 0x49 0x00 0x4e 0x00 0x20 0x00 0x01 0x00 0x30 0x00 0x5a - here 0x01 0x00 0x30 0x00 refers to U+0130 (the upper case I with dot), in "beIN İZ"
// https://github.com/PredatH0r/ChanSort/issues/421: 0x38 0x00 0x20 0x00 0xD0 0x00 0xBA ... seems to contain cyrillic UTF-8 encoding in channel names instead of UTF-16
// In version 120 umlauts in channel names are encoded as 1 byte CP-1252 (= low byte UTF16) code point + 0xFF as the second byte
varhexParts=input.Split(' ');
varbuffer=newMemoryStream();
varutf16=newMemoryStream();
varutf8=newMemoryStream();
boolhighByte=false;
boolinvalidUtf8=false;
bytebigEndianUnicodeHighByte=0;
intbigEndianUnicodeIndex=-1;
foreach(varpartinhexParts)
{
if(part=="")
continue;
varval=(byte)ParseInt(part);
invalidUtf8|=highByte&&val!=0;
if(highByte&&val==0xff)// hack-around for version 120
val=0;
buffer.WriteByte(val);
if(bigEndianUnicodeIndex>=0)// special handling when a character < 32 was detected, which means we have a messed up "HI 00 LO 00" encoding for an UTF16 character (where HI is < 32)
{
++bigEndianUnicodeIndex;
if(bigEndianUnicodeIndex==2)
{
utf16.WriteByte(val);
utf16.WriteByte(bigEndianUnicodeHighByte);
bigEndianUnicodeHighByte=0;
}
elseif(bigEndianUnicodeIndex==3)
bigEndianUnicodeIndex=-1;
}
else
{
if(!highByte)
{
if(val<32&&val!=0)// a char < 32 is likely the high byte of a "HI 00 LO 00" encoded UTF16 character
// It is unclear whether XML nodes must be sorted by the new program number or kept in the original order. This may be different for the various format versions.
// Onka, which was made for the ChannelMap_100 flavor that doesn't export dtv_cmdb_2.bin files, reorders the XML nodes and users reported that it works.
// The official Philips Editor 6.61.22 does not reorder the XML nodes and does not change dtv_cmdb_*.bin when editing a ChannelMap_100 folder. But it is unclear if this editor is designed to handle the cmdb flavor.
// A user with a ChannelMap_100 export including a dtv_cmdb_2.bin reported, that the TV shows the reordered list in the menu, but tunes the channels based on the original numbers.
// It's unclear if that happens because the XML was reordered and out-of-sync with the .bin, or if the TV always uses the .bin for tuning and XML edits are moot.
// On top of that this TV messed up Umlauts during the import, despite ChanSort writing the exact same name data in hex-encoded UTF16. The result was as if the string was exported as UTF-8 bytes and then parsed with an 8-bit code page.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.