Re: [vdr] [ANNOUNCE] VDR developer version 1.5.17 - release candidate 2
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 -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.17 - release candidate 2
Hi Klaus, I attached new ukrainian language file for VDR 1.5.17 (uk_UA.po.VDR), and also ukrainian language file for DXR3 (uk_UA.po.DXR3). All the best, Yarema VDR developer version 1.5.17 is now available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.17.tar.bz2 A 'diff' against the previous developer version is available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.16-1.5.17.diff NOTE: = The originally planned release of version 1.6.0 has been postponed, because there have been a few small changes that need to be properly tested first. Please report any bugs as soon as possible. If nothing unexpected happens, I plan to release version 1.6.0 on March 9. The following translation files still have untranslated texts: ca_ES.po el_GR.po es_ES.po hr_HR.po nn_NO.po pl_PL.po pt_PT.po sv_SE.po uk_UA.po It would be nice if somebody could finish these before the 1.6.0 release. To avoid duplicate work, please announce your activity here in this thread. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.17 - release candidate 2
Hi Klaus, I attached new ukrainian language file for VDR 1.5.17 (uk_UA.po.VDR), and also ukrainian language file for DXR3 (uk_UA.po.DXR3). All the best, Yarema VDR developer version 1.5.17 is now available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.17.tar.bz2 A 'diff' against the previous developer version is available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.16-1.5.17.diff NOTE: = The originally planned release of version 1.6.0 has been postponed, because there have been a few small changes that need to be properly tested first. Please report any bugs as soon as possible. If nothing unexpected happens, I plan to release version 1.6.0 on March 9. The following translation files still have untranslated texts: ca_ES.po el_GR.po es_ES.po hr_HR.po nn_NO.po pl_PL.po pt_PT.po sv_SE.po uk_UA.po It would be nice if somebody could finish these before the 1.6.0 release. To avoid duplicate work, please announce your activity here in this thread. # VDR language source file. # Copyright (C) 2008 Klaus Schmidinger [EMAIL PROTECTED] # This file is distributed under the same license as the VDR package. # Yarema Aka Knedlyk [EMAIL PROTECTED], 2007 # msgid msgstr Project-Id-Version: VDR 1.6.0\n Report-Msgid-Bugs-To: [EMAIL PROTECTED]\n POT-Creation-Date: 2008-02-10 12:22+0100\n PO-Revision-Date: 2008-03-07 14:17+0200\n Last-Translator: Yarema Aka Knedlyk [EMAIL PROTECTED]\n Language-Team: Ukrainian\n MIME-Version: 1.0\n Content-Type: text/plain; charset=ISO-8859-5\n Content-Transfer-Encoding: 8bit\n msgid *** Invalid Channel *** msgstr *** ½ÕßàÐÒØÛìÝØÙ ÚÐÝÐÛ *** msgid Channel not available! msgstr ºÐÝÐÛ ÝÕÔÞáâãßÝØÙ! msgid Can't start Transfer Mode! msgstr ½ÕÜÞÖÛØÒÞ ÒÚÛîçØâØ àÕÖØÜ ßàÞßãáÚã! msgid Starting EPG scan msgstr ¿ÞçØÝÐî EPG-áÚÐÝãÒÐÝÝï msgid No title msgstr ±Õ× ÝÐ×ÒØ #. TRANSLATORS: The name of the language, as written natively msgid LanguageName$English msgstr ÃÚàÐ÷ÝáìÚÐ #. TRANSLATORS: The 3-letter code of the language msgid LanguageCode$eng msgstr ukr msgid Phase 1: Detecting RC code type msgstr ºàÞÚ 1: ²Ø×ÝÐçÕÝÝï âØßã ÚÞÔã ßãÛìâÐ msgid Press any key on the RC unit msgstr ½ÐâØáÝöâì ÑãÔì-ïÚã ÚÝÞßÚã ÝÐ ßãÛìâö msgid RC code detected! msgstr ²Ø×ÝÐçÕÝÞ ÚÞÔ ßãÛìâÐ! msgid Do not press any key... msgstr ½Õ ÝÐâØáÚÐÙâÕ ÚÝÞßÚØ... msgid Phase 2: Learning specific key codes msgstr ºàÞÚ 2: ¿àØßØáãÒÐÝÝï ÚÞÔöÒ ÔÛï ÒöÔßÞÒöÔÝØå ÚÝÞßÞÚ #, c-format msgid Press key for '%s' msgstr ½ÐâØáÝöâì ÚÝÞßÚã '%s' msgid Press 'Up' to confirm msgstr ½ÐâØáÝöâì '²ÒÕàå' ÔÛï ßöÔâÒÕàÔÖÕÝÝï msgid Press 'Down' to continue msgstr ½ÐâØáÝöâì '²ÝØ×' ÔÛï ßàÞÔÞÒÖÕÝÝï msgid (press 'Up' to go back) msgstr (½ÐâØáÝöâì '²ÒÕàå' ÔÛï ßÞÒÕàÝÕÝÝï) msgid (press 'Down' to end key definition) msgstr (½ÐâØáÝöâì '²ÝØ×' ÔÛï ×ÐÚöÝçÕÝÝï ÝÐáâàÞÙÚØ ßãÛìâÐ) msgid (press 'Menu' to skip this key) msgstr (½ÐâØáÝöâì '¼ÕÝî' éÞÑ ßàÞßãáâØâØ ÚÝÞßÚã) msgid Learning Remote Control Keys msgstr ½ÐÒçÐÝÝï ßãÛìâÐ msgid Phase 3: Saving key codes msgstr ºàÞÚ 3: ·ÐßÐÜ'ïâÞÒãÒÐÝÝï ÚÞÔöÒ ÚÝÞßÞÚ msgid Press 'Up' to save, 'Down' to cancel msgstr ½ÐâØáÝöâì '²ÒÕàå' ÔÛï ×ÐÚöÝçÕÝÝï, '²ÝØ×' ÔÛï ÒöÔÜÞÒØ msgid Key$Up msgstr ²ÒÕàå msgid Key$Down msgstr ²ÝØ× msgid Key$Menu msgstr ¼ÕÝî msgid Key$Ok msgstr Ok msgid Key$Back msgstr ½Ð×ÐÔ msgid Key$Left msgstr ½ÐÛöÒÞ msgid Key$Right msgstr ½ÐßàÐÒÞ msgid Key$Red msgstr ÇÕàÒÞÝÐ msgid Key$Green msgstr ·ÕÛÕÝÐ msgid Key$Yellow msgstr ¶ÞÒâÐ msgid Key$Blue msgstr ÁØÝï msgid Key$Info msgstr ¦ÝäÞ msgid Key$Play msgstr ¿àÞÓàÐÒÐÝÝï msgid Key$Pause msgstr ¿Ðã×Ð msgid Key$Stop msgstr ÁâÞß msgid Key$Record msgstr ·ÐßØá msgid Key$FastFwd msgstr ¿àÞÚàãâÚÐ ÒßÕàÕÔ msgid Key$FastRew msgstr ¿àÞÚàãâÚÐ ÝÐ×ÐÔ msgid Key$Next msgstr ²ßÕàÕÔ msgid Key$Prev msgstr ½Ð×ÐÔ msgid Key$Power msgstr ²ØÚÛîçØâØ msgid Key$Channel+ msgstr ºÐÝÐÛ + msgid Key$Channel- msgstr ºÐÝÐÛ - msgid Key$PrevChannel msgstr ¿ÞßÕàÕÔÝöÙ ÚÐÝÐÛ msgid Key$Volume+ msgstr ³ãçÝöáâì + msgid Key$Volume- msgstr ³ãçÝöáâì - msgid Key$Mute msgstr ²ØÚÛîçØâØ ×ÒãÚ msgid Key$Audio msgstr ¼ÞÒÐ msgid Key$Subtitles msgstr ÁãÑâØâàØ msgid Key$Schedule msgstr ÂÕÛÕÓöÔ msgid Key$Channels msgstr ºÐÝÐÛØ msgid Key$Timers msgstr ÂÐÙÜÕàØ msgid Key$Recordings msgstr ·ÐßØáØ msgid Key$Setup msgstr ½ÐÛÐèâãÒÐÝÝï msgid Key$Commands msgstr ºÞÜÐÝÔØ msgid Key$User1 msgstr ºÞàØáâãÒÐç1 msgid Key$User2 msgstr ºÞàØáâãÒÐç2 msgid Key$User3 msgstr ºÞàØáâãÒÐç3 msgid Key$User4 msgstr ºÞàØáâãÒÐç4 msgid Key$User5 msgstr ºÞàØáâãÒÐç5 msgid Key$User6 msgstr ºÞàØáâãÒÐç6 msgid Key$User7 msgstr ºÞàØáâãÒÐç7 msgid Key$User8 msgstr ºÞàØáâãÒÐç8 msgid Key$User9 msgstr ºÞàØáâãÒÐç8 msgid Disk msgstr ´ØáÚ msgid free msgstr ÒöÛìÝÞ msgid Free To Air msgstr FTA (ÝÕ×ÐÚÞÔÞÒÐÝÞ) msgid encrypted msgstr ×ÐÚÞÔÞÒÐÝÞ msgid auto msgstr ÐÒâÞ msgid Edit channel msgstr ÀÕÔÐÚâãÒÐÝÝï ÚÐÝÐÛã msgid Name msgstr ½Ð×ÒÐ msgid Source msgstr ´ÖÕàÕÛÞ msgid Frequency msgstr ÇÐáâÞâÐ msgid Vpid msgstr Vpid (ÒöÔÕÞ) msgid Ppid msgstr Ppid msgid Apid1 msgstr Apid1 (ÐãÔöÞ 1)
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.17 - release candidate 2
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.17 - release candidate 2
On Thu, Mar 6, 2008 at 1:49 PM, Klaus Schmidinger [EMAIL PROTECTED] 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. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.17 - release candidate 2
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
--- 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)
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.17 - release candidate 2
Malte Schröder a écrit : On Wed, 05 Mar 2008 18:10:59 +0100 Klaus Schmidinger [EMAIL PROTECTED] 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.17 - release candidate 2
2008/3/5, Malte Schröder [EMAIL PROTECTED]: 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. -- Best Regards, Joachim. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.17 - release candidate 2
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.17 - release candidate 2
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 problem is now very intensively discussed at Czech and Slovak Satellite forum (www.cssf.cz). Some users from www.cssf.cz are proposing how to solve the situation in the future, but they agreed not to initiate any changes before version 1.7.0 will be released. Regards, Ales ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.17 - release candidate 2
En/na Klaus Schmidinger ha escrit: The following translation files still have untranslated texts: ca_ES.po el_GR.po es_ES.po hr_HR.po nn_NO.po pl_PL.po pt_PT.po sv_SE.po uk_UA.po Attached are patches for ca_ES and es_ES, beware, none is my mother tongue, so if someone comes up with better translations I won't be offended. Bye -- Luca ca_ES.diff.bz2 Description: application/bzip es_ES.diff.bz2 Description: application/bzip ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
