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). Lucian _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
