Re: [vdr] French DVB-T Channel IDs vs. EIT Channel IDs

2018-03-09 Thread Patrick Boettcher 
On Fri, 9 Mar 2018 11:55:02 +0100
Klaus Schmidinger <klaus.schmidin...@tvdr.de> wrote:

> On 09.03.2018 11:51, Patrick Boettcher wrote:
> > On Fri, 9 Mar 2018 11:30:36 +0100
> > Klaus Schmidinger <klaus.schmidin...@tvdr.de> wrote:
> >   
> >> On 01.03.2018 10:22, Patrick Boettcher wrote:  
> >> > On Wed, 28 Feb 2018 11:01:23 +0100
> >> > Klaus Schmidinger <klaus.schmidin...@tvdr.de> wrote:
> >> > 
> >> >> On 27.02.2018 17:58, Patrick Boettcher wrote:
> >> >> > On Tue, 27 Feb 2018 16:54:35 +0100
> >> >> > Klaus Schmidinger <klaus.schmidin...@tvdr.de> wrote:
> >> >> >   
> >> >> >> Hello Patrick,
> >> >> >> 
> >> >> >> your scan doesn't contain the NIT, which is where the
> >> >> >> transponder innformation is broadcast. Can you scan that,
> >> >> >> too, please?  
> >> >> > 
> >> >> > Hi Klaus,
> >> >> > 
> >> >> > NIT attached (from another multiplex with the same
> >> >> > symptoms).  
> >> >> 
> >> >>  DVB-DescriptorTag: 90 (0x5a)  [=
> >> >> terrestrial_delivery_system_descriptor] descriptor_length: 11
> >> >> (0x0b) Center frequency: 0x (= 42949672.095 kHz)
> >> >> 
> >> >> @@ -219,6 +219,8 @@
> >> >>cDvbTransponderParameters dtp;
> >> >>int Source =
> >> >> cSource::FromData(cSource::stTerr); int Frequency =
> >> >> Frequencies[0] = sd->getFrequency() * 10;
> >> >> + Frequency = Transponder() * 100;//XXX
> >> >> + dsyslog("Frequency = %08X, Transponder = %d",
> >> >> sd->getFrequency(), Transponder());//XXX static int
> >> >> Bandwidths[] = { 800, 700, 600, 500, 0, 0, 0,
> >> >> 0 }; dtp.SetBandwidth(Bandwidths[sd->getBandwidth()]); static
> >> >> int Constellations[] = { QPSK, QAM_16, QAM_64, QAM_AUTO };
> >> > 
> >> > It works. I had to have VDR recreate the channels because it was
> >> > mixing things up with the already existing ones.
> >> > 
> >> > As to why the frequency is set to "-10" I don't know (yet), but I
> >> > remember it has always been like this since 2005.
> >> > 
> >> > Initial tuning files have always contained all active frequencies
> >> > for their region, because the NIT did not set the center
> >> > frequencies correctly.
> >> > 
> >> > It might be because the multiplexed transport streams are
> >> > generated centrally and then distributed to all the
> >> > base-stations where they are emitted as-is but on different
> >> > frequencies depending on the region.
> >> > 
> >> > What can we do to get this upstream?
> >> 
> >> I'm afraid I don't see how this case can be handled correctly.
> >> 
> >> Maybe somebody else has an idea?  
> > 
> > One approach might be to ignore frequencies for DVB-T channels
> > update during NIT parsing (in France only?).
> >   
> >>From my experiences with DVB-T SetTopBoxes using the NIT for  
> > new channel-discovery is rarely done. No customer of my ex-employer
> > was using it - scanning was entirely based on continuous
> > frequency-band scanning with a spare demod.
> > 
> > That would be my idea. But I don't know whether this can be easily
> > applied to VDR.  
> 
> Well, maybe this works for you?
> 
> --- nit.c   2016/12/23 14:16:59 4.4
> +++ nit.c   2018/03/09 10:53:38
> @@ -218,6 +218,8 @@
>SI::TerrestrialDeliverySystemDescriptor *sd =
> (SI::TerrestrialDeliverySystemDescriptor *)d;
> cDvbTransponderParameters dtp; int Source =
> cSource::FromData(cSource::stTerr);
> + if (sd->getFrequency() == 0x)
> +continue;
>int Frequency = Frequencies[0] =
> sd->getFrequency() * 10; static int Bandwidths[] = { 800,
> 700, 600, 500, 0, 0, 0, 0 };
> dtp.SetBandwidth(Bandwidths[sd->getBandwidth()]);

This is what I'm doing right now (though I'm using break instead of
continue).

But won't his inhibit the update of modulation parameters of the
_current_ channel?

--
Patrick.

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] French DVB-T Channel IDs vs. EIT Channel IDs

2018-03-09 Thread Patrick Boettcher 
On Fri, 9 Mar 2018 11:30:36 +0100
Klaus Schmidinger <klaus.schmidin...@tvdr.de> wrote:

> On 01.03.2018 10:22, Patrick Boettcher wrote:
> > On Wed, 28 Feb 2018 11:01:23 +0100
> > Klaus Schmidinger <klaus.schmidin...@tvdr.de> wrote:
> >   
> >> On 27.02.2018 17:58, Patrick Boettcher wrote:  
> >> > On Tue, 27 Feb 2018 16:54:35 +0100
> >> > Klaus Schmidinger <klaus.schmidin...@tvdr.de> wrote:
> >> > 
> >> >> Hello Patrick,
> >> >> 
> >> >> your scan doesn't contain the NIT, which is where the
> >> >> transponder innformation is broadcast. Can you scan that, too,
> >> >> please?
> >> > 
> >> > Hi Klaus,
> >> > 
> >> > NIT attached (from another multiplex with the same symptoms).
> >> 
> >>  DVB-DescriptorTag: 90 (0x5a)  [=
> >> terrestrial_delivery_system_descriptor] descriptor_length: 11
> >> (0x0b) Center frequency: 0x (= 42949672.095 kHz)
> >> 
> >> @@ -219,6 +219,8 @@
> >>cDvbTransponderParameters dtp;
> >>int Source = cSource::FromData(cSource::stTerr);
> >>int Frequency = Frequencies[0] =
> >> sd->getFrequency() * 10;
> >> + Frequency = Transponder() * 100;//XXX
> >> + dsyslog("Frequency = %08X, Transponder = %d",
> >> sd->getFrequency(), Transponder());//XXX static int Bandwidths[] =
> >> { 800, 700, 600, 500, 0, 0, 0, 0 };
> >> dtp.SetBandwidth(Bandwidths[sd->getBandwidth()]); static int
> >> Constellations[] = { QPSK, QAM_16, QAM_64, QAM_AUTO };  
> > 
> > It works. I had to have VDR recreate the channels because it was
> > mixing things up with the already existing ones.
> > 
> > As to why the frequency is set to "-10" I don't know (yet), but I
> > remember it has always been like this since 2005.
> > 
> > Initial tuning files have always contained all active frequencies
> > for their region, because the NIT did not set the center frequencies
> > correctly.
> > 
> > It might be because the multiplexed transport streams are generated
> > centrally and then distributed to all the base-stations where they
> > are emitted as-is but on different frequencies depending on the
> > region.
> > 
> > What can we do to get this upstream?  
> 
> I'm afraid I don't see how this case can be handled correctly.
> 
> Maybe somebody else has an idea?

One approach might be to ignore frequencies for DVB-T channels update
during NIT parsing (in France only?).

From my experiences with DVB-T SetTopBoxes using the NIT for
new channel-discovery is rarely done. No customer of my ex-employer was
using it - scanning was entirely based on continuous frequency-band
scanning with a spare demod. 

That would be my idea. But I don't know whether this can be easily
applied to VDR.

--
Patrick.

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] French DVB-T Channel IDs vs. EIT Channel IDs

2018-03-01 Thread Patrick Boettcher 
On Thu, 1 Mar 2018 10:22:10 +0100
Patrick Boettcher <patrick.boettc...@posteo.de> wrote:

> On Wed, 28 Feb 2018 11:01:23 +0100
> Klaus Schmidinger <klaus.schmidin...@tvdr.de> wrote:
> 
> > On 27.02.2018 17:58, Patrick Boettcher wrote:  
> > > On Tue, 27 Feb 2018 16:54:35 +0100
> > > Klaus Schmidinger <klaus.schmidin...@tvdr.de> wrote:
> > > 
> > >> Hello Patrick,
> > >> 
> > >> your scan doesn't contain the NIT, which is where the transponder
> > >> innformation is broadcast. Can you scan that, too, please?
> > > 
> > > Hi Klaus,
> > > 
> > > NIT attached (from another multiplex with the same symptoms).
> > 
> >  DVB-DescriptorTag: 90 (0x5a)  [=
> > terrestrial_delivery_system_descriptor] descriptor_length: 11 (0x0b)
> >  Center frequency: 0x (= 42949672.095 kHz)
> > 
> > @@ -219,6 +219,8 @@
> >cDvbTransponderParameters dtp;
> >int Source = cSource::FromData(cSource::stTerr);
> >int Frequency = Frequencies[0] =
> > sd->getFrequency() * 10;
> > + Frequency = Transponder() * 100;//XXX
> > + dsyslog("Frequency = %08X, Transponder = %d",
> > sd->getFrequency(), Transponder());//XXX static int Bandwidths[] =
> > { 800, 700, 600, 500, 0, 0, 0, 0 };
> > dtp.SetBandwidth(Bandwidths[sd->getBandwidth()]); static int
> > Constellations[] = { QPSK, QAM_16, QAM_64, QAM_AUTO };  
> 
> It works. I had to have VDR recreate the channels because it was
> mixing things up with the already existing ones.
> 
> As to why the frequency is set to "-10" I don't know (yet), but I
> remember it has always been like this since 2005. 

Here is the explanation why the frequency field in French DVB-T shall
not be used, (cf. CSA-Profil-de-signalisationv3.4.pdf, page 30,
terrestrial_delivery_system_descriptor):

  le terrestrial delivery_system_descriptor diffusés dans la NIT
  correspond au cas général. En effet, la NIT ne décrit pas de façon
  exhaustive le réseau actuel d’émetteurs, mais l’organisation des
  services des multiplex diffusés : ainsi les fréquences des multiplex
  renseignées par le paramètre centre_frequency ont une valeur fixée à
  0x. Ces fréquences ne sont pas à prendre en compte

It says, grosso modo, that the NIT does not describe the network in an
exhaustive manner, but it does for services. Le field centre_frequency
contains the value 0x and is not to be taken into consideration.

--
Patrick.




___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] French DVB-T Channel IDs vs. EIT Channel IDs

2018-03-01 Thread Patrick Boettcher 
On Thu, 1 Mar 2018 10:22:10 +0100
Patrick Boettcher <patrick.boettc...@posteo.de> wrote:

> On Wed, 28 Feb 2018 11:01:23 +0100
> Klaus Schmidinger <klaus.schmidin...@tvdr.de> wrote:
> 
> > On 27.02.2018 17:58, Patrick Boettcher wrote:  
> > > On Tue, 27 Feb 2018 16:54:35 +0100
> > > Klaus Schmidinger <klaus.schmidin...@tvdr.de> wrote:
> > > 
> > >> Hello Patrick,
> > >> 
> > >> your scan doesn't contain the NIT, which is where the transponder
> > >> innformation is broadcast. Can you scan that, too, please?
> > > 
> > > Hi Klaus,
> > > 
> > > NIT attached (from another multiplex with the same symptoms).
> > 
> >  DVB-DescriptorTag: 90 (0x5a)  [=
> > terrestrial_delivery_system_descriptor] descriptor_length: 11 (0x0b)
> >  Center frequency: 0x (= 42949672.095 kHz)
> > 
> > @@ -219,6 +219,8 @@
> >cDvbTransponderParameters dtp;
> >int Source = cSource::FromData(cSource::stTerr);
> >int Frequency = Frequencies[0] =
> > sd->getFrequency() * 10;
> > + Frequency = Transponder() * 100;//XXX
> > + dsyslog("Frequency = %08X, Transponder = %d",
> > sd->getFrequency(), Transponder());//XXX static int Bandwidths[] =
> > { 800, 700, 600, 500, 0, 0, 0, 0 };
> > dtp.SetBandwidth(Bandwidths[sd->getBandwidth()]); static int
> > Constellations[] = { QPSK, QAM_16, QAM_64, QAM_AUTO };  
> 
> It works. I had to have VDR recreate the channels because it was
> mixing things up with the already existing ones.

I called victory too early: something (channel-updates?) is overwriting
the frequencies and modulation-data for all DVB-T-channels.

Please see the attached log-file.

--
Patrick.
Mar  1 11:27:41 vdr vdr: [4099] Frequency = , Transponder = 482
Mar  1 11:27:41 vdr vdr: [4099] changing transponder data of channel 1 (France 2) from 58600:B8D34G8M64S0T8Y0:T to 48200:B8D34G8M64S0T8Y0:T
Mar  1 11:27:41 vdr vdr: [4099] changing transponder data of channel 2 (F3 Paris Ile-de-France) from 58600:B8D34G8M64S0T8Y0:T to 48200:B8D34G8M64S0T8Y0:T
Mar  1 11:27:41 vdr vdr: [4099] changing transponder data of channel 10 (franceinfo:) from 58600:B8D34G8M64S0T8Y0:T to 48200:B8D34G8M64S0T8Y0:T
Mar  1 11:27:41 vdr vdr: [4099] changing transponder data of channel 91 (France 4) from 58600:B8D34G8M64S0T8Y0:T to 48200:B8D34G8M64S0T8Y0:T
Mar  1 11:27:41 vdr vdr: [4099] changing transponder data of channel 92 (France Ô) from 58600:B8D34G8M64S0T8Y0:T to 48200:B8D34G8M64S0T8Y0:T
Mar  1 11:27:41 vdr vdr: [4099] changing transponder data of channel 93 (BFM Paris) from 58600:B8D34G8M64S0T8Y0:T to 48200:B8D34G8M64S0T8Y0:T
Mar  1 11:27:41 vdr vdr: [4099] Frequency = , Transponder = 482
Mar  1 11:27:41 vdr vdr: [4099] changing transponder data of channel 8 (BFM TV) from 58600:B8D34G8M64S0T8Y0:T to 48200:B8D34G8M64S0T8Y0:T
Mar  1 11:27:41 vdr vdr: [4099] changing transponder data of channel 79 (C8) from 58600:B8D34G8M64S0T8Y0:T to 48200:B8D34G8M64S0T8Y0:T
Mar  1 11:27:41 vdr vdr: [4099] changing transponder data of channel 80 (CNEWS) from 58600:B8D34G8M64S0T8Y0:T to 48200:B8D34G8M64S0T8Y0:T
Mar  1 11:27:41 vdr vdr: [4099] changing transponder data of channel 81 (CSTAR) from 58600:B8D34G8M64S0T8Y0:T to 48200:B8D34G8M64S0T8Y0:T
Mar  1 11:27:41 vdr vdr: [4099] changing transponder data of channel 82 (Gulli) from 58600:B8D34G8M64S0T8Y0:T to 48200:B8D34G8M64S0T8Y0:T
Mar  1 11:27:41 vdr vdr: [4099] Frequency = , Transponder = 482
Mar  1 11:27:41 vdr vdr: [4099] changing transponder data of channel 72 (CANAL+) from 58600:B8D34G8M64S0T8Y0:T to 48200:B8D34G8M64S0T8Y0:T
Mar  1 11:27:41 vdr vdr: [4099] changing transponder data of channel 73 (CANAL+ CINEMA) from 58600:B8D34G8M64S0T8Y0:T to 48200:B8D34G8M64S0T8Y0:T
Mar  1 11:27:41 vdr vdr: [4099] changing transponder data of channel 74 (CANAL+ SPORT) from 58600:B8D34G8M64S0T8Y0:T to 48200:B8D34G8M64S0T8Y0:T
Mar  1 11:27:41 vdr vdr: [4099] changing transponder data of channel 75 (PLANETE+) from 58600:B8D34G8M64S0T8Y0:T to 48200:B8D34G8M64S0T8Y0:T
Mar  1 11:27:41 vdr vdr: [4099] changing transponder data of channel 76 (LCI) from 58600:B8D34G8M64S0T8Y0:T to 48200:B8D34G8M64S0T8Y0:T
Mar  1 11:27:41 vdr vdr: [4099] changing transponder data of channel 77 (PARIS PREMIERE) from 58600:B8D34G8M64S0T8Y0:T to 48200:B8D34G8M64S0T8Y0:T
Mar  1 11:27:41 vdr vdr: [4099] changing transponder data of channel 78 (CANAL+) from 58600:B8D34G8M64S0T8Y0:T to 48200:B8D34G8M64S0T8Y0:T
Mar  1 11:27:41 vdr vdr: [4099] Frequency = , Transponder = 482
Mar

Re: [vdr] French DVB-T Channel IDs vs. EIT Channel IDs

2018-03-01 Thread Patrick Boettcher 
On Wed, 28 Feb 2018 11:01:23 +0100
Klaus Schmidinger <klaus.schmidin...@tvdr.de> wrote:

> On 27.02.2018 17:58, Patrick Boettcher wrote:
> > On Tue, 27 Feb 2018 16:54:35 +0100
> > Klaus Schmidinger <klaus.schmidin...@tvdr.de> wrote:
> >   
> >> Hello Patrick,
> >> 
> >> your scan doesn't contain the NIT, which is where the transponder
> >> innformation is broadcast. Can you scan that, too, please?  
> > 
> > Hi Klaus,
> > 
> > NIT attached (from another multiplex with the same symptoms).  
> 
>  DVB-DescriptorTag: 90 (0x5a)  [=
> terrestrial_delivery_system_descriptor] descriptor_length: 11 (0x0b)
>  Center frequency: 0x (= 42949672.095 kHz)
> 
> @@ -219,6 +219,8 @@
>cDvbTransponderParameters dtp;
>int Source = cSource::FromData(cSource::stTerr);
>int Frequency = Frequencies[0] =
> sd->getFrequency() * 10;
> + Frequency = Transponder() * 100;//XXX
> + dsyslog("Frequency = %08X, Transponder = %d",
> sd->getFrequency(), Transponder());//XXX static int Bandwidths[] =
> { 800, 700, 600, 500, 0, 0, 0, 0 };
> dtp.SetBandwidth(Bandwidths[sd->getBandwidth()]); static int
> Constellations[] = { QPSK, QAM_16, QAM_64, QAM_AUTO };

It works. I had to have VDR recreate the channels because it was mixing
things up with the already existing ones.

As to why the frequency is set to "-10" I don't know (yet), but I
remember it has always been like this since 2005. 

Initial tuning files have always contained all active frequencies for
their region, because the NIT did not set the center frequencies
correctly.

It might be because the multiplexed transport streams are generated
centrally and then distributed to all the base-stations where they are
emitted as-is but on different frequencies depending on the region.

What can we do to get this upstream?

Thanks for your help,
--
Patrick.




___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] French DVB-T Channel IDs vs. EIT Channel IDs

2018-02-27 Thread Patrick Boettcher 
On Tue, 27 Feb 2018 16:54:35 +0100
Klaus Schmidinger  wrote:

> Hello Patrick,
> 
> your scan doesn't contain the NIT, which is where the transponder
> innformation is broadcast. Can you scan that, too, please?

Hi Klaus,

NIT attached (from another multiplex with the same symptoms).

best regards,
--
Patrick.


nit
Description: Binary data
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] French DVB-T Channel IDs vs. EIT Channel IDs

2018-02-26 Thread Patrick Boettcher 
Hi Klaus,

thank you for your reply.

On Mon, 26 Feb 2018 16:58:20 +0100
Klaus Schmidinger  wrote:
> > How should this be fixed correctly?
> > 
> > Is this a regression introduced somewhere?
> > 
> > Can it be solved by configuration?  
>
> where did the channel with ID T-0-506-517 come from in the first
> place?

I ran dvbv5-scan with -O vdr and it gave me the line. I manually
copied it to channels.conf. Upon vdr start I saw that VDR was updating
the PIDs. 

Here's what came out of it:

France 2:586000:B8C23G32M64S0T8Y0:T:0:120=27:0; \
   130=fra@122,131=qad@122,132=qaa@122:0;140=fra,142=fra :0:257:0:0:0

(\ and line break added by me)


> What happens if you delete that channel from VDR's channel list and
> tune to the transponder? Does it create the channel with the correct
> ID?

Good idea. 

I deleted the channel and switched to another channel on the same
transponder.

Nothing happens. VDR does not re-"find" the channel. VDR is set up to
"Add New Transponders".

Running scan -c (current transponder) gives:

0x 0x0101: pmt_pid 0x006e GR1 B -- France 2 (running)
0x 0x0104: pmt_pid 0x0136 GR1 B -- France 4 (running)
0x 0x0105: pmt_pid 0x01fe GR1 B -- France Ô (running)
0x 0x0106: pmt_pid 0x0262 GR1 B -- franceinfo: (running)
0x 0x0111: pmt_pid 0x00d2 GR1 -- F3 Paris Ile-de-France (running)
0x 0x0170: pmt_pid 0x02c6 R1 TFL -- BFM Paris (running)
dumping lists (6 services)
France 2 (0x0101) 01: PCR == V   V 0x0078 SUB 0x008e
France 4 (0x0104) 01: PCR == V   V 0x0140 SUB 0x0156
France Ô(0x0105) 01: PCR == V   V 0x0208 SUB 0x021c
franceinfo   (0x0106) 01: PCR == V   V 0x026c SUB 0x0280
F3 Paris Ile-de-France   (0x0111) 01: PCR == V   V 0x00dc A 0x00e6 (fre) 0x00e7 
(qad) 0x00e8 (qaa) SUB0x00f2
BFM Paris(0x0170) 01: PCR == V   V 0x02d0

(attached is the complete output with -vvv.)

Any idea?

--
Patrick.
pmp@vdr:/var/lib/vdr$ scan -c -vv
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
PAT
PMT 0x0262 for service 0x0106
  VIDEO : PID 0x026c
  OTHER : PID 0x0276 TYPE 0x06
  SUBTITLING: PID 0x0280
PMT 0x0136 for service 0x0104
  VIDEO : PID 0x0140
  OTHER : PID 0x014a TYPE 0x06
  OTHER : PID 0x014b TYPE 0x06
  OTHER : PID 0x014c TYPE 0x06
  SUBTITLING: PID 0x0154
  SUBTITLING: PID 0x0156
PMT 0x02c6 for service 0x0170
  VIDEO : PID 0x02d0
  OTHER : PID 0x02da TYPE 0x06
PMT 0x00d2 for service 0x0111
  VIDEO : PID 0x00dc
  AUDIO : PID 0x00e6
  AUDIO : PID 0x00e7
  SUBTITLING: PID 0x00f0
  AUDIO : PID 0x00e8
  SUBTITLING: PID 0x00f2
PMT 0x01fe for service 0x0105
  VIDEO : PID 0x0208
  OTHER : PID 0x0212 TYPE 0x06
  OTHER : PID 0x0213 TYPE 0x06
  SUBTITLING: PID 0x021c
PMT 0x006e for service 0x0101
  VIDEO : PID 0x0078
  OTHER : PID 0x0082 TYPE 0x06
  OTHER : PID 0x0083 TYPE 0x06
  OTHER : PID 0x0084 TYPE 0x06
  SUBTITLING: PID 0x008c
  SUBTITLING: PID 0x008e
SDT (actual TS)
0x 0x0101: pmt_pid 0x006e GR1 B -- France 2 (running)
0x 0x0104: pmt_pid 0x0136 GR1 B -- France 4 (running)
0x 0x0105: pmt_pid 0x01fe GR1 B -- France Ô (running)
0x 0x0106: pmt_pid 0x0262 GR1 B -- franceinfo: (running)
0x 0x0111: pmt_pid 0x00d2 GR1 -- F3 Paris Ile-de-France (running)
0x 0x0170: pmt_pid 0x02c6 R1 TFL -- BFM Paris (running)
dumping lists (6 services)
France 2 (0x0101) 01: PCR == V   V 0x0078 SUB 0x008e
France 4 (0x0104) 01: PCR == V   V 0x0140 SUB 0x0156
France Ô(0x0105) 01: PCR == V   V 0x0208 SUB 0x021c
franceinfo   (0x0106) 01: PCR == V   V 0x026c SUB 0x0280
F3 Paris Ile-de-France   (0x0111) 01: PCR == V   V 0x00dc A 0x00e6 (fre) 0x00e7 
(qad) 0x00e8 (qaa) SUB 0x00f2
BFM Paris(0x0170) 01: PCR == V   V 0x02d0
Done.
pmp@vdr:/var/lib/vdr$ scan -c -vvv
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
parse_section:1574: pid 0x00 tid 0x00 table_id_ext 0x0001, 0/0 (version 4)
PAT
parse_section:1574: pid 0x262 tid 0x02 table_id_ext 0x0106, 0/0 (version 1)
PMT 0x0262 for service 0x0106
  VIDEO : PID 0x026c
  OTHER : PID 0x0276 TYPE 0x06
  SUBTITLING: PID 0x0280
parse_pmt:1235: 0x 0x0106: (null) -- (null), pmt_pid 0x0262, vpid 0x026c, 
apid 0x ()
parse_section:1574: pid 0x136 tid 0x02 table_id_ext 0x0104, 0/0 (version 0)
PMT 0x0136 for service 0x0104
  VIDEO : PID 0x0140
  OTHER : PID 0x014a TYPE 0x06
  OTHER : PID 0x014b TYPE 0x06
  OTHER : PID 0x014c TYPE 0x06
  SUBTITLING: PID 0x0154
  SUBTITLING: PID 0x0156
parse_pmt:1235: 0x 0x0104: (null) -- (null), pmt_pid 0x0136, vpid 0x0140, 
apid 0x ()
parse_section:1574: pid 0x2c6 tid 0x02 table_id_ext 0x0170, 0/0 (version 1)
PMT 0x02c6 for service 0x0170
  VIDEO : PID 0x02d0
  OTHER : PID 0x02da TYPE 0x06
parse_pmt:1235: 0x 0x0170: (null) -- (null), pmt_pid 0x02c6, vpid 0x02d0, 
apid 0x ()

[vdr] French DVB-T Channel IDs vs. EIT Channel IDs

2018-02-25 Thread Patrick Boettcher 
Hi list,

since some time (1-2 years) I noticed that the DVB-T channels do not
show EPG anymore. I'm not sure what is the root-cause: either it
was the migration of French DVB-T to HD (in 2016) or an update of VDR.

Anyway, this morning I took the time to figure out what is wrong and
here is what I found. 

In short, the channel-ID generated from the one received in the EIT
does not correspond to a known channel-ID from the channel list, and
VDR drops the whole section:

In cEIT::cEIT (from eit.c) we see

  tChannelID channelID(Source, getOriginalNetworkId(), getTransportStreamId(), 
getServiceId());
  cChannel *Channel = Channels->GetByChannelID(channelID, true);

and channel is NULL in my case.

I added some debug prints to GetByChannelID() in the search loop:

  printf("sid: %d == %d, %s, %s %d\n", 
 Channel->Sid(), 
 sid,
 (const char *)ChannelID.ToString(),
 (const char *)Channel->GetChannelID().ToString(),
 Channel->GetChannelID() == ChannelID);

And here is an example of what I get:

  sid: 517 == 517, T-8442-2-517, T-0-506-517 0

The internal channel ID of vdr reads T-0-506-517. 517 is the SID, 506
is the radio-channel frequency in MHz. This is the right internal
channel for this EIT-section.

The EIT-channel-ID is telling me that 8442 is the original network ID
and 2 might be the radio-channel ID.

I tweaked the operator==() of ChannelID to make it work, but not in a
contributable manner. 

How should this be fixed correctly?

Is this a regression introduced somewhere?

Can it be solved by configuration?

Thanks for any help.

best regards,
--
Patrick.













___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] broken recordings

2016-08-08 Thread Patrick Boettcher 
On Mon, 8 Aug 2016 22:51:13 +0200
Patrick Boettcher <patrick.boettc...@posteo.de> wrote:

> Hi,
> 
> On Mon, 8 Aug 2016 20:30:33 +0200
> Matthias Bodenbinder <matth...@bodenbinder.de> wrote:
> 
> > Hello Christoph,
> > 
> > based on your feedback I made another test. The USB HD performance
> > seems to be ok (see my other reply). But anyways I made a test with
> > recording directly to the Flash SD card. And that works pretty well.
> > 15 min without issue. So it looks like it is indeed an issue with
> > USB on the Raspberry PI 2. Any idea how to solve that?  
> 
> It _could_ be the write-cache-flush which saturates the bus and then
> dramatically decreases I/O of the overall system.
> 
> Try
> 
> hdparm -W 0 /dev/
> 

You could also try iotop, which should I/O activity of all processes,
maybe there is something going on.

sudo apt install iotop
sudo iotop

Thanks,
-- 
Patrick.

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] broken recordings

2016-08-08 Thread Patrick Boettcher 
Hi,

On Mon, 8 Aug 2016 20:30:33 +0200
Matthias Bodenbinder  wrote:

> Hello Christoph,
> 
> based on your feedback I made another test. The USB HD performance
> seems to be ok (see my other reply). But anyways I made a test with
> recording directly to the Flash SD card. And that works pretty well.
> 15 min without issue. So it looks like it is indeed an issue with USB
> on the Raspberry PI 2. Any idea how to solve that?

It _could_ be the write-cache-flush which saturates the bus and then
dramatically decreases I/O of the overall system.

Try

hdparm -W 0 /dev/

which might work. I had mixed results with this command on a PC back
then when I wanted to store a continuous stream which came in at 33
MiB/s and lead to data drop due to write-caches on an SSD...

My parents use your setup with an HDD connected to USB and receiving
all DVB over network (which is USB on the RPI2) and have no problems.

You might also try to replace your raspberry Pi - maybe there is
another problem somewhere (if you already did this, sorry, I
must have over-read it).

regards,

-- 
Patrick.

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Sat>IP-plugin: how to configure 2 DD Octopus NETs with different satellites

2016-07-19 Thread Patrick Boettcher 
On Tue, 19 Jul 2016 02:37:42 +0200
"fnu"  wrote:

> Hi,
> 
> I remember that Rolf always does suggest to use "OctopusNet" or
> "minisatip" as device name.

Yep, that's for the quirks, I think. I simply copied the string as I
found them in the README.

> The other stuff, hmm, I don't know, as the plugin follows quite
> straight the
> SAT>IP specifications. Your add-on is maybe the point to discuss with
> SAT>the  
> original author Rolf.

In the spec I found the description of the fe and src argument. They say
that, AFAIU, the src-arg depends on the configuration of your
satip-environment and that it is the client-side which should be
configured to use it correctly. I assume it is the same for the fe-arg.

I would be delighted if Rolf joins this thread. For the moment I
continue to explore things.

Thanks,
--
Patrick.

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Sat>IP-plugin: how to configure 2 DD Octopus NETs with different satellites

2016-07-18 Thread Patrick Boettcher 
Hi fnu,

Thank you for your answer.

On Mon, 18 Jul 2016 10:29:58 +0200
"fnu" <v...@auktion.hostingkunde.de> wrote:

> Dear Patrick,
> 
> changes in "sources.conf" are IIRC only necessary if you have a
> DiSEqC configuration controlled by VDR. But using a/the generic
> sources.conf doesn't harm VDR operation, I guess most users do have
> one without DiSEqC.

That seems to be true. Before looking at the code of the satip-plugin I
thought that I could limit magically the created (virtual)
satipDevices to the Sources assigned to them via the diseqc.conf.

> You may use a workaround by using CAID field for specific adapter:
> 
> https://www.linuxtv.org/vdrwiki/index.php/Syntax_of_channels.conf#CA_-_Conditional_access

Yeah, no, I don't like this.
 
> But I do not now if it is possible to cover more than 4 devices and
> no good idea how to tie a SAT>IP device always to the same number.

As said above, I dug into the code and saw that nothing can be done with
standard vdr-config-files. Neither diseqc.conf nor sources.conf can
help.

However, I added some code and now it works as I wanted it to work.

I did this by adding a Source-member to the satipFrontend created by
satipServer and in satipFrontend::Assign() I additionally check whether
the requested source can be delivered by this frontend.

In my environment, where I have one VDR which will use all
satip-devices, this is exactly what I need.

Now, how to get that correctly done?

Automatic detection? I haven't seen any option on the Octopus-device
that would help the satip-plugin to identify automatically the
source/input when it does the discovery.

So, I'd opt for the command-line-parameter-option: I'd add an
additional parameter to the plugin which will assign the correct source
to the satipFrontend. Which would only work if the -s-option is given.
Maybe it could be even part of the -s-option.. Let's try:

  --server=192.168.1.21|DVBS2-4|Octo1;192.168.1.20|DVBS2-2,DVBT2-2|Octo2

becomes

  --server=192.168.1.21|DVBS2-4|Octo1|S19.2E,S19.2E,S19.2E,S19.2E; \
192.168.1.20|DVBS2-2,DVBT2-2|Octo2|S28.2E,S28.2E,T,T

Looks good to me. I'll try that. 

This will surely work, however, right now, the satip-plugin does not
use the fe=-parameter the RTSP-URL for that. So even with this syntax,
it won't be possible to mix different satellites on _one_ Octopus NET.

Like '[..]Octo2|S28.2E,S19.2E,S28.2E,S19.2E' wouldn't work without
changing the URL-creation-method. It even looked like that the URL is
created before the satipFrontend is chosen. That would have to be
changed.

best regards,
-- 
Patrick Boettcher

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] SatIP>plugin: how to configure 2 DD Octopus NETs with different satellites

2016-07-17 Thread Patrick Boettcher 
Hi,

I have 2 DD Octopus NET devices. One is a 2x DVB-S(2) + 2x DVB-T(2)
(let's call it AA) and the other one is 4x DVB-S(2) (BB).

AA's satellite orientation is Astra 28.2, BB's one is Astra 19.2.

How can I associate AA's or BB's inputs in VDR's configuration so that
it uses 

  1) the right input for the right source

  2) the maximum number of devices in parallel for recording,
 epg-scanning etc.

conf.d/50-satip.conf contains 

  --devices=8
  --server=192.168.1.21|DVBS2-4|Octo1;192.168.1.20|DVBS2-2,DVBT2-2|Octo2


I found discussions where they say that in sources.conf one needs to
assigned device numbers, so I tried:

  S19.2E 1 Astra 1KR/1L/1M/2C
  S19.2E 2 Astra 1KR/1L/1M/2C
  S19.2E 3 Astra 1KR/1L/1M/2C
  S19.2E 4 Astra 1KR/1L/1M/2C
  S28.2E 5 Astra 1N/2A/2F
  S28.2E 6 Astra 1N/2A/2F

This isn't working, it seems that even for S28.2 channels it selects the
S19.2-devices.

Then I changed the diseqc.conf to

  1 2 3 4:
  S19.2E  11700 V  9750  t v W15 [E0 10 38 F0] W15 A W15 t
  S19.2E  9 V 10600  t v W15 [E0 10 38 F1] W15 A W15 T
  S19.2E  11700 H  9750  t V W15 [E0 10 38 F2] W15 A W15 t
  S19.2E  9 H 10600  t V W15 [E0 10 38 F3] W15 A W15 T

  5 6:
  S28.2E  11700 V  9750  t v W15 [E0 10 38 F4] W15 B W15 t
  S28.2E  9 V 10600  t v W15 [E0 10 38 F5] W15 B W15 T
  S28.2E  11700 H  9750  t V W15 [E0 10 38 F6] W15 B W15 t
  S28.2E  9 H 10600  t V W15 [E0 10 38 F7] W15 B W15 T

Didn't help.

Is there anything I can do? 

Thanks in advance for any help.

Best regards,
-- 
Patrick.

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR deleting non-.del-dirs in video-path

2016-02-16 Thread Patrick Boettcher 
On Wed, 17 Feb 2016 08:29:10 +0100
Reiner Bühl  wrote:

> The easiest way to fix this would be to separate backup and video
> dir. Why don't you create two directories on your USB HDD and link
> them into different locations? E.g. Mount the HDD as /mnt/usbdisk and
> then create a symbolic link /video that points to /mnt/usbdisk/video
> and one symbolic link /backup that points to /mnt/usbdisk/backup.
> Or just create two partitions on the external disk and mount them 
> directly to the right places?

To be totally honest, that's what I did just now. 

I was just surprised seeing in the logs that VDR actually was "cleaning"
my backup.

Thinking about it, the video-dir is VDR's file-system, it can do
what it wants.

--
Patrick.





___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] VDR deleting non-.del-dirs in video-path

2016-02-16 Thread Patrick Boettcher 
Hi list,

I'm using a Raspi2 for vdr and attached a HDD over USB for storage.

I'm also backuping the rootfs (SD-card) onto the HDD on a regular basis.

Checking the logs for another problem it turns out the it enters my
backup-dir and tries to delete empty-directories. 

I read in the ML-archive that this is normal behavior. Is there
anything I can do to prevent this? Telling vdr to ignore it.

best regards,
--
Patrick.



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR + SatIP + Octopus Net - no more data on SD channels

2016-01-05 Thread Patrick Boettcher 
On Sun, 3 Jan 2016 22:29:20 +0100
Patrick Boettcher <patrick.boettc...@posteo.de> wrote:
> Everything works fine. Except that after some time streaming on
> SD-channels seems to stop. Zapping to a HD-channels works.
> 
> When trying to receive a non-working SD-stream I can see, via the
> satip-config-menu, that no PIDs seem to be delivered.
> 
> Restarting the vdr-process (via the menu) works.
> 
> While trying to understand the problem I have the feeling that zapping
> to non-existent services makes it appear faster. Not sure though.
> 
> Is this a known issue?

Replying to myself. E-Tobi's version of satip is currently 2.2.0 - the
one with which I encountered my problems.

Just after writing my Email I updated to 2.2.3 and the described issues
have disappeared.

--
Patrick.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] VDR + SatIP + Octopus Net - no more data on SD channels

2016-01-03 Thread Patrick Boettcher 
Hi list,

I'm facing a problem with the following configuration:

- VDR on a Raspi2 (raspian with packages from e-tobi)
- Digital Devices' Octopus Net with 2 DVB-S2 receivers

I'm using vdr-plugin-satip with the following arguments:

-s |DVBS2-2|Octo -d 2

Everything works fine. Except that after some time streaming on
SD-channels seems to stop. Zapping to a HD-channels works.

When trying to receive a non-working SD-stream I can see, via the
satip-config-menu, that no PIDs seem to be delivered.

Restarting the vdr-process (via the menu) works.

While trying to understand the problem I have the feeling that zapping
to non-existent services makes it appear faster. Not sure though.

Is this a known issue?

What can I do to better analyse the problem?

Thanks in advance for any help.

--
Patrick.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] xineliboutput and streamdev at the same time

2015-04-20 Thread Patrick Boettcher 
On Mon, 20 Apr 2015 16:05:45 +0300 Marko Mäkelä marko.mak...@iki.fi
wrote:

 On Mon, Apr 20, 2015 at 11:40:41AM +0200, Patrick Boettcher wrote:
 vdr-fbfe is connecting over network to a vdr running on a full
 machine. No need for streamdev.
 
 This looks interesting. Am I right assuming that the full machine
 will not need any video output? 

Yes, you are right. Vdr is running like a daemon.

 Can vdr-fbfe be used for editing recordings on the RPi, or is
 there too much latency when using 10Mb/s Ethernet to connect to an
 old VDR server? 

I'd not recommend a 10Mb/s. Fast Ethernet (100Mb/s) should be the
minimum.

 How about using vdr-fbfe to connect on a vdr instance running on the 
 same RPi machine? 

Yes.

 Is it technically possible to for example pause a
 live SD TV stream and copy some files over the Ethernet at the same
 time? 

Which scenario? VDR on RPI or on a remote? If VDR on a remote host,
IIRC, pausing causes very few bandwidth as only a still image is
displayed. 

The pause is global to all connected clients to this vdr-remote. Yes,
you can connect several clients to one xineliboutput-vdr-host but they
will all have the same channel and OSD appearances displayed - IOW,
they are not independent.

 The single USB bus on the RPi would in that case need to handle
 the traffic of a hard disk adapter as well as the DVB dongle and the
 built-in Ethernet controller.

Yes. IMHO, it is better to use RPI only as client with no harddisk. 

--
Patrick.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] xineliboutput and streamdev at the same time

2015-04-20 Thread Patrick Boettcher 
On Mon, 20 Apr 2015 11:33:02 +0200 Torgeir Veimo
torgeir.ve...@gmail.com wrote:

 Have you tried rpihddevice plugin with VDR on the rpi? It might work
 even smoother than using xinelinboutput, but you'd have to find a
 different setup for cec i suppose.
 
 http://projects.vdr-developer.org/git/vdr-plugin-rpihddevice.git/

I think the big difference between rpihddevice and vdr-fbfe is that
the vdr-fbfe does not need a local vdr-instance running on the device.
vdr-fbfe is connecting over network to a vdr running on a full
machine. No need for streamdev.

Thank you both for your input.

regards,
--
Patrick.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] from xineliboutput to ... perhaps softhdddevice?

2015-04-17 Thread Patrick Boettcher 
Hi all,

On Fri, 17 Apr 2015 09:25:22 +0300 Füley István airo...@tigercomp.ro
wrote:

 I know, it's not a proper answer for your problem, but I think at the 
 moment the best native vdr client is a Raspberry Pi with Thomas
 Reufer's great plugin. It's small, cheap and (using with vdr) it's
 fast.
 
 I moved from vdr-sxfe to rpihddevice with all my 3 clients in the
 house.

And you are using streamdev-server on your vdr-host (which has all the
DVB-cards) and client on the RPI?

regards,
--
Patrick.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] xinelib / vdpau suddenly fails to detect Nvidia ION GPU

2014-01-01 Thread Patrick Boettcher 
Hi,

On Thursday 26 December 2013 19:13:05 Harald Milz wrote:
 Any idea where I should look? Why might xinelib or vdr-sxfe fail to
 correctly detect the ION (MCP79) chip when everything is unchanged? 
Yes I
 ran an apt-get upgrade on the underlying Ubuntu 12.04.3 OS but this 
didn't
 change anything, apparently.

If this upgrade upgraded the xorg-stuff, most likely some of the xorg-
libraries, which are normally overwritten by the NVIDIA-driver (assuming you 
are using the proprietary driver), have been re-overwritten.

Try to reinstall the proprietary NVIDIA-driver.

regards,
-- 
Patrick 
___
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

2012-04-09 Thread Patrick Boettcher 
On Monday 09 April 2012 13:39:36 Dominic Evans wrote:
 On 9 April 2012 10:40, Klaus Schmidinger klaus.schmidin...@tvdr.de 
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

Re: [vdr] Bug in pat.c (VDR 1.7.27) - possible fix attached

2012-04-09 Thread Patrick Boettcher 
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 Schmidingerklaus.schmidin...@tvdr.de
  
  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] Bug in pat.c (VDR 1.7.27) - possible fix attached

2012-04-08 Thread Patrick Boettcher 
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. 

Please consider applying soon.

Thanks,
--
Patrick

http://www.kernellabs.com/
diff --git a/pat.c b/pat.c
index d9b93f6..f0d0024 100644
--- a/pat.c
+++ b/pat.c
@@ -456,12 +456,30 @@ void cPatFilter::Process(u_short Pid, u_char Tid, const u_char *Data, int Length
  }
   }
   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;
-  break;
+  case 0x80: {
+  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;
+  // http://www.smpte-ra.org/mpegreg/mpegreg.html
+  switch (rd-getFormatIdentifier()) {
+  case 0x44434949: // STREAMTYPE_USER_PRIVATE - DigiCipher II VIDEO (ANSI/SCTE 57)
+  Vpid = esPid;
+  Ppid = pmt.getPCRPid();
+  Vtype = 0x02; // compression based upon MPEG-2
+  ProcessCaDescriptors = true;
+  break;
+  default:
+  break;
+  }
+  } break;
+  default:
+  break;
+  }
+  }
+  } break;
+
   case 0x81: // STREAMTYPE_USER_PRIVATE - ATSC A/53 AUDIO (ANSI/SCTE 57)
   {
   char lang[MAXLANGCODE1] = { 0 };
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] recordings not deleted in additional video-dirs (video.0x)

2011-01-10 Thread Patrick Boettcher 
Hi all,

First let me descibe my setup:

I'm using VDR from http://e-tobi.net/vdr-experimental (vdr (1.7.16/1.7.16), 
1.7.16-2~ctvdr1 - vdr-abi-1.7.16-multipatch) 

I switched to vdr-experimental beginning of November 2010. I think the version 
I'm using now (above) is available only since last week (before it was 1.7.16-
something else). 
I don't know what has changed and whether my problem persists with this 
version and I can't easily check any longer. However, I'm sure that the 
previous one was having the following problem:

Until recently I used 2 partitions for recordings:

/var/lib/video - /var/lib/video.00
/var/lib/video.00
/var/lib/video.01

/var/lib/video.01 is what I called additional video-dir in the subject. VDR 
puts some files (.ts or .vdr respectively) into /var/lib/video.01 and creates 
symbolic links from /var/lib/video.00 .

I'm not sure whether this feature is added by multipatch or included in 
vanilla-vdr.

When now I merged the two video.0x directories onto a new partition I resolved 
the symbolic links with a small script and mv'd the corresponding files into 
the right place. When this was done I realized that there were still plenty of 
.ts and .vdr files which had no longer any reference in the original video.00-
directory. 

All the files that were left are files from recordings I deleted after 
switching 
to vdr-1.7.16 . Those were recordings from before and after switching to 
vdr-1.7.16 .

I hope what I'm writing is clear. If I'm finding the time I will take a look at 
the vdr-source from the package, but don't count on it...

best regards,
--
Patrick 

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] recordings not deleted in additional video-dirs (video.0x)

2011-01-10 Thread Patrick Boettcher 
On Monday 10 January 2011 23:41:48 Tobias Grimm wrote:
 Am Montag, den 10.01.2011, 23:28 +0100 schrieb Patrick Boettcher:
  When now I merged the two video.0x directories onto a new partition I
  resolved the symbolic links with a small script and mv'd the
  corresponding files into the right place. When this was done I realized
  that there were still plenty of .ts and .vdr files which had no longer
  any reference in the original video.00- directory.
 
 A known bug in VDR 1.7.16. In the Debian package I fixed this in version
 1.7.16-2~ctvdr1 with a patch provided by Steffen Barszus:

Thanks to both of you, good job!

--
Patrick.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR can no longer be compiled with the current driver from http://linuxtv.org/hg/v4l-dvb.

2009-10-22 Thread Patrick Boettcher 




On Sun, 2009-06-14 at 13:49 +0200, Klaus Schmidinger wrote:
...

If you use a full featured DVB card for replay you need the DVB driver
version from

  http://linuxtv.org/hg/v4l-dvb


The driver had its API version changed on 2009-10-19 17:08:05:

--- v4l-dvb-af3d28c7ef19/linux/include/linux/dvb/version.h  2009-06-21 
02:25:44.0 +0200
+++ v4l-dvb-f6680fa8e7ec/linux/include/linux/dvb/version.h  2009-10-19 
17:08:05.0 +0200

@@ -24,6 +24,6 @@
#define _DVBVERSION_H_

#define DVB_API_VERSION 5
-#define DVB_API_VERSION_MINOR 0
+#define DVB_API_VERSION_MINOR 1

#endif /*_DVBVERSION_H_*/


This modification was done due to the introduction of ISDB-T and ISDB-Tsb to 
the API.


Normally, in the sense of only being a human being doing lots of mistakes, the 
API is completely backward and binary compatible. Except for this 
minor-version-change.


If there was a mistake and it's not compatible, we still can fix it, as kernel 
2.6.32 is not yet out.


best regards,
--

Patrick Boettcher - Kernel Labs
http://www.kernellabs.com/

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] DVB-H

2009-05-13 Thread Patrick Boettcher 
Hi Theunis,

On Wed, 13 May 2009, Theunis Potgieter wrote:

 Hi, is dvb-h a subset of dvb-t? our country decided to switch on
 dvb-t, we receive dvb-t and dvb-h with h.264.

DVB-H is more than just DVB-T plus H264 services. I strongly think that 
what you're having in your country is standard DVB-T with normal H264 
services how they are supported with VDR 1.7.

DVB-H is using also H264 to encode video streams, but is encapsulating it 
in RTP over DVB-MPE. Up to now I don't know any complete DVB-H reception 
chain, though there are some starting points which can be found in the 
dvb-apps repository at linuxtv.org and at other places. But before you're 
diving in to that, I recommend that you're first trying to find out 
whether it is really DVB-H you're looking for or DVB-T with H264. DVB-H 
service however are designs for handheld devices with small screens, most 
likely the video quality will not be very nice when watching it on a 
full-screen desktop/TV replacement.

HTH,
Patrick.

--
   Mail: patrick.boettc...@desy.de
   WWW:  http://www.wi-bw.tfh-wildau.de/~pboettch/

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] DVB-H

2009-05-13 Thread Patrick Boettcher 
On Wed, 13 May 2009, Theunis Potgieter wrote:

 So far I only pick something up on 586MHz and 706MHz

 w_scan produces this:

 tune to: :586000:I999B8C999D999M999T999G999Y0:T:27500:
 --no signal--
 tune to: :586000:I999B8C999D999M999T999G999Y0:T:27500: (no signal)
 INT(Provider)
 SS1(Provider)
 SS2(Provider)
 SS3(Provider)
 CNN(Provider)
 eNews(Provider)
 E! Entertainment(Provider)
 SABC(Provider)
 Cartoon Network(Provider)
 ESG CBMS(Provider)
 Bootstrap-Nokia(Provider)
 Nokia-ESG(Provider)

This really looks like a real DVB-H broadcast. You won't be able to use 
this with VDR for now - like I explained in my previous Email.

 Network Name 'Thomson'
 tune to: :706000:I999B8C999D999M999T999G999Y0:T:27500:
 Network Name 'DTT Network'
 M-Net(MCA)
 CSN(MCA)
 MStar(MCA)
 Actio(MCA)
 ChO(MCA)
 Blitz(MCA)
 NaGeo(MCA)
 AJE(MCA)
 dumping lists (21 services)
 M-Net:706000:I999B8C999D999M999T999G999Y0:T:27500:273:34:0:608:1010:0:0:0
 CSN:706000:I999B8C999D999M999T999G999Y0:T:27500:289:290:0:608:1020:0:0:0
 MStar:706000:I999B8C999D999M999T999G999Y0:T:27500:305:306:0:608:1030:0:0:0
 Actio:706000:I999B8C999D999M999T999G999Y0:T:27500:321:322:0:608:1040:0:0:0
 ChO:706000:I999B8C999D999M999T999G999Y0:T:27500:337:0:0:608:1050:0:0:0
 Blitz:706000:I999B8C999D999M999T999G999Y0:T:27500:353:0:0:608:1060:0:0:0
 NaGeo:706000:I999B8C999D999M999T999G999Y0:T:27500:369:0:0:608:1070:0:0:0
 AJE:706000:I999B8C999D999M999T999G999Y0:T:27500:385:32:0:608:1080:0:0:0


 Are those VDR generated channels.conf lines correct?

Please check in README/Manual of VDR or on the Wikis which can be found in 
several places all over the internet. I'm sure this question can be 
answered there ;)

Patrick.

--
   Mail: patrick.boettc...@desy.de
   WWW:  http://www.wi-bw.tfh-wildau.de/~pboettch/

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] DVB-H

2009-05-13 Thread Patrick Boettcher 
On Wed, 13 May 2009, Theunis Potgieter wrote:

 My country is South Africa,  (soccer host for world cup 2010) so it
 would be nice, if there was any kinda information on dvb-h + vdr.

As I said before: DVB-H and VDR I think it will be hard to do and the 
outcome would be minimal, as VDR is a software for full-screen huge 
display sets and DVB-H service is meant for handheld (very small screens).

 So would you advise me to move to vdr-1.7.7 to see if I can get H.264?

Yes, and you may try the old-fashion scan to generate vdr channels.conf . 
It will only give a useful channels.conf when it's not H264 services.

Patrick.

--
   Mail: patrick.boettc...@desy.de
   WWW:  http://www.wi-bw.tfh-wildau.de/~pboettch/

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [v4l-dvb-maintainer] [Wanted] dvb-ttpci maintainer

2008-09-25 Thread Patrick Boettcher 
Hi,

On Fri, 26 Sep 2008, Niels Wagenaar wrote:
 [..] Maybe it's bad that 2 years of development has gone down 
 the drain. [..] (talking about mutliproto)

Only a small part of all multiproto changes will go down the drain: The 
drivers written especially for multiproto can and will be converted and 
merged. The same will happen with the dvb-driver-core changes. Preferable 
by Manu, as he knows those drivers and their hardware best.

S2API (DVBv5) mainly adds features to the user-interface 
(include/linux/frontend.h) along with some necessary changes in the 
dvb-driver-core. The latter are relatively small and not incompatible with 
the needs of multiproto's internal changes.

The dvb-driver-core mechanisms can be changed at any time - whereas the 
user-interface cannot.

Patrick.

--
   Mail: [EMAIL PROTECTED]
   WWW:  http://www.wi-bw.tfh-wildau.de/~pboettch/


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr-xine + mplayer-plugin + MPlayer - is it possible ?

2008-06-10 Thread Patrick Boettcher 
I don't know if this is applicable for your setup, but did you try 
vdr-plugin-xineliboutput instead of vdr-plugin-xine?

It is at least 3 things in one:

- Client/Server architecture: splits VDR (server) and displaying software
- Media Player integrated (via OSD)
- X11 (XV or others) display (vdr-sxfe)

Patrick.

On Tue, 10 Jun 2008, Goga777 wrote:

 Hi

 i try to run MPlayer on my vdr 170 + mplayer-plugin from HG + vdr-xine  (if 
 it possible)

 in mplayer.sh I have written

 #!/bin/sh
 CMDLINE=mplayer -fs -vo xv -ao alsa -cache 4096 -slave -nolirc -quiet
 DISPLAY=:0.0 $CMDLINE $1 |logger
 exit


 but after the start of reply some file with mplayer-plugin I have

 resume: resume file is '/mnt/asp/video/hdtv/.mplayer.resume'
 resume: assuming empty resume file
 [VO_XV] Could not grab port 65.
 [VO_XV] Could not find free Xvideo port - maybe another process is already
 [VO_XV] using it. Close all video applications, and try again. If that does
 [VO_XV] not help, see 'mplayer -vo help' for other (non-xv) video out drivers.
 Error opening/initializing the selected video_out (-vo) device.


 Jun 8 01:54:53 localhost logger: MPEG-PES file format detected.
 Jun 8 01:54:53 localhost logger: 
 ==
 Jun 8 01:54:53 localhost logger: Opening audio decoder: [liba52] AC3 decoding 
 with liba52
 Jun 8 01:54:53 localhost logger: AUDIO: 48000 Hz, 2 ch, s16le, 448.0 
 kbit/29.17% (ratio: 56000-192000)
 Jun 8 01:54:53 localhost logger: Selected audio codec: [a52] afm: liba52 
 (AC3-liba52)
 Jun 8 01:54:53 localhost logger: 
 ==
 Jun 8 01:54:53 localhost logger: AO: [alsa] 48000Hz 2ch s16le (2 bytes per 
 sample)
 Jun 8 01:54:53 localhost logger: Video: no video
 Jun 8 01:54:53 localhost logger: Starting playback...
 Jun 8 01:54:59 localhost kernel: dvb_frontend_ioctl: FESTATE_RETUNE: 
 fepriv-state=2
 Jun 8 01:55:03 localhost logger:
 Jun 8 01:55:03 localhost logger:
 Jun 8 01:55:03 localhost logger: Exiting... (End of file)
 Jun 8 01:55:04 localhost vdr: [11413] mplayer: player thread ended (pid=11233)
 Jun 8 01:55:08 localhost vdr: [11420] mplayer: mplayer child started 
 (pid=11420)
 Jun 8 01:55:08 localhost vdr: [11423] mplayer: player thread started 
 (pid=11233)
 Jun 8 01:55:08 localhost logger: MPlayer dev-SVN-r26871-4.2.4 (C) 2000-2008 
 MPlayer Team
 Jun 8 01:55:08 localhost logger: CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz 
 (Family: 15, Model: 3, Stepping: 4)
 Jun 8 01:55:08 localhost logger: CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 
 SSE: 1 SSE2: 1
 Jun 8 01:55:08 localhost logger: Compiled for x86 CPU with extensions: MMX 
 MMX2 SSE SSE2
 Jun 8 01:55:08 localhost logger:
 Jun 8 01:55:08 localhost logger: Playing /mnt/asp/video/hdtv/1muz.ts.
 Jun 8 01:55:08 localhost logger:
 Jun 8 01:55:08 localhost logger: TS file format detected.
 Jun 8 01:55:08 localhost logger: VIDEO H264(pid=53 AUDIO MPA(pid=725) NO SUBS 
 (yet)! PROGRAM N. 18
 Jun 8 01:55:08 localhost logger: FPS seems to be: 25.00
 Jun 8 01:55:08 localhost logger: 
 ==
 Jun 8 01:55:08 localhost logger: Opening audio decoder: [mp3lib] MPEG 
 layer-2, layer-3
 Jun 8 01:55:08 localhost logger: AUDIO: 48000 Hz, 2 ch, s16le, 128.0 
 kbit/8.33% (ratio: 16000-192000)
 Jun 8 01:55:08 localhost logger: Selected audio codec: [mp3] afm: mp3lib 
 (mp3lib MPEG layer-2, layer-3)
 Jun 8 01:55:08 localhost logger: 
 ==
 Jun 8 01:55:08 localhost logger: AO: [alsa] 48000Hz 2ch s16le (2 bytes per 
 sample)
 Jun 8 01:55:08 localhost logger: Video: no video
 Jun 8 01:55:08 localhost logger: Starting playback...
 Jun 8 01:55:10 localhost kernel: dvb_frontend_ioctl: FESTATE_RETUNE: 
 fepriv-state=2
 Jun 8 01:55:20 localhost vdr: [11237] frontend 0 timed out while tuning to 
 channel 2782, tp 111055
 Jun 8 01:55:20 localhost kernel: dvb_frontend_ioctl: FESTATE_RETUNE: 
 fepriv-state=2
 Jun 8 01:55:26 localhost logger: TS_PARSE: COULDN'T SYNC
 Jun 8 01:55:26 localhost logger:
 Jun 8 01:55:26 localhost logger:
 Jun 8 01:55:26 localhost logger: Exiting... (End of file)
 Jun 8 01:55:27 localhost vdr: [11423] mplayer: player thread ended (pid=11233)


 I think the xine locked the videocard and due to this MPlayer can't lock it.
 Is it possible to solve this issue ?

 Goga777




 ___
 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] xineliboutput: viewing 16:9 content on 4:3 output device

2008-04-08 Thread Patrick Boettcher 
Hi,

On Tue, 8 Apr 2008, Ian Bates wrote:
 One more remark, if as I believe from the comments in the code above,
 that the '16:9 crop to 4:3' behaviour is not implemented in
 xineliboutput, am I the only one suffering from the lack of this
 feature?  Am I the only one still using a 4:3 TV?  I don't think so,
 what do other people do when viewing 16:9 material on a 4:3 device,
 other than put up with the black bars?

This is exactly what I'm doing - I'm accepting the black bars at the 
bottom and the top, dreaming about the screen I'm going to buy at some 
point in the future, along with being happy for other xineliboutput-users 
having already a 16:9 screen.

Patrick.


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Straw poll: stable version 1.6.0 now?

2008-02-03 Thread Patrick Boettcher 
Hi Klaus,

On Sun, 3 Feb 2008, Klaus Schmidinger wrote:
Should there be a stable version 1.6.0 now, based on what's in
version 1.5.14, but without DVB-S2 or even H.264 support?

With H264 support, because some DVB-T channels (at least here in France) 
are starting to carry H264-channels, afaiu unencrypted.

With Multiproto support (DVB-S2), but only if VDR is able to switch to the 
current DVB-API provided by standard kernels at compile time. I guess 
Multiproto will not be there before 2.6.26 or even later. There is a bunch 
of drivers currently not working with Multiproto.

Thanks,
Patrick

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Straw poll: stable version 1.6.0 now?

2008-02-03 Thread Patrick Boettcher 
On Sun, 3 Feb 2008, Klaus Schmidinger wrote:

 On 02/03/08 13:26, Patrick Boettcher wrote:
  Hi Klaus,
  
  On Sun, 3 Feb 2008, Klaus Schmidinger wrote:
 Should there be a stable version 1.6.0 now, based on what's in
 version 1.5.14, but without DVB-S2 or even H.264 support?
  
  With H264 support, because some DVB-T channels (at least here in France) 
  are starting to carry H264-channels, afaiu unencrypted.
  
  With Multiproto support (DVB-S2), but only if VDR is able to switch to the 
  current DVB-API provided by standard kernels at compile time. I guess 
  Multiproto will not be there before 2.6.26 or even later. There is a bunch 
  of drivers currently not working with Multiproto.
 
 There can only be Yes or No answers ;-)

There can be only yes or no to a yes-or-no question. The latter criteria 
does not apply for yours. 

Maybe shorter: yes, without DVB-S2 support, with H264.

Patrick.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr