Re: [vdr] Bug in pat.c (VDR 1.7.27) - possible fix attached
On 08.04.2012 18:38, Patrick Boettcher wrote: Hi, I located a small bug which has been introduced in 1.7.18 (at least I think so). Reading the Changes file I could not determine which change caused it, but the problem is the following. In pat.c: if the PMT of a service has a stream of stream-type 128 (0x80) the vpid is overridden with the PID signalled in the Elementary-PID-field of this stream. This happens to be the case here in France for some of the DVB- T services. It breaks 2 channels (France 2 and France 5) when channel- updates is at least configured to "update PIDs". The code which is doing that is described as "STREAMTYPE_USER_PRIVATE - DigiCipher II VIDEO (ANSI/SCTE 57)" which before was only applied when the stream had a certain descriptor and there a certain type. The attached patch resets the code to do exactly that for STREAMTYPE 0x80 - though can't check whether the digiCipher-stuff is still working. + // http://www.smpte-ra.org/mpegreg/mpegreg.html + ... + case 0x44434949: // STREAMTYPE_USER_PRIVATE - DigiCipher II VIDEO (ANSI/SCTE 57) There is no entry for 44-43-49-49 on the given page. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
On 08.04.2012 23:11, Christopher Reimer wrote: 2012/4/8 VDR User mailto:user@gmail.com>> I know several people who set their directories on the command line and ignore maintaining Make.config completely so it's not true everyone uses Make.config. OK, that could be possible, although I don't understand why. Let's wait what Klaus says. The only condition I want to be met is that when building the original, unpatched VDR out of the box, without any user defined Make.config etc., it needs to behave just like it does now. However, there is one thing in the current behavior that I would even consider a bug: if one starts VDR with vdr -v /mydir it uses /mydir as the video directory, but still uses /video for the configuration files. I believe that as long as there is no explicit -c option given, the config directory should follow what's given in the -v option. So I wouldn't mind if this was fixed along with implementing the FHS stuff ;-) (or in a separate step). Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
Udo Richter wrote: > Ok, second attempt: > - Makefile does not set CACHEDIR and RESDIR > - Make.config *can* set CACHEDIR and RESDIR, or not. > - If --cachedir or --resdir is set by command line, use them. > - If not, default to CACHEDIR and RESDIR. > - If CACHEDIR or RESDIR is not set (empty string), fall back to whatever > --video and --config is set to. > > Patched patch attached. ;) > Needs documentation updated though. Do so. I guess it is nearly impossible to document this in a way, a user actually understands. Yours Manuel -- () ascii ribbon campaign - against html mail /\- gegen HTML-Mail answers as html mail will be deleted automatically! Antworten als HTML-Mail werden automatisch gelöscht! Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
2012/4/9 Klaus Schmidinger > > However, there is one thing in the current behavior that I would even > consider a bug: if one starts VDR with > > vdr -v /mydir > > it uses /mydir as the video directory, but still uses /video for the > configuration files. I believe that as long as there is no explicit > -c option given, the config directory should follow what's given in > the -v option. So I wouldn't mind if this was fixed along with implementing > the FHS stuff ;-) (or in a separate step). > > Ok, maybe Udo can add this to the patch. Udo, please also mind the additional Makefile change I mentioned before. I can't find a special place where to add this to the documentation. In addition I think it's self explanatory ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
On 9.4.2012 12:54, Klaus Schmidinger wrote: vdr -v /mydir it uses /mydir as the video directory, but still uses /video for the configuration files. I believe that as long as there is no explicit -c option given, the config directory should follow what's given in the -v option. Shouldn't it follow option given at ./configure? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
On 09.04.2012 13:15, Pertti Kosunen wrote: On 9.4.2012 12:54, Klaus Schmidinger wrote: vdr -v /mydir it uses /mydir as the video directory, but still uses /video for the configuration files. I believe that as long as there is no explicit -c option given, the config directory should follow what's given in the -v option. Shouldn't it follow option given at ./configure? What "./configure"??? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Bug in pat.c (VDR 1.7.27) - possible fix attached
On 9 April 2012 10:40, Klaus Schmidinger wrote: > + // http://www.smpte-ra.org/mpegreg/mpegreg.html > + ... > + case 0x44434949: // STREAMTYPE_USER_PRIVATE - > DigiCipher II VIDEO (ANSI/SCTE 57) > > There is no entry for 44-43-49-49 on the given page. > > Klaus fwiw, Patrick's patch simply re-instates the case statement that was removed in VDR 1.7.18, although with a slightly different comment against it see pat.c diff at http://git.gekrumbel.de/vdr.git?p=vdr.git;a=commitdiff;h=f3d9ba8bfd6cd51779aa1d2923903949fbb92f3c I'm guessing this was removed as part of Rolf's patch to add DigiCipher support? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
On 9.4.2012 14:19, Klaus Schmidinger wrote: What "./configure"??? When compiling VDR from source, "./configure ; make ; make install". ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
On 09.04.2012 13:44, Pertti Kosunen wrote: On 9.4.2012 14:19, Klaus Schmidinger wrote: What "./configure"??? When compiling VDR from source, "./configure ; make ; make install". There is no "./configure" in the VDR source. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
Am 09.04.2012 11:54, schrieb Klaus Schmidinger: > However, there is one thing in the current behavior that I would even > consider a bug: if one starts VDR with > > vdr -v /mydir > > it uses /mydir as the video directory, but still uses /video for the > configuration files. I believe that as long as there is no explicit > -c option given, the config directory should follow what's given in > the -v option. You're sure about -c following -v? It worked that way until 1.5.8, but has been dropped in favor of the final changes regarding CONFDIR in 1.5.11. I don't see any reason to change that. Or did you mess up --config with --cachedir? Happened to me too. In the latter case: In my patch, the cacheDirectory follows the VideoDirectory, even if the latter is set by --video, but only as long as CACHEDIR is un-set. (Same applies to --config and RESDIR.) I'm not sure whether this should also be the case if VDR is compiled to be FHS compliant. In that case users should know about the various folders, and setting a --video directory should not have precedence over CACHEDIR=/var/lib/vdr. The only thing I could think of is to check whether CACHEDIR==VIDEODIR, and only then let cacheDirectory follow --video, but I would prefer to not use such hacks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
On 09.04.2012 15:18, Udo Richter wrote: Am 09.04.2012 11:54, schrieb Klaus Schmidinger: However, there is one thing in the current behavior that I would even consider a bug: if one starts VDR with vdr -v /mydir it uses /mydir as the video directory, but still uses /video for the configuration files. I believe that as long as there is no explicit -c option given, the config directory should follow what's given in the -v option. You're sure about -c following -v? It worked that way until 1.5.8, but has been dropped in favor of the final changes regarding CONFDIR in 1.5.11. I don't see any reason to change that. Or did you mess up --config with --cachedir? Happened to me too. I surely didn't mean --cachedir because my VDR doesn't have that option (yet) ;-). A while ago I ran a test and wanted to use a different video directory, so I started VDR with the -v option. I was surprised to see that it still loaded the config files from the default /video directory. In the latter case: In my patch, the cacheDirectory follows the VideoDirectory, even if the latter is set by --video, but only as long as CACHEDIR is un-set. (Same applies to --config and RESDIR.) I'm not sure whether this should also be the case if VDR is compiled to be FHS compliant. In that case users should know about the various folders, and setting a --video directory should not have precedence over CACHEDIR=/var/lib/vdr. The only thing I could think of is to check whether CACHEDIR==VIDEODIR, and only then let cacheDirectory follow --video, but I would prefer to not use such hacks. Currently VDR has only two directories, 'video' and 'config'. The idea is that by default the video directory is /video, and the config directory is the same. If -v is given, this changes the video directory, and since config follows video (or at least is supposed to), the config files will be loaded from the new video directory. Only if there is an explicit -c option shall the config directory be different from the video directory. I'd like to see a similar mechanism for the two new directories 'cache' and 'resource'. By default they follow 'config' and can only be different if the respective options are given. The default values for 'cache' and 'resource' shall be empty, in which case they follow 'config'. If VDR is compiled with non-empty values for 'cache' and/or 'resource', simply let them no longer follow 'config' (same behavior as if a command line option has been given). Don't know whether the patch already behaves this way (haven't checked), but that's the way it should be. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Bug in pat.c (VDR 1.7.27) - possible fix attached
On Monday 09 April 2012 13:39:36 Dominic Evans wrote: > On 9 April 2012 10:40, Klaus Schmidinger wrote: > > + // > > http://www.smpte-ra.org/mpegreg/mpegreg.html + > > ... > > + case 0x44434949: // STREAMTYPE_USER_PRIVATE > > - DigiCipher II VIDEO (ANSI/SCTE 57) > > > > There is no entry for 44-43-49-49 on the given page. It wasn't me who added this stream-type check, I just re-applied the checks how they were done before. > see pat.c diff at > http://git.gekrumbel.de/vdr.git?p=vdr.git;a=commitdiff;h=f3d9ba8bfd6cd517 > 79aa1d2923903949fbb92f3c I used exactly this repository to find out that the regression was introduced in 1.7.18. > I'm guessing this was removed as part of Rolf's patch to add DigiCipher > support? Rolf contacted me off-list and confirmed your assumption. I sent the PMT (attached here as well) of the channel to him to see whether he has an idea how it can be avoided. In general I think just brutally replace the VPID with the PID signalled in the stream which is "user-defined" can't be the right way. -- Patrick http://www.kernellabs.com/ dvbsnoop V1.4.50 -- http://dvbsnoop.sourceforge.net/ SECT-Packet: 0001 PID: 110 (0x006e), Length: 98 (0x0062) Time received: Mon 2012-04-09 09:51:42.797 : 02 b0 5f 01 01 ff 00 00 e0 78 f0 00 02 e0 78 f0 .._..xx. 0010: 03 11 01 ff 03 e0 82 f0 06 0a 04 66 72 61 00 03 ...fra.. 0020: e0 83 f0 0d 0a 04 71 61 64 00 7f 05 06 85 66 72 ..qad.fr 0030: 61 06 e0 8c f0 0a 59 08 66 72 61 20 00 01 00 01 a.Y.fra 0040: 05 e0 aa f0 05 6f 03 80 10 e0 80 e0 ab f0 00 80 .o.. 0050: e0 ac f0 00 80 e0 ad f0 00 80 e0 ae f0 00 eb 4a ...J 0060: d3 d2 .. PID: 110 (0x006e) Guess table from table id... PMT-decoding Table_ID: 2 (0x02) [= Program Map Table (PMT)] section_syntax_indicator: 1 (0x01) (fixed '0'): 0 (0x00) reserved_1: 3 (0x03) Section_length: 95 (0x005f) Program_number: 257 (0x0101) reserved_2: 3 (0x03) Version_number: 31 (0x1f) current_next_indicator: 1 (0x01) [= valid now] Section_number: 0 (0x00) Last_Section_number: 0 (0x00) reserved_3: 7 (0x07) PCR PID: 120 (0x0078) reserved_4: 15 (0x0f) Program_info_length: 0 (0x) Stream_type loop: Stream_type: 2 (0x02) [= ITU-T Rec. H.262 | ISO/IEC 13818-2 Video | ISO/IEC 11172-2 constr. parameter video stream] reserved_1: 7 (0x07) Elementary_PID: 120 (0x0078) reserved_2: 15 (0x0f) ES_info_length: 3 (0x0003) MPEG-DescriptorTag: 17 (0x11) [= STD_descriptor] descriptor_length: 1 (0x01) reserved_1: 127 (0x7f) leak_valid_flag: 1 (0x01) Stream_type: 3 (0x03) [= ISO/IEC 11172 Audio] reserved_1: 7 (0x07) Elementary_PID: 130 (0x0082) reserved_2: 15 (0x0f) ES_info_length: 6 (0x0006) MPEG-DescriptorTag: 10 (0x0a) [= ISO_639_language_descriptor] descriptor_length: 4 (0x04) ISO639_language_code: fra Audio_type: 0 (0x00) [= undefined] Stream_type: 3 (0x03) [= ISO/IEC 11172 Audio] reserved_1: 7 (0x07) Elementary_PID: 131 (0x0083) reserved_2: 15 (0x0f) ES_info_length: 13 (0x000d) MPEG-DescriptorTag: 10 (0x0a) [= ISO_639_language_descriptor] descriptor_length: 4 (0x04) ISO639_language_code: qad Audio_type: 0 (0x00) [= undefined] DVB-DescriptorTag: 127 (0x7f) [= extension_descriptor] descriptor_length: 5 (0x05) descriptor_tag_extension: 6 (0x06) selector_bytes: : 85 66 72 61.fra Stream_type: 6 (0x06) [= ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data] reserved_1: 7 (0x07) Elementary_PID: 140 (0x008c) reserved_2: 15 (0x0f) ES_info_length: 10 (0x000a) DVB-DescriptorTag: 89 (0x59) [= subtitling_descriptor] descriptor_length: 8 (0x08) ISO639_language_code: fra Subtitling_type: 32 (0x20) [= DVB subtitles (for the hard hearing) with no monitor aspect ratio critical] Composition_page_id: 1 (0x0001) Ancillary_page_id: 1 (0x0001) Stream_type: 5 (0x05) [= ITU-T Rec. H.222.0 | ISO/IEC 13818-1 private sections] reserved_1: 7 (0x07) Elementary_PID: 170 (0x00aa) reserved_2: 15 (0x0f) ES_info_length: 5 (0x0005) DVB-DescriptorTag: 111 (0x6f) [= application_signalling_descriptor] descriptor_length: 3 (0x03) Application type: 32784 (0x8010) reserved: 7 (0x07) AIT version nr.: 0 (0x00) Stream_type: 128 (0x80) [= User private]
Re: [vdr] Bug in pat.c (VDR 1.7.27) - possible fix attached
On 09.04.2012 17:49, Patrick Boettcher wrote:
On Monday 09 April 2012 13:39:36 Dominic Evans wrote:
On 9 April 2012 10:40, Klaus Schmidinger
wrote:
+ //
http://www.smpte-ra.org/mpegreg/mpegreg.html +
...
+ case 0x44434949: // STREAMTYPE_USER_PRIVATE
- DigiCipher II VIDEO (ANSI/SCTE 57)
There is no entry for 44-43-49-49 on the given page.
It wasn't me who added this stream-type check, I just re-applied the checks
how they were done before.
No big deal, I was just wondering.
I have adopted your patch in the attached form.
Maybe you (and/or Rolf) would like to verify it.
Klaus
--- pat.c 2012/03/02 10:56:45 2.17
+++ pat.c 2012/04/09 11:49:39 2.18
@@ -456,11 +456,28 @@
}
}
break;
- case 0x80: // STREAMTYPE_USER_PRIVATE - DigiCipher II VIDEO (ANSI/SCTE 57)
- Vpid = esPid;
- Ppid = pmt.getPCRPid();
- Vtype = 0x02; // compression based upon MPEG-2
- ProcessCaDescriptors = true;
+ // see http://www.smpte-ra.org/mpegreg/mpegreg.html for the codes used below
+ case 0x80: { // STREAMTYPE_USER_PRIVATE - DigiCipher II VIDEO (ANSI/SCTE 57)
+ SI::Descriptor *d;
+ for (SI::Loop::Iterator it; (d = stream.streamDescriptors.getNext(it)); ) {
+ switch (d->getDescriptorTag()) {
+case SI::RegistrationDescriptorTag: {
+ SI::RegistrationDescriptor *rd = (SI::RegistrationDescriptor *)d;
+ switch (rd->getFormatIdentifier()) {
+ case 0x44434949: // 'DCII' aka. DigiCipher II
+Vpid = esPid;
+Ppid = pmt.getPCRPid();
+Vtype = 0x02; // compression based upon MPEG-2
+ProcessCaDescriptors = true;
+break;
+ default: ;
+ }
+ }
+ break;
+default: ;
+}
+ }
+ }
break;
case 0x81: // STREAMTYPE_USER_PRIVATE - ATSC A/53 AUDIO (ANSI/SCTE 57)
{
@@ -495,7 +512,6 @@
switch (d->getDescriptorTag()) {
case SI::RegistrationDescriptorTag: {
SI::RegistrationDescriptor *rd = (SI::RegistrationDescriptor *)d;
- // http://www.smpte-ra.org/mpegreg/mpegreg.html
switch (rd->getFormatIdentifier()) {
case 0x41432D33: // 'AC-3'
IsAc3 = true;
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Bug in pat.c (VDR 1.7.27) - possible fix attached
On Monday 09 April 2012 17:57:20 Klaus Schmidinger wrote: > On 09.04.2012 17:49, Patrick Boettcher wrote: > > On Monday 09 April 2012 13:39:36 Dominic Evans wrote: > >> On 9 April 2012 10:40, Klaus Schmidinger > > > > wrote: > >>> + // > >>> http://www.smpte-ra.org/mpegreg/mpegreg.html + > >>> > >>> ... > >>> > >>> + case 0x44434949: // > >>> STREAMTYPE_USER_PRIVATE - DigiCipher II VIDEO (ANSI/SCTE 57) > >>> > >>> There is no entry for 44-43-49-49 on the given page. > > > > It wasn't me who added this stream-type check, I just re-applied the > > checks how they were done before. > > No big deal, I was just wondering. > > I have adopted your patch in the attached form. > Maybe you (and/or Rolf) would like to verify it. The patch looks good to me. In the meantime Rolf contacted me saying that it be better to move this code to a plugin which digicipher users could use if they want (at least that's what I understood). I think he will contact you. For the time being your patch should fix it. Thanks. -- Patrick http://www.kernellabs.com/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Bug in pat.c (VDR 1.7.27) - possible fix attached
Hi A plugin why not but in our case, DVB-T in France, those channels are FTA The real question should be why broadcaster include this ? good question !! The patch is reported as working and fixing PPID wrong value that's the most important Thanks for this patch @+ Le lundi 09 avril 2012 18:23:58, Patrick Boettcher a écrit : > On Monday 09 April 2012 17:57:20 Klaus Schmidinger wrote: > > On 09.04.2012 17:49, Patrick Boettcher wrote: > > > On Monday 09 April 2012 13:39:36 Dominic Evans wrote: > > >> On 9 April 2012 10:40, Klaus Schmidinger > > > > > > wrote: > > >>> + // > > >>> http://www.smpte-ra.org/mpegreg/mpegreg.html + > > >>> > > >>> ... > > >>> > > >>> + case 0x44434949: // > > >>> STREAMTYPE_USER_PRIVATE - DigiCipher II VIDEO (ANSI/SCTE 57) > > >>> > > >>> There is no entry for 44-43-49-49 on the given page. > > > > > > It wasn't me who added this stream-type check, I just re-applied the > > > checks how they were done before. > > > > No big deal, I was just wondering. > > > > I have adopted your patch in the attached form. > > Maybe you (and/or Rolf) would like to verify it. > > The patch looks good to me. > > In the meantime Rolf contacted me saying that it be better to move this > code to a plugin which digicipher users could use if they want (at least > that's what I understood). > > I think he will contact you. For the time being your patch should fix it. > > Thanks. > > -- > Patrick > http://www.kernellabs.com/ > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Bug in pat.c (VDR 1.7.27) - possible fix attached
On 09.04.2012 20:05, Dominique wrote: Hi A plugin why not but in our case, DVB-T in France, those channels are FTA The real question should be why broadcaster include this ? good question !! The patch is reported as working and fixing PPID wrong value that's the most important Rolf Ahrenberg has informed me that this patch breaks things for North American streams, so I'm going to revoke it again. I wouldn't want to introduce a plugin interface for this, so unless there is a way to tell these different versions apart from the data stream, we'll need to introduce some way of making this selectable by the user. Of course, a way of detecting them automatically would be preferable. Klaus Le lundi 09 avril 2012 18:23:58, Patrick Boettcher a écrit : On Monday 09 April 2012 17:57:20 Klaus Schmidinger wrote: On 09.04.2012 17:49, Patrick Boettcher wrote: On Monday 09 April 2012 13:39:36 Dominic Evans wrote: On 9 April 2012 10:40, Klaus Schmidinger wrote: + // http://www.smpte-ra.org/mpegreg/mpegreg.html + ... + case 0x44434949: // STREAMTYPE_USER_PRIVATE - DigiCipher II VIDEO (ANSI/SCTE 57) There is no entry for 44-43-49-49 on the given page. It wasn't me who added this stream-type check, I just re-applied the checks how they were done before. No big deal, I was just wondering. I have adopted your patch in the attached form. Maybe you (and/or Rolf) would like to verify it. The patch looks good to me. In the meantime Rolf contacted me saying that it be better to move this code to a plugin which digicipher users could use if they want (at least that's what I understood). I think he will contact you. For the time being your patch should fix it. Thanks. -- Patrick ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
