This is now possible at 4 levels:
1. The global defaults (for known bad muxes)
2. The network
3. The mux
4. The service
Such that 4 overrides 3, overrides 2, etc...
Canal + uses it's own encoded guide. But info for Current-Next program is delivered using standard EPG DVB-S method. But it doesn't indicate correctly the encoding used (latin) so TVH shows information assuming UTF-8 and this doesn't show correctly latin chars (áéíóúñ and things like that).
This modification allows tvh to correctly identify charset for current (as of today 10Aug2013) Canal + Spain transponders.
in the "Sattelite BG" digital platform from 23.5E however hence
several of those transponders share their channels with other
platforms this commit sets in only where it is safe meaning where
channels are used by this platform only. To set them for others
would require more testing
It seems from my debugging that we cannot force the encoding to specific
type as the only one, because the providers are sometimes encoding
the current/next events differently then the rest. As the result the
part of events could have wrong encoding. There are also situations,
where firstly loaded event is OK, but further update is screwing
the encoding on it.
My solution is adding special encoding type: PL_AUTO which cover all
Polish EPG. This way the encoding is correct for both current/next
and further events. Side effect is that the encoding list for Polish
channels is smaller (don't need to check if channel is encoded in
ISO8859-2 or in ISO6937, it just works if it is set to PL_AUTO).
The is still a place to force encoding to specified one for a whole
transponder or specific services, but it is not applicable to Polish
providers.
Certain services on some networks are transmitted with incorrect
charset encodings. The user has the ability to manually override
these, but this provide initial defaults for known bad services.
Mostly this relates to Polish DVB-S providers at this time.
