Reply to thread

Message: <blockquote data-quote="Vasilich" data-source="post: 1052605" data-attributes="member: 97516">completely forgotten about that one, sorry. I am short in time currently, so i will try to answer all your questions/comments, but shortly.you've put it mildly <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile    :)" loading="lazy" data-shortname=":)" />exactly.not completely - in getString468A we have on lines 120-121 of trunk[CODE=c++]        text[textIndex] = 0;        bufIndex += 2;[/CODE]so on this part textIndex wasn't changed and is =2, and  bufIndex was increased from 0 to 2. This means that next char is the last, third byte of our 3-byte encoding, and just 2nd byte (=0) was replaced with 3rd one, so 0x10 0x00 0x02 [text] will be saved as 0x10 0x02 0x02 [text]. I can confirm this behavior as this is what i have seen while debugging - many polish channels (that i am able to receive) use exactly this encoding.yes, there are 2 serious flaws in this code:1. wrong place to do the decoding (we have dedicated function to decode this)2. all czech EPG will be decoded using this ISO6937, independently of encoding sent by provider.while i can understand that it can fix the encoding for some szech providers sending wrong encoding, it is still a hack.Moreover, EN468 says that code table 00 isn't  exactly ISO6937 - Euro sign is added (i fixed this locally - let me know if you are interested)yes, another hack.As I see it:we should first fix TsWriter code to pass proper encoding bytes to TVLib,then remove hacks with czech and rus/ukr/bel owerwriting,and pass received language code to Convert() function.then implement all possible encodings in this function.Only then we can think about bad providers - my idea was to read combination of NID/TSID/SID from XML file, and this XML file should be filled only by experienced users, as the problem is that these bad providers often use NID that is not intended to use by them (i have often seen NID=0x01 for those providers gurabli uses) and on different sattellites we can have same NID for different providers. Yes, i hate things that do not conform standards, but we have to live with them and try to workaround *some* of inconsistences (surely developers of software for STBs also have to deal with those, and i am almost sure they also have kinda exclusion/override tables for some providers).The problem for gurabli is that he receives several providers, and while some are conform to DVB standards (UPC Direct), others are not. Sadly our code handles DVB-conform encoding wrong, but overrides wrong encoding  - the last part i am still not understand completely how it comes that ISO8859-2 decodes properly as ANSI for hungarian (CP1252) - these tables are different. Hopefully i will get some time in next 2 weeks to understand how it can be.</blockquote>

Verification