| Message ID | 47CED423.2060303@cadsoft.de |
|---|---|
| State | New |
| Headers |
Received: from raven.cadsoft.de ([217.7.101.211]) by www.linuxtv.org with esmtp (Exim 4.63) (envelope-from <Klaus.Schmidinger@cadsoft.de>) id 1JWx8x-0005WE-WB for vdr@linuxtv.org; Wed, 05 Mar 2008 18:11:04 +0100 Received: from [192.168.100.10] (hawk.cadsoft.de [192.168.100.10]) by raven.cadsoft.de (8.13.3/8.13.3) with ESMTP id m25HAxPP004111 for <vdr@linuxtv.org>; Wed, 5 Mar 2008 18:11:00 +0100 Message-ID: <47CED423.2060303@cadsoft.de> Date: Wed, 05 Mar 2008 18:10:59 +0100 From: Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de> Organization: CadSoft Computer GmbH User-Agent: Thunderbird 2.0.0.9 (X11/20070801) MIME-Version: 1.0 To: vdr@linuxtv.org References: <47CA8238.9000802@cadsoft.de> <200803042126.42446.ajurik@quick.cz> In-Reply-To: <200803042126.42446.ajurik@quick.cz> Content-Type: multipart/mixed; boundary="------------040707030406090407010706" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (raven.cadsoft.de [192.168.1.1]); Wed, 05 Mar 2008 18:11:00 +0100 (CET) X-LSpam-Score: 0.0 (/) Subject: Re: [vdr] [ANNOUNCE] VDR developer version 1.5.17 - release candidate 2 X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: VDR Mailing List <vdr@linuxtv.org> List-Id: VDR Mailing List <vdr.linuxtv.org> List-Unsubscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=unsubscribe> List-Archive: <http://www.linuxtv.org/pipermail/vdr> List-Post: <mailto:vdr@linuxtv.org> List-Help: <mailto:vdr-request@linuxtv.org?subject=help> List-Subscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=subscribe> X-List-Received-Date: Wed, 05 Mar 2008 17:11:04 -0000 Status: O X-Status: X-Keywords: X-UID: 15964 |
Commit Message
Klaus Schmidinger
March 5, 2008, 5:10 p.m. UTC
On 03/04/08 21:26, Ales Jurik wrote: > On Sunday 02 of March 2008, Klaus Schmidinger wrote: >> - Rendering the non-breaking space symbol as a blank (thanks to Tobias >> Grimm). - Changed the default character set for SI data from ISO6937 (as >> required by the DVB standard ETSI EN 300 468) to ISO-8859-9, in order to >> work around the stupidity of some providers, who actually use ISO-8859-9, >> but fail to correctly announce that. > > Hi Klaus, > > this change is preventing to use vdr for all Czech/Slovak satellite providers > as they broadcast epg in ISO6937 (ok, UPC at 19.2E with some minor errors). This was exactly what I was afraid of - now the broadcasts that actually do follow the standards are broken. Please try the attached patch. With this the default is ISO6937 again, and can be overridden by setting the environment variable VDR_CHARSET_OVERRIDE. Users in Germany should please test this, too, and do an export VDR_CHARSET_OVERRIDE=ISO-8859-9 before starting VDR. Klaus
Comments
On Wed, 05 Mar 2008 18:10:59 +0100 Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de> wrote: > On 03/04/08 21:26, Ales Jurik wrote: > > On Sunday 02 of March 2008, Klaus Schmidinger wrote: > >> - Rendering the non-breaking space symbol as a blank (thanks to Tobias > >> Grimm). - Changed the default character set for SI data from ISO6937 (as > >> required by the DVB standard ETSI EN 300 468) to ISO-8859-9, in order to > >> work around the stupidity of some providers, who actually use ISO-8859-9, > >> but fail to correctly announce that. > > > > Hi Klaus, > > > > this change is preventing to use vdr for all Czech/Slovak satellite providers > > as they broadcast epg in ISO6937 (ok, UPC at 19.2E with some minor errors). > > This was exactly what I was afraid of - now the broadcasts that actually > do follow the standards are broken. > > Please try the attached patch. With this the default is ISO6937 again, > and can be overridden by setting the environment variable VDR_CHARSET_OVERRIDE. > > Users in Germany should please test this, too, and do an > > export VDR_CHARSET_OVERRIDE=ISO-8859-9 > > before starting VDR. > > Klaus It seems to me as if we would need a per-channel setting for this ...
Malte Schröder a écrit : > On Wed, 05 Mar 2008 18:10:59 +0100 > Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de> wrote: > >> >> Please try the attached patch. With this the default is ISO6937 again, >> and can be overridden by setting the environment variable VDR_CHARSET_OVERRIDE. >> >> Users in Germany should please test this, too, and do an >> >> export VDR_CHARSET_OVERRIDE=ISO-8859-9 >> >> before starting VDR. >> >> Klaus > > It seems to me as if we would need a per-channel setting for this ... > +1 Jean-Claude
2008/3/5, Malte Schröder <maltesch@gmx.de>: > > Please try the attached patch. With this the default is ISO6937 again, > > and can be overridden by setting the environment variable VDR_CHARSET_OVERRIDE. > It seems to me as if we would need a per-channel setting for this ... -1 Blame your tv provider.
On Wednesday 05 of March 2008, Malte Schröder wrote: > On Wed, 05 Mar 2008 18:10:59 +0100 > > > > > Users in Germany should please test this, too, and do an > > > > export VDR_CHARSET_OVERRIDE=ISO-8859-9 > > > > before starting VDR. > > > > Klaus > > It seems to me as if we would need a per-channel setting for this ... This is exactly the solution which seems to be commonly forced at www.cssf.cz. The solution is to use config file in encoding.conf format (linux enigma boxes). It could be possible to define encoding not for all channels but only for these which encoding is not well recognized and different from default. I think not only I will be very happy to have such a solution as I'm watching not only Czech channels, but also from other countries. And for example I'm very disappointed to have at one channel German epg without problem (RTL, EinsPlus) and at other (Q TV SHOP) epg badly encoded. BR, Ales
Klaus Schmidinger wrote: > Users in Germany should please test this, too, and do an > > export VDR_CHARSET_OVERRIDE=ISO-8859-9 > > before starting VDR. In case we do head for a single override option, wouldn't it be more consistent to do this with a command line option instead of an environment variable? Cheers, Udo
On 03/05/08 22:55, Udo Richter wrote: > Klaus Schmidinger wrote: >> Users in Germany should please test this, too, and do an >> >> export VDR_CHARSET_OVERRIDE=ISO-8859-9 >> >> before starting VDR. > > In case we do head for a single override option, wouldn't it be more > consistent to do this with a command line option instead of an > environment variable? Let's first see if a single override is sufficient. I wouldn't want this workaround to manifest itself too much in the normal VDR operation. If there are different code overrides necessary, we'll probably need something like a "workaround-broadcaster-stupidity.conf" file... BTW: I wish this thread would have been started as a new one, with a proper subject... Klaus
On 03/05/08 22:11, Ales Jurik wrote: > On Wednesday 05 of March 2008, Malte Schröder wrote: >> On Wed, 05 Mar 2008 18:10:59 +0100 >> >>> Users in Germany should please test this, too, and do an >>> >>> export VDR_CHARSET_OVERRIDE=ISO-8859-9 >>> >>> before starting VDR. >>> >>> Klaus >> It seems to me as if we would need a per-channel setting for this ... > > This is exactly the solution which seems to be commonly forced at www.cssf.cz. Sorry, I don't speak Czech, so I can't follow what's going on there. > The solution is to use config file in encoding.conf format (linux enigma > boxes). It could be possible to define encoding not for all channels but only > for these which encoding is not well recognized and different from default. With the recent change at least the Czech channels should work properly again. Can you confirm that? > I think not only I will be very happy to have such a solution as I'm watching > not only Czech channels, but also from other countries. And for example I'm > very disappointed to have at one channel German epg without problem (RTL, > EinsPlus) and at other (Q TV SHOP) epg badly encoded. Instead of working around these problems people should massively complain to their broadcasters. For version 1.6.0 there's nothing more I can do than using the environment variable. Maybe later I'll introduce a "workaround-provider-stupidity.conf" ;-) Klaus
On Thursday 06 of March 2008, Klaus Schmidinger wrote: > > Sorry, I don't speak Czech, so I can't follow what's going on there. > Hi, there is nothing more than I've tried to put into this maillist except discussion. > With the recent change at least the Czech channels should work > properly again. Can you confirm that? > Yes, I confirm that. Similar solution was proposed by bastlir at the forum (he proposed to comment out the line your patch is deleting). > For version 1.6.0 there's nothing more I can do than using the environment > variable. Maybe later I'll introduce a "workaround-provider-stupidity.conf" > ;-) > I agree with you but I'm afraid that such communications with broadcasters will give no results. This maybe will be successfull when big producers of sat boxes will make such pression too. But it seems that for them is more efficient to make localization which is compliant to broadcasters not to sat norms. BR, Ales
On 03/06/08 11:36, Ales Jurik wrote: > On Thursday 06 of March 2008, Klaus Schmidinger wrote: >> Sorry, I don't speak Czech, so I can't follow what's going on there. >> > > Hi, > > there is nothing more than I've tried to put into this maillist except > discussion. > >> With the recent change at least the Czech channels should work >> properly again. Can you confirm that? >> > > Yes, I confirm that. Similar solution was proposed by bastlir at the forum (he > proposed to comment out the line your patch is deleting). > >> For version 1.6.0 there's nothing more I can do than using the environment >> variable. Maybe later I'll introduce a "workaround-provider-stupidity.conf" >> ;-) >> > > I agree with you but I'm afraid that such communications with broadcasters > will give no results. This maybe will be successfull when big producers of > sat boxes will make such pression too. But it seems that for them is more > efficient to make localization which is compliant to broadcasters not to sat > norms. I'd really like to know why some broadcasters don't adhere to the standards (even though it would be a child's game). Are they actively refusing to, unable to interpret the standard documents, or just flat out dumb? Klaus
On Thu, Mar 6, 2008 at 1:49 PM, Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de> wrote: > I'd really like to know why some broadcasters don't adhere to the standards > (even though it would be a child's game). Are they actively refusing to, unable > to interpret the standard documents, or just flat out dumb? I don't think it's a law they have to and if that's the case, why should they adhere to them? Maybe they think they have a better way of doing things, or something more suited for the way their systems are set up. Unless it's a law, it's a recommendation and we all know a lot of the time people choose not to follow them. I wish everyone did follow one set of guidelines just to make what we do easier but if I were a provider I can't honestly say that would be a priority unless we didn't have our own hardware to provide to our customers.
En/na Klaus Schmidinger ha escrit: > I'd really like to know why some broadcasters don't adhere to the standards > (even though it would be a child's game). Are they actively refusing to, unable > to interpret the standard documents, or just flat out dumb? [X] All of the above ;-) Bye
--- libsi/si.c 2008/03/01 12:02:01 1.24 +++ libsi/si.c 2008/03/05 17:00:55 @@ -14,6 +14,7 @@ #include <errno.h> #include <iconv.h> #include <malloc.h> +#include <stdlib.h> // for broadcaster stupidity workaround #include <string.h> #include "descriptor.h" @@ -340,9 +341,12 @@ // and length are adjusted accordingly. static const char *getCharacterTable(const unsigned char *&buffer, int &length, bool *isSingleByte = NULL) { const char *cs = "ISO6937"; - cs = "ISO-8859-9"; // Workaround for broadcaster stupidity: according to + // Workaround for broadcaster stupidity: according to // "ETSI EN 300 468" the default character set is ISO6937. But unfortunately some // broadcasters actually use ISO-8859-9, but fail to correctly announce that. + static const char *CharsetOverride = getenv("VDR_CHARSET_OVERRIDE"); + if (CharsetOverride) + cs = CharsetOverride; if (isSingleByte) *isSingleByte = false; if (length <= 0)