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