Klaus Schmidinger wrote:
> On 03/26/08 13:39, Lucian Muresan wrote:
>> Klaus Schmidinger wrote:
>> [..]
>>>>>> Please try setting VDR_CHARSET_OVERRIDE=ISO-8859-9 before starting
>>>>>> VDR. This should fix it.
>>>>> This is fixed !
>>>>> Thank you.
>>>> Looks like this is set globally, for all of the epg data, right? What 
>>>> about mixed charsets from different providers (I know for sure there 
>>>> are, and there are also the "external" data sources like tvmovie2vdr and 
>>>> the like fetching some xmltv listings and injecting the data via SVDRP)?
>>> The DVB standard provides for a way to mark text strings, so that
>>> applications can correctly determine the actual encoding. The
>>> VDR_CHARSET_OVERRIDE is just a workaround in case your "main"
>>> provider fails to correctly encode their strings.
>> Am I missing something, is there a way to mark a provider as being my 
>> "main" one? Or is the workaround rather replacing the character set for 
>> all incorrectly recognized ones (assuming that the application 
>> determines the fact that it is incorrect)? If the latter case occures, 
>> what if there are several providers not marking the encoding right, but 
>> their epg content actually need different encodings, will they all use 
>> the same encoding specified in VDR_CHARSET_OVERRIDE? (This reminds me of 
>> the early UTF-8 patch which required setting the encoding for every 
>> channel in channels.conf, which of course is ugly, but could handle 
>> different EPG encoding needs in case of multiple providers failing to 
>> mark this correctly).
> Well, first and foremost providers should actually do their homework
> and encode their stuff according to the standard.
> The problem is with providers who don't add a codeset marker to their
> strings. This is ok as long as they actually encode in ISO6937.
> Unfortunately some providers use ISO-8859-9 instead (or maybe even
> others). With VDR_CHARSET_OVERRIDE set, all strings that are not
> explicitly marked as using a specific codeset are assumed to be
> encoded in the way given by VDR_CHARSET_OVERRIDE.
>>> External data source simply need to provide the strings in the
>>> encoding used on your local system (presumably UTF-8).
>> So it should work in the case of correctly handling external data, thanks.
>> BTW, OSD then stays unaffected by VDR_CHARSET_OVERRIDE? It might be 
>> worth renaming this to something more clearly specifying that it only 
>> affects EPG.
> This was just a last minute quick workaround (initially this was hardcoded),
> since some (esp. Czech) providers actually do encode their strings in
> ISO6937, and I didn't want to cause problems with those who do adhere to
> the standard.
> An elaborate workaround would probably require a separare file
> in which transponders can be marked as using a specific default
> codeset (and then VDR_CHARSET_OVERRIDE would vanish again).
> But it would be so much better if these providers would just follow
> the standard! Yes, I know, these are multi million dollar enterprises,
> so they can't be bothered with "standards" - oh well...

You're so right about these providers :-). Thanks for enlightening on 
the current state of this workaround. Maybe, if proven necessary, the 
extra file concept will be not too difficult or "unclean" to implement 
(possibly as a patch by someone else, myself not excluded).


vdr mailing list

Reply via email to