… to be casted (from void*).
This reverts commit 9ebb1f9.
…toring to mirror doc section re-ordering.
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.
The original patch provided a very PL specific patch, this has now been expanded to be more general and work better with the previous charset PR.
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.
…ome a few minor issues.
…xes #1310. This is really considered a hack, it will be replaced with a better internal DVB structure in 3.4.
dvb_charset field (in service UI config) now overrides any DVB provided values rather than simply acting as a default for where values are not specified. This helps fix problems both where providers fail to specify the charset (and ISO6937 is not used) and also where the simply specify the wrong charset entirely.
…me embedded dev systems may not have bzip2 by default.