[vdr] VDR 1.7 branch and xineliboutput (on Gentoo)

[Ville Aakko]

Hi,

I don't seem to get vdr-xineliboutput working at all on Gentoo.

I used to have vdr-1.6 branch with xineliboutput. Live TV was OK, but
recordings were just unwatchable (vdr-sxfe losing the connection all
the time, rewinding being a PITA etc..). So, I've used Mplayer to play
those, and VDR just as a recording server. But this was very annoying,
so I decided to upgrade to vdr-1.7 and try the vdr-xineliboutput cvs
plugin, to see if it would work better. (I'm an ATI user, but judging
from the symptoms, I suspect there was something very wrong with my
installation, not jsut ATI-related problems).

But, now, I don't get a connection to the vdr-xineliboutput server at
all! I just get the "No Signal" picture. Has anyonve on Gentoo got
this working?

I'm using the vdr-devel repository in addition to stock portage. I
have installed:

vdr-1.7.14-r1 (from vdr-devel)
xine-lib-1.1.18.1
vdr-xineliboutput- (the CVS ebuild from Gentoo portage).

I see the bug report at
. But it is inclear to
me whether the ebuild in portage is updated or not... I will compare
and see of course, but decided to post here to get some input from
fellow users =)

Here's vdr-sxfe output. I'm running vdr-sxfe as a regular user (I've
never got the local pipes working, anyone got an idea how / where to
set the permissions?).

# vdr-sxfe --fullscreen --video=opengl --audio=alsa:phononpulse 127.0.0.1
vdr-sxfe 1.0.90-cvs  (build with xine-lib 1.1.18, using xine-lib 1.1.18)

Fullscreen mode
Video driver: opengl
Audio driver: alsa
Audio device: phononpulse
VDR Server: 127.0.0.1

[11727] [vdr-fe]Error: The name org.gnome.ScreenSaver was not
provided by any .service files
[11727] [vdr-fe]   (ERROR (tools/gnome_screensaver.c,126):
Resource temporarily unavailable)
[11727] [vdr-fe]Detected 2 CPUs
[11727] [vdr-fe]Enabling FFmpeg multithreaded video decoding
[11727] [input_vdr] Connecting (control) to tcp://127.0.0.1:37890 ...
[11727] [input_vdr] Server greeting: VDR-1.7.14 xineliboutput-1.0.90-cvs READY
[11727] [input_vdr] Connected (control) to tcp://127.0.0.1:37890
[11727] [input_vdr] Connecting (data) to
pipe:///etc/vdr/plugins/xineliboutput/pipes.11591/pipe.0
[11727] [input_vdr] Pipe opening failed
[11727] [input_vdr](ERROR (xine_input_vdr.c,5499): Permission denied)
[11727] [input_vdr] Data stream connection failed (PIPE)
[11727] [input_vdr] Connecting (data) to rtp://@224.0.1.9:37890 ...
[11727] [input_vdr] Received UDP/RTP multicast from unknown sender:
192.168.0.3:51915
[11727] [input_vdr] Received UDP/RTP multicast from unknown sender:
192.168.0.3:51915
[11727] [input_vdr] Received UDP/RTP multicast from unknown sender:
192.168.0.3:51915
[11727] [input_vdr] Received UDP/RTP multicast from unknown sender:
192.168.0.3:51915
[11727] [input_vdr] Data stream connection failed (RTP)
[11727] [input_vdr] Connecting (data) to udp://127.0.0.1 ...
[11727] [input_vdr] Data stream connected (UDP)
[11727] [input_vdr] WARNING: xine-engine setting
"engine.buffers.audio_num_buffers":230 istoo low for HD-playback!
Please use values between 500-1000!
[11727] [input_vdr] WARNING: Video output driver reports it does not
support unscaled overlays !
[11727] [demux_vdr] Using decoder "libmpeg2" for mpeg2 video
[11727] [demux_vdr] Using decoder "FFmpeg" for H.264 video
WARNING: MRL does not start with 'xvdr:' (127.0.0.1)

Press Esc to exit

post_warp: warp_get_parameters
post_warp: warp_get_parameters
post_warp: warp_get_parameters
post_warp: warp_get_parameters
post_warp: warp_set_parameters: output_width=0, output_height=0,
output_aspect=0.000, no_downscaling=0
post_warp: warp_get_parameters
post_warp: warp_set_parameters: output_width=720, output_height=0,
output_aspect=0.000, no_downscaling=0
post_warp: warp_get_parameters
post_warp: warp_set_parameters: output_width=720, output_height=576,
output_aspect=0.000, no_downscaling=0
post_warp: warp_get_parameters
post_warp: warp_set_parameters: output_width=720, output_height=576,
output_aspect=0.000, no_downscaling=1
post_warp: warp_get_parameters
post_warp: dispose
post_warp: dispose
[11727] [input_vdr] Connections closed.
Terminating...
[11727] [vdr-fe]Error: The name org.gnome.ScreenSaver was not
provided by any .service files
[11727] [vdr-fe]   (ERROR (tools/gnome_screensaver.c,126):
Resource temporarily unavailable)



-- 
-- 
Ville Aakko - ville.aa...@gmail.com

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

Re: [vdr] VDR 1.7 branch and xineliboutput (on Gentoo)

[Halim Sahin]

Hi,
Check your setup.conf of your vdr and search for
xineliboutput.Remote.LocalIP =
and change it to:
xineliboutput.Remote.LocalIP = 127.0.0.1

Restart vdr and start your vdr-sxfe like this:
# vdr-sxfe --fullscreen --video=opengl --audio=alsa:phononpulse 
xvdr+tcp://127.0.0.1

HTH.
Halim


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

Re: [vdr] VDR 1.7 branch and xineliboutput (on Gentoo)

[Ville Aakko]

2010/5/16 Ville Aakko :
> But, now, I don't get a connection to the vdr-xineliboutput server at
> all! I just get the "No Signal" picture. Has anyonve on Gentoo got
> this working?

My bad!

I had installed a dxr3 card back to my computer, in order to get at
least one well working output for VDR, and enabled the plugin, and
forgot to disable that... because I had both dxr3 plugin and
xineliboutput enabled, VDR thought the dxr3 is the primary device and
send nothing to the xineliboutput frontend... I think =). At least it
works now, that I disabled the dxr3. Thanks for Halim, anyways.

With the 1.7 branch and CVS xineliboutput, the opengl output is
unusable (with the 1.6 branch / 1.0.4_p20091118 xineliboutput opengl
was the most usable output). SDL, and XV work well, and even
recordings now seem to work!

However, The OSD is very ugly! Seems like everything in the OSD is
scaled to 512x384 or something, that of course looks terrible on a
FullHD 40" LCD. The problem here is, of course, that with ATI, you
can't use the hud OSD (the picture get's blanked then, although the
OSD would look very nice then) ... in the CVS the non-HUD OSD is very
ugly.

Well, at least now this is usable altough with a very ugly OSD, but I
guess I can live with that for time being. If there are any tips for
getting this working better, they are welcome =).

-- 
-- 
Ville Aakko - ville.aa...@gmail.com

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

Re: [vdr] VDR 1.7 branch and xineliboutput (on Gentoo)

[Ville Aakko]

2010/5/16 Ville Aakko :
> Well, at least now this is usable altough with a very ugly OSD, but I
> guess I can live with that for time being. If there are any tips for
> getting this working better, they are welcome =).

I'll have to add, that all the xineliboutput configuration settings
are missing from the VDR menu (Menu -> Settings -> Plugins: There is
no xineliboutput menu anymore!). Is this normal?

Cheers!

 - Ville

-- 
-- 
Ville Aakko - ville.aa...@gmail.com

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

Re: [vdr] VDR 1.7 branch and xineliboutput (on Gentoo)

[Halim Sahin]

hi,
On So, Mai 16, 2010 at 12:32:48 +0300, Ville Aakko wrote:
> 2010/5/16 Ville Aakko :
> > Well, at least now this is usable altough with a very ugly OSD, but I
> > guess I can live with that for time being. If there are any tips for
> > getting this working better, they are welcome =).
> 
> I'll have to add, that all the xineliboutput configuration settings
> are missing from the VDR menu (Menu -> Settings -> Plugins: There is
> no xineliboutput menu anymore!). Is this normal?

No :-(.-
BR.
Halim

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

Re: [vdr] vdr and aac support

[Klaus Schmidinger]

On 15.05.2010 20:00, Newsy Paper wrote:
> hi Luis,
> 
> seems like an ugly hack. Channel I'm receiving here has:
> Stream_type: 15 (0x0f)  [= ISO/IEC 13818-7 Audio with ADTS transport sytax]

If you do this instead:

--- pat.c   2010/03/27 15:17:46 2.9
+++ pat.c   2010/05/16 10:53:46
@@ -358,6 +358,8 @@
   break;
   case 3: // STREAMTYPE_11172_AUDIO
   case 4: // STREAMTYPE_13818_AUDIO
+  case 0x0F: // ISO/IEC 13818-7 Audio with ADTS transport sytax
+  case 0x11: // ISO/IEC 14496-3 Audio with LATM transport syntax
   {
   if (NumApids < MAXAPIDS) {
  Apids[NumApids] = esPid;


does this put the proper PID into the APID section?
This may still not work with recordings, but I first want to know
whether a proper PID is detected that way.

Klaus

> --- Luis Fernandes  schrieb am Sa, 15.5.2010:
> 
>> Von: Luis Fernandes 
>> Betreff: Re: [vdr] vdr and aac support
>> An: "VDR Mailing List" 
>> Datum: Samstag, 15. Mai, 2010 17:40 Uhr
>> hello everybody, in my case of he-aac
>> streamtype 0x11 coming in, if
>> you want to record or listen to xineliboutput i have to
>> change in
>> remux.c and pat.c in the following lines,
>>
>> pat.c
>>
>>   case 0x04: / / STREAMTYPE_13818_AUDIO
>> + case 0x11: / / ISO/IEC 14496-3 Audio with LATM transport
>> syntax
>>
>>
>> thus adds the audio pid correctly
>>
>> remux.c
>>
>> for (int n = 0; Channel->Apid(n); n++) {
>> - i += MakeStream(buf
>> + i, 0x04, Channel->Apid(n));
>> +   i += MakeStream(buf + i,
>> 0x11, Channel->Apid(n));
>>  const char *Alang =
>> Channel->Alang(n);
>>
>>   case 0x04: / / STREAMTYPE_13818_AUDIO
>> + case 0x11: / / ISO/IEC 14496-3 Audio with LATM transport
>> syntax
>>
>>
>> but this way I can not hear sound from other channels, only
>> the
>> channels with streamtype 0x11
>> is there any way to identify the audio streamtype in this
>> line so that
>> the MakeStream (buf + i, streamaudiotype, Channel-> APID
>> (n));
>>
>> Excuse my English
>> Best regards
>>
>> 2010/5/15 Newsy Paper :
>>> thx Klaus for your patch, but seems like there's
>> something missing. Perhaps in remux.c?
>>> DDpid and Apid are both 0
>>> If I enter aac pid in ddpid field it's set back to 0
>> again.
>>> kind regards
>>>
>>> Newspaperman
>>>
>>> --- Klaus Schmidinger 
>> schrieb am Fr, 14.5.2010:
 Von: Klaus Schmidinger 
 Betreff: Re: [vdr] vdr and aac support
 An: vdr@linuxtv.org
 Datum: Freitag, 14. Mai, 2010 16:13 Uhr
 On 07.05.2010 09:53, Newsy Paper
 wrote:
> Hi!
>
> there are some channels using aac for audio.
>> I.e.
 SABC1 at 23.5°East 10758 V 22000 8/9 DVB-S2
> Seems vdr doesn't support aac as no pid is
>> entered
 neither for apid nor for ddpid. I think xine
>> should support
 acc or doesn't it? So it should be no big deal do
>> extend vdr
 to support aac.

 Please try this and see if it makes any
>> difference:
 --- pat.c   2010/03/27
 15:17:46 2.9
 +++ pat.c   2010/05/14
 14:12:31
 @@ -401,6 +401,7 @@

switch
 (d->getDescriptorTag()) {

  case
 SI::AC3DescriptorTag:

  case
 SI::EnhancedAC3DescriptorTag:
 +
 case
 SI::AACDescriptorTag:


   dpid = esPid;


   ProcessCaDescriptors = true;


   break;

 --- eit.c   2010/01/08
 15:17:09 2.11
 +++ eit.c   2010/05/14
 14:06:55
 @@ -257,7 +257,7 @@

   SI::ComponentDescriptor *cd =
 (SI::ComponentDescriptor *)d;

   uchar Stream = cd->getStreamContent();

   uchar Type = cd->getComponentType();
 -
if (1 <= Stream && Stream <=
 4 && Type != 0) { // 1=video, 2=audio,
>> 3=subtitles,
 4=AC3
 +
if (1 <= Stream && Stream <=
 6 && Type != 0) { // 1=MPEG2-video,
>> 2=MPEG1-audio,
 3=subtitles, 4=AC3-audio, 5=H.264-video,
>> 6=HEAAC-audio
  if (!Components)

 Components = new cComponents;

  char buffer[Utf8BufSize(256)];


 Klaus

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

Re: [vdr] vdr and aac support

[Klaus Schmidinger]

On 16.05.2010 12:55, Klaus Schmidinger wrote:
> On 15.05.2010 20:00, Newsy Paper wrote:
>> hi Luis,
>>
>> seems like an ugly hack. Channel I'm receiving here has:
>> Stream_type: 15 (0x0f)  [= ISO/IEC 13818-7 Audio with ADTS transport sytax]
> 
> If you do this instead:
> 
> --- pat.c   2010/03/27 15:17:46 2.9
> +++ pat.c   2010/05/16 10:53:46
> @@ -358,6 +358,8 @@
>break;
>case 3: // STREAMTYPE_11172_AUDIO
>case 4: // STREAMTYPE_13818_AUDIO
> +  case 0x0F: // ISO/IEC 13818-7 Audio with ADTS transport sytax
> +  case 0x11: // ISO/IEC 14496-3 Audio with LATM transport syntax
>{
>if (NumApids < MAXAPIDS) {
>   Apids[NumApids] = esPid;
> 
> 
> does this put the proper PID into the APID section?
> This may still not work with recordings, but I first want to know
> whether a proper PID is detected that way.

Ok, here's a complete patch that attempts to handle audio types.
It is untested, so please use it with care.
Please let me know whether this works with your audio types in
live mode and with replaying recordings.

Klaus
--- ./channels.c	2010/05/02 15:07:38	2.14
+++ ./channels.c	2010/05/16 11:44:31
@@ -271,14 +271,21 @@
   return result;
 }
 
-static int IntArrayToString(char *s, const int *a, int Base = 10, const char n[][MAXLANGCODE2] = NULL)
+static int IntArrayToString(char *s, const int *a, int Base = 10, const char n[][MAXLANGCODE2] = NULL, const int *t = NULL)
 {
   char *q = s;
   int i = 0;
   while (a[i] || i == 0) {
 q += sprintf(q, Base == 16 ? "%s%X" : "%s%d", i ? "," : "", a[i]);
-if (a[i] && n && *n[i])
-   q += sprintf(q, "=%s", n[i]);
+const char *Delim = "=";
+if (a[i]) {
+   if (n && *n[i]) {
+  q += sprintf(q, "%s%s", Delim, n[i]);
+  Delim = "";
+  }
+   if (t && t[i])
+  q += sprintf(q, "%...@%d", Delim, t[i]);
+   }
 if (!a[i])
break;
 i++;
@@ -287,29 +294,29 @@
   return q - s;
 }
 
-void cChannel::SetPids(int Vpid, int Ppid, int Vtype, int *Apids, char ALangs[][MAXLANGCODE2], int *Dpids, char DLangs[][MAXLANGCODE2], int *Spids, char SLangs[][MAXLANGCODE2], int Tpid)
+void cChannel::SetPids(int Vpid, int Ppid, int Vtype, int *Apids, int *Atypes, char ALangs[][MAXLANGCODE2], int *Dpids, char DLangs[][MAXLANGCODE2], int *Spids, char SLangs[][MAXLANGCODE2], int Tpid)
 {
   int mod = CHANNELMOD_NONE;
   if (vpid != Vpid || ppid != Ppid || vtype != Vtype || tpid != Tpid)
  mod |= CHANNELMOD_PIDS;
-  int m = IntArraysDiffer(apids, Apids, alangs, ALangs) | IntArraysDiffer(dpids, Dpids, dlangs, DLangs) | IntArraysDiffer(spids, Spids, slangs, SLangs);
+  int m = IntArraysDiffer(apids, Apids, alangs, ALangs) | IntArraysDiffer(atypes, Atypes) | IntArraysDiffer(dpids, Dpids, dlangs, DLangs) | IntArraysDiffer(spids, Spids, slangs, SLangs);
   if (m & STRDIFF)
  mod |= CHANNELMOD_LANGS;
   if (m & VALDIFF)
  mod |= CHANNELMOD_PIDS;
   if (mod) {
- const int BufferSize = (MAXAPIDS + MAXDPIDS) * (5 + 1 + MAXLANGCODE2) + 10; // 5 digits plus delimiting ',' or ';' plus optional '=cod+cod', +10: paranoia
+ const int BufferSize = (MAXAPIDS + MAXDPIDS) * (5 + 1 + MAXLANGCODE2 + 5) + 10; // 5 digits plus delimiting ',' or ';' plus optional '=cod+...@type', +10: paranoia
  char OldApidsBuf[BufferSize];
  char NewApidsBuf[BufferSize];
  char *q = OldApidsBuf;
- q += IntArrayToString(q, apids, 10, alangs);
+ q += IntArrayToString(q, apids, 10, alangs, atypes);
  if (dpids[0]) {
 *q++ = ';';
 q += IntArrayToString(q, dpids, 10, dlangs);
 }
  *q = 0;
  q = NewApidsBuf;
- q += IntArrayToString(q, Apids, 10, ALangs);
+ q += IntArrayToString(q, Apids, 10, ALangs, Atypes);
  if (Dpids[0]) {
 *q++ = ';';
 q += IntArrayToString(q, Dpids, 10, DLangs);
@@ -331,6 +338,7 @@
  vtype = Vtype;
  for (int i = 0; i < MAXAPIDS; i++) {
  apids[i] = Apids[i];
+ atypes[i] = Atypes[i];
  strn0cpy(alangs[i], ALangs[i], MAXLANGCODE2);
  }
  apids[MAXAPIDS] = 0;
@@ -485,10 +493,10 @@
  if (Channel->vpid && Channel->vtype)
 q += snprintf(q, sizeof(vpidbuf) - (q - vpidbuf), "=%d", Channel->vtype);
  *q = 0;
- const int BufferSize = (MAXAPIDS + MAXDPIDS) * (5 + 1 + MAXLANGCODE2) + 10; // 5 digits plus delimiting ',' or ';' plus optional '=cod+cod', +10: paranoia
+ const int BufferSize = (MAXAPIDS + MAXDPIDS) * (5 + 1 + MAXLANGCODE2 + 5) + 10; // 5 digits plus delimiting ',' or ';' plus optional '=cod+...@type', +10: paranoia
  char apidbuf[BufferSize];
  q = apidbuf;
- q += IntArrayToString(q, Channel->apids, 10, Channel->alangs);
+ q += IntArrayToString(q, Channel->apids, 10, Channel->alangs, Channel->atypes);
  if (Channel->dpids[0]) {
 *q+

Re: [vdr] dvb-s2 transponder can be received but channels are not automatically found

[Klaus Schmidinger]

On 15.05.2010 14:50, Newsy Paper wrote:
> Hi Klaus,
> 
> thx for your answer. Only 3 channels are found Ned3, Film1 HD and Sport 1 HD. 
> I also noticed this problem on some dvb-s2 transponders at 28.2 East.
> ...
> 
> SECT-Packet: 0014   PID: 17 (0x0011), Length: 292 (0x0124)
> Time received: Sat 2010-05-15  14:40:00.207
> 
>   :  42 f1 21 0c 96 e3 00 00  00 03 ff 51 ae ff 80 19   B.!Q
>   0010:  48 17 16 0d 43 61 6e 61  6c 64 69 67 69 74 61 61   H...Canaldigitaa
>   0020:  6c 07 46 69 6c 6d 31 2e  32 51 b3 ff 80 19 48 17   l.Film1.2QH.
>   0030:  16 0d 43 61 6e 61 6c 64  69 67 69 74 61 61 6c 07   ..Canaldigitaal.
>   0040:  46 69 6c 6d 31 2e 33 51  b8 ff 80 1e 48 1c 16 0d   Film1.3QH...
>   0050:  43 61 6e 61 6c 64 69 67  69 74 61 61 6c 0c 46 69   Canaldigitaal.Fi
>   0060:  6c 6d 31 20 41 63 74 69  6f 6e 51 bd ff 80 18 48   lm1 ActionQH
>   0070:  16 16 0d 43 61 6e 61 6c  64 69 67 69 74 61 61 6c   ...Canaldigitaal
>   0080:  06 53 70 6f 72 74 31 51  c2 ff 80 1a 48 18 16 0d   .Sport1QH...
>   0090:  43 61 6e 61 6c 64 69 67  69 74 61 61 6c 08 53 70   Canaldigitaal.Sp
>   00a0:  6f 72 74 31 2e 32 51 c7  fc 80 16 48 14 16 0d 43   ort1.2QH...C
>   00b0:  61 6e 61 6c 64 69 67 69  74 61 61 6c 04 74 73 74   analdigitaal.tst
>   00c0:  32 51 d6 ff 80 19 48 17  19 0d 43 61 6e 61 6c 64   2QH...Canald
>   00d0:  69 67 69 74 61 61 6c 07  4e 45 44 33 20 48 44 51   igitaal.NED3 HDQ
>   00e0:  db ff 80 1b 48 19 19 0d  43 41 4e 41 4c 44 49 47   H...CANALDIG
>   00f0:  49 54 41 41 4c 09 46 69  6c 6d 20 31 20 48 44 51   ITAAL.Film 1 HDQ
>   0100:  e0 ff 80 1c 48 1a 19 0d  43 61 6e 61 6c 64 69 67   H...Canaldig
>   0110:  69 74 61 61 6c 0a 53 70  6f 72 74 20 31 20 48 44   itaal.Sport 1 HD
>   0120:  f1 a3 19 67...g
> 
> PID:  17 (0x0011)  [= assigned for: DVB Service Description Table (SDT), 
> Bouquet Association Table (BAT)]
> ...
> service_type: 22 (0x16)  [= advanced codec SD digital television 
> service]
> Service_name: "Film1.2"  -- Charset: Latin alphabet
> ...
> service_type: 22 (0x16)  [= advanced codec SD digital television 
> service]
> Service_name: "Film1.3"  -- Charset: Latin alphabet
> ...
> service_type: 22 (0x16)  [= advanced codec SD digital television 
> service]
> Service_name: "Film1 Action"  -- Charset: Latin alphabet
> ...
> service_type: 22 (0x16)  [= advanced codec SD digital television 
> service]
> Service_name: "Sport1"  -- Charset: Latin alphabet
> ...
> service_type: 22 (0x16)  [= advanced codec SD digital television 
> service]
> Service_name: "Sport1.2"  -- Charset: Latin alphabet
> ...
> service_type: 22 (0x16)  [= advanced codec SD digital television 
> service]
> Service_name: "tst2"  -- Charset: Latin alphabet
> ...
> service_type: 25 (0x19)  [= advanced codec HD digital television 
> service]
> Service_name: "NED3 HD"  -- Charset: Latin alphabet
> ...
> service_type: 25 (0x19)  [= advanced codec HD digital television 
> service]
> Service_name: "Film 1 HD"  -- Charset: Latin alphabet
> ...
> service_type: 25 (0x19)  [= advanced codec HD digital television 
> service]
> Service_name: "Sport 1 HD"  -- Charset: Latin alphabet

Apparently only the three channels that are automatically detected use
service type 0x19. The others use 0x16, which is not known in VDR.

Please try this:

--- sdt.c   2009/12/23 16:02:47 2.4
+++ sdt.c   2010/05/16 14:23:21
@@ -55,6 +55,7 @@
case 0x02: // digital radio sound service
case 0x04: // NVOD reference service
case 0x05: // NVOD time-shifted service
+   case 0x16: // digital SD television service
case 0x19: // digital HD television service
 {
 char NameBuf[Utf8BufSize(1024)];


Klaus


> --- Klaus Schmidinger  schrieb am Fr, 14.5.2010:
> 
>> Von: Klaus Schmidinger 
>> Betreff: Re: [vdr] dvb-s2 transponder can be received but channels are not 
>> automatically found
>> An: vdr@linuxtv.org
>> Datum: Freitag, 14. Mai, 2010 15:50 Uhr
>> On 07.05.2010 09:45, Newsy Paper
>> wrote:
>>> hi!
>>>
>>> I noticed a new vdr problem concerning only some of
>> those dvb-s2 transponders.
>>> If I create a new channel in channel list with these
>> transponder datas and "add new channels" is activated in vdr
>> settings nothing happens either. But when I set manually SID
>> manually video + audio pids are found automatically but not
>> the other channels on that transponders are added
>> automatically.
>>> One of these problem transponders is 12129 V 27500 5/6
>> DVB-S2 on Astra 23.5°East.
>>
>> I'm af

Re: [vdr] dvb-s2 transponder can be received but channels are not automatically found

[Newsy Paper]

Hi Klaus,

thx very much. with this line it's working fine now for this transponder at 
23.5East.
But BSkyB at 28.2East is using another id. Service type 0x86 on their HD 
channels.


So I would suggest a new case
+case 0x86: // BSkyB HD television service

kind regards

Newspaperman

here's a short part of pid 0x11.

Service_id: 3861 (0x0f15)  [=  --> refers to PMT program_number]
reserved_1: 63 (0x3f)
EIT_schedule_flag: 1 (0x01)
EIT_present_following_flag: 1 (0x01)
Running_status: 4 (0x04)  [= running]
Free_CA_mode: 1 (0x01)  [= streams [partially] CA controlled]
Descriptors_loop_length: 157 (0x009d)

DVB-DescriptorTag: 73 (0x49)  [= country_availibility_descriptor]
descriptor_length: 7 (0x07)
country_availability_flag: 1 (0x01)
reserved: 127 (0x7f)
   country_code:  GBR
   country_code:  IRL

DVB-DescriptorTag: 95 (0x5f)  [= private_data_specifier_descriptor]
descriptor_length: 4 (0x04)
PrivateDataSpecifier: 2 (0x0002)  [= BskyB 1]

DVB-DescriptorTag: 72 (0x48)  [= service_descriptor]
descriptor_length: 15 (0x0f)
service_type: 134 (0x86)  [= User defined]
service_provider_name_length: 5 (0x05)
service_provider_name: "BSkyB"  -- Charset: Latin alphabet
service_name_length: 7 (0x07)
Service_name: "Sky1 HD"  -- Charset: Latin alphabet


--- Klaus Schmidinger  schrieb am So, 16.5.2010:

> Von: Klaus Schmidinger 
> Betreff: Re: [vdr] dvb-s2 transponder can be received but channels are not 
> automatically found
> An: vdr@linuxtv.org
> Datum: Sonntag, 16. Mai, 2010 16:24 Uhr
> On 15.05.2010 14:50, Newsy Paper
> wrote:
> > Hi Klaus,
> > 
> > thx for your answer. Only 3 channels are found Ned3,
> Film1 HD and Sport 1 HD. I also noticed this problem on some
> dvb-s2 transponders at 28.2 East.
> > ...
> >
> 
> > SECT-Packet: 0014   PID: 17
> (0x0011), Length: 292 (0x0124)
> > Time received: Sat 2010-05-15  14:40:00.207
> >
> 
> >   :  42 f1 21 0c 96 e3 00
> 00  00 03 ff 51 ae ff 80
> 19   B.!Q
> >   0010:  48 17 16 0d 43 61 6e
> 61  6c 64 69 67 69 74 61
> 61   H...Canaldigitaa
> >   0020:  6c 07 46 69 6c 6d 31
> 2e  32 51 b3 ff 80 19 48
> 17   l.Film1.2QH.
> >   0030:  16 0d 43 61 6e 61 6c
> 64  69 67 69 74 61 61 6c
> 07   ..Canaldigitaal.
> >   0040:  46 69 6c 6d 31 2e 33
> 51  b8 ff 80 1e 48 1c 16
> 0d   Film1.3QH...
> >   0050:  43 61 6e 61 6c 64 69
> 67  69 74 61 61 6c 0c 46
> 69   Canaldigitaal.Fi
> >   0060:  6c 6d 31 20 41 63 74
> 69  6f 6e 51 bd ff 80 18 48   lm1
> ActionQH
> >   0070:  16 16 0d 43 61 6e 61
> 6c  64 69 67 69 74 61 61
> 6c   ...Canaldigitaal
> >   0080:  06 53 70 6f 72 74 31
> 51  c2 ff 80 1a 48 18 16
> 0d   .Sport1QH...
> >   0090:  43 61 6e 61 6c 64 69
> 67  69 74 61 61 6c 08 53
> 70   Canaldigitaal.Sp
> >   00a0:  6f 72 74 31 2e 32 51
> c7  fc 80 16 48 14 16 0d
> 43   ort1.2QH...C
> >   00b0:  61 6e 61 6c 64 69 67
> 69  74 61 61 6c 04 74 73
> 74   analdigitaal.tst
> >   00c0:  32 51 d6 ff 80 19 48
> 17  19 0d 43 61 6e 61 6c
> 64   2QH...Canald
> >   00d0:  69 67 69 74 61 61 6c
> 07  4e 45 44 33 20 48 44
> 51   igitaal.NED3 HDQ
> >   00e0:  db ff 80 1b 48 19 19
> 0d  43 41 4e 41 4c 44 49
> 47   H...CANALDIG
> >   00f0:  49 54 41 41 4c 09 46
> 69  6c 6d 20 31 20 48 44 51   ITAAL.Film
> 1 HDQ
> >   0100:  e0 ff 80 1c 48 1a 19
> 0d  43 61 6e 61 6c 64 69
> 67   H...Canaldig
> >   0110:  69 74 61 61 6c 0a 53
> 70  6f 72 74 20 31 20 48
> 44   itaal.Sport 1 HD
> >   0120:  f1 a3 19 67   
>                
>                
>     ...g
> > 
> > PID:  17 (0x0011)  [= assigned for: DVB
> Service Description Table (SDT), Bouquet Association Table
> (BAT)]
> > ...
> >         
>    service_type: 22 (0x16)  [= advanced
> codec SD digital television service]
> >         
>    Service_name: "Film1.2"  -- Charset:
> Latin alphabet
> > ...
> >         
>    service_type: 22 (0x16)  [= advanced
> codec SD digital television service]
> >         
>    Service_name: "Film1.3"  -- Charset:
> Latin alphabet
> > ...
> >         
>    service_type: 22 (0x16)  [= advanced
> codec SD digital television service]
> >         
>    Service_name: "Film1 Action"  --
> Charset: Latin alphabet
> > ...
> >         
>    service_type: 22 (0x16)  [= advanced
> codec SD digital television service]
> >         
>    Service_name: "Sport1"  -- Charset:
> Latin alphabet
> > ...
> >         
>    service_type: 22 (0x16)  [= advanced
> codec SD digital television service]
> >         
>    Service_name: "Sport1.2"  -- Charset:
> Latin alphabet
> > ...
> >         
>    service_type: 22 (0x16)  [= advanced
> codec SD digital television service]
> >         
>    Service_name: "tst2"  -- Charset:
> Latin alphabet
> > ...
> >         
>    service_

Re: [vdr] xineliboutput - choppy problem

[Jiri Dobry]

Hello,

I has similar problem with jerky video on vdpau. After some 
investigation I hope that I found solution. I was try increase volume of 
output surfaces.


In file
xine-lib-1.2/src/video_out/video_out_vdpau.c

change line:
#define NOUTPUTSURFACE 2

I am trying value 6 and it is perfect on nVidia G100 or G130 graphic, 
and almost perfect on 8300/shared


I can confirm it on 3 machines, and I have confirmation from 2 other people.

Jiri

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

Re: [vdr] dvb-s2 transponder can be received but channels are not automatically found

[Klaus Schmidinger]

On 16.05.2010 19:13, Newsy Paper wrote:
> Hi Klaus,
> 
> thx very much. with this line it's working fine now for this transponder at 
> 23.5East.
> But BSkyB at 28.2East is using another id. Service type 0x86 on their HD 
> channels.
> 
> 
> So I would suggest a new case
> +case 0x86: // BSkyB HD television service

Have you actually tested this?
This is an undefined value ("User defined"), so any provider could
use that for something different.
Besides, AFAIK "Sky1 HD" is encrypted, and there is no CAM for the
Sky channels :-(

Klaus

> here's a short part of pid 0x11.
> 
> Service_id: 3861 (0x0f15)  [=  --> refers to PMT program_number]
> reserved_1: 63 (0x3f)
> EIT_schedule_flag: 1 (0x01)
> EIT_present_following_flag: 1 (0x01)
> Running_status: 4 (0x04)  [= running]
> Free_CA_mode: 1 (0x01)  [= streams [partially] CA controlled]
> Descriptors_loop_length: 157 (0x009d)
> 
> DVB-DescriptorTag: 73 (0x49)  [= country_availibility_descriptor]
> descriptor_length: 7 (0x07)
> country_availability_flag: 1 (0x01)
> reserved: 127 (0x7f)
>country_code:  GBR
>country_code:  IRL
> 
> DVB-DescriptorTag: 95 (0x5f)  [= 
> private_data_specifier_descriptor]
> descriptor_length: 4 (0x04)
> PrivateDataSpecifier: 2 (0x0002)  [= BskyB 1]
> 
> DVB-DescriptorTag: 72 (0x48)  [= service_descriptor]
> descriptor_length: 15 (0x0f)
> service_type: 134 (0x86)  [= User defined]
> service_provider_name_length: 5 (0x05)
> service_provider_name: "BSkyB"  -- Charset: Latin alphabet
> service_name_length: 7 (0x07)
> Service_name: "Sky1 HD"  -- Charset: Latin alphabet
> 
> 
> --- Klaus Schmidinger  schrieb am So, 16.5.2010:
> 
>> Von: Klaus Schmidinger 
>> Betreff: Re: [vdr] dvb-s2 transponder can be received but channels are not 
>> automatically found
>> An: vdr@linuxtv.org
>> Datum: Sonntag, 16. Mai, 2010 16:24 Uhr
>> On 15.05.2010 14:50, Newsy Paper
>> wrote:
>>> Hi Klaus,
>>>
>>> thx for your answer. Only 3 channels are found Ned3,
>> Film1 HD and Sport 1 HD. I also noticed this problem on some
>> dvb-s2 transponders at 28.2 East.
>>> ...
>>>
>> 
>>> SECT-Packet: 0014   PID: 17
>> (0x0011), Length: 292 (0x0124)
>>> Time received: Sat 2010-05-15  14:40:00.207
>>>
>> 
>>>:  42 f1 21 0c 96 e3 00
>> 00  00 03 ff 51 ae ff 80
>> 19   B.!Q
>>>0010:  48 17 16 0d 43 61 6e
>> 61  6c 64 69 67 69 74 61
>> 61   H...Canaldigitaa
>>>0020:  6c 07 46 69 6c 6d 31
>> 2e  32 51 b3 ff 80 19 48
>> 17   l.Film1.2QH.
>>>0030:  16 0d 43 61 6e 61 6c
>> 64  69 67 69 74 61 61 6c
>> 07   ..Canaldigitaal.
>>>0040:  46 69 6c 6d 31 2e 33
>> 51  b8 ff 80 1e 48 1c 16
>> 0d   Film1.3QH...
>>>0050:  43 61 6e 61 6c 64 69
>> 67  69 74 61 61 6c 0c 46
>> 69   Canaldigitaal.Fi
>>>0060:  6c 6d 31 20 41 63 74
>> 69  6f 6e 51 bd ff 80 18 48   lm1
>> ActionQH
>>>0070:  16 16 0d 43 61 6e 61
>> 6c  64 69 67 69 74 61 61
>> 6c   ...Canaldigitaal
>>>0080:  06 53 70 6f 72 74 31
>> 51  c2 ff 80 1a 48 18 16
>> 0d   .Sport1QH...
>>>0090:  43 61 6e 61 6c 64 69
>> 67  69 74 61 61 6c 08 53
>> 70   Canaldigitaal.Sp
>>>00a0:  6f 72 74 31 2e 32 51
>> c7  fc 80 16 48 14 16 0d
>> 43   ort1.2QH...C
>>>00b0:  61 6e 61 6c 64 69 67
>> 69  74 61 61 6c 04 74 73
>> 74   analdigitaal.tst
>>>00c0:  32 51 d6 ff 80 19 48
>> 17  19 0d 43 61 6e 61 6c
>> 64   2QH...Canald
>>>00d0:  69 67 69 74 61 61 6c
>> 07  4e 45 44 33 20 48 44
>> 51   igitaal.NED3 HDQ
>>>00e0:  db ff 80 1b 48 19 19
>> 0d  43 41 4e 41 4c 44 49
>> 47   H...CANALDIG
>>>00f0:  49 54 41 41 4c 09 46
>> 69  6c 6d 20 31 20 48 44 51   ITAAL.Film
>> 1 HDQ
>>>0100:  e0 ff 80 1c 48 1a 19
>> 0d  43 61 6e 61 6c 64 69
>> 67   H...Canaldig
>>>0110:  69 74 61 61 6c 0a 53
>> 70  6f 72 74 20 31 20 48
>> 44   itaal.Sport 1 HD
>>>0120:  f1 a3 19 67   
>>
>>
>> ...g
>>> PID:  17 (0x0011)  [= assigned for: DVB
>> Service Description Table (SDT), Bouquet Association Table
>> (BAT)]
>>> ...
>>>  
>>service_type: 22 (0x16)  [= advanced
>> codec SD digital television service]
>>>  
>>Service_name: "Film1.2"  -- Charset:
>> Latin alphabet
>>> ...
>>>  
>>service_type: 22 (0x16)  [= advanced
>> codec SD digital television service]
>>>  
>>Service_name: "Film1.3"  -- Charset:
>> Latin alphabet
>>> ...
>>>  
>>service_type: 22 (0x16)  [= advanced
>> codec SD digital television service]
>>>  
>>Service_name: "Film1 Action"  --
>> Charset: Latin alphabet
>>> ...
>>>  
>>service_type: 22 (0x16)  [= advanced
>> codec SD digital television service]
>>>  
>>Service_name: "Sport1

Re: [vdr] dvb-s2 transponder can be received but channels are not automatically found

[Newsy Paper]

Hi Klaus,

yes, it's tested by.
I don't know why they don't stick to the standard and use their own user 
defined value. I was always wondering why vdr didn't find a channel on those 
transponders, but now I know the reason. Do you know why standalone sat 
receivers find those channels? Would be interesting if these receivers consider 
0x86 or just add all channels no matter what ID. 

I will check if unencrypted channels like Luxe HD or ITV1 HD are also using 
0x86.

kind regards

Newspaperman

--- Klaus Schmidinger  schrieb am So, 16.5.2010:

> Von: Klaus Schmidinger 
> Betreff: Re: [vdr] dvb-s2 transponder can be received but channels are not 
> automatically found
> An: vdr@linuxtv.org
> Datum: Sonntag, 16. Mai, 2010 20:31 Uhr
> On 16.05.2010 19:13, Newsy Paper
> wrote:
> > Hi Klaus,
> > 
> > thx very much. with this line it's working fine now
> for this transponder at 23.5East.
> > But BSkyB at 28.2East is using another id. Service
> type 0x86 on their HD channels.
> > 
> > 
> > So I would suggest a new case
> > +case 0x86: // BSkyB HD television service
> 
> Have you actually tested this?
> This is an undefined value ("User defined"), so any
> provider could
> use that for something different.
> Besides, AFAIK "Sky1 HD" is encrypted, and there is no CAM
> for the
> Sky channels :-(
> 
> Klaus
> 
> > here's a short part of pid 0x11.
> > 
> > Service_id: 3861 (0x0f15)  [=  --> refers
> to PMT program_number]
> >     reserved_1: 63 (0x3f)
> >     EIT_schedule_flag: 1 (0x01)
> >     EIT_present_following_flag: 1
> (0x01)
> >     Running_status: 4 (0x04) 
> [= running]
> >     Free_CA_mode: 1 (0x01) 
> [= streams [partially] CA controlled]
> >     Descriptors_loop_length: 157
> (0x009d)
> > 
> >         
>    DVB-DescriptorTag: 73 (0x49)  [=
> country_availibility_descriptor]
> >         
>    descriptor_length: 7 (0x07)
> >         
>    country_availability_flag: 1 (0x01)
> >         
>    reserved: 127 (0x7f)
> >               
> country_code:  GBR
> >               
> country_code:  IRL
> > 
> >         
>    DVB-DescriptorTag: 95 (0x5f)  [=
> private_data_specifier_descriptor]
> >         
>    descriptor_length: 4 (0x04)
> >         
>    PrivateDataSpecifier: 2 (0x0002) 
> [= BskyB 1]
> > 
> >         
>    DVB-DescriptorTag: 72 (0x48)  [=
> service_descriptor]
> >         
>    descriptor_length: 15 (0x0f)
> >         
>    service_type: 134 (0x86)  [= User
> defined]
> >         
>    service_provider_name_length: 5 (0x05)
> >         
>    service_provider_name: "BSkyB"  --
> Charset: Latin alphabet
> >         
>    service_name_length: 7 (0x07)
> >         
>    Service_name: "Sky1 HD"  -- Charset:
> Latin alphabet
> > 
> > 
> > --- Klaus Schmidinger 
> schrieb am So, 16.5.2010:
> > 
> >> Von: Klaus Schmidinger 
> >> Betreff: Re: [vdr] dvb-s2 transponder can be
> received but channels are not automatically found
> >> An: vdr@linuxtv.org
> >> Datum: Sonntag, 16. Mai, 2010 16:24 Uhr
> >> On 15.05.2010 14:50, Newsy Paper
> >> wrote:
> >>> Hi Klaus,
> >>>
> >>> thx for your answer. Only 3 channels are found
> Ned3,
> >> Film1 HD and Sport 1 HD. I also noticed this
> problem on some
> >> dvb-s2 transponders at 28.2 East.
> >>> ...
> >>>
> >>
> 
> >>> SECT-Packet: 0014   PID:
> 17
> >> (0x0011), Length: 292 (0x0124)
> >>> Time received: Sat 2010-05-15 
> 14:40:00.207
> >>>
> >>
> 
> >>>    :  42 f1 21 0c 96 e3 00
> >> 00  00 03 ff 51 ae ff 80
> >> 19   B.!Q
> >>>    0010:  48 17 16 0d 43 61 6e
> >> 61  6c 64 69 67 69 74 61
> >> 61   H...Canaldigitaa
> >>>    0020:  6c 07 46 69 6c 6d 31
> >> 2e  32 51 b3 ff 80 19 48
> >> 17   l.Film1.2QH.
> >>>    0030:  16 0d 43 61 6e 61 6c
> >> 64  69 67 69 74 61 61 6c
> >> 07   ..Canaldigitaal.
> >>>    0040:  46 69 6c 6d 31 2e 33
> >> 51  b8 ff 80 1e 48 1c 16
> >> 0d   Film1.3QH...
> >>>    0050:  43 61 6e 61 6c 64 69
> >> 67  69 74 61 61 6c 0c 46
> >> 69   Canaldigitaal.Fi
> >>>    0060:  6c 6d 31 20 41 63 74
> >> 69  6f 6e 51 bd ff 80 18
> 48   lm1
> >> ActionQH
> >>>    0070:  16 16 0d 43 61 6e 61
> >> 6c  64 69 67 69 74 61 61
> >> 6c   ...Canaldigitaal
> >>>    0080:  06 53 70 6f 72 74 31
> >> 51  c2 ff 80 1a 48 18 16
> >> 0d   .Sport1QH...
> >>>    0090:  43 61 6e 61 6c 64 69
> >> 67  69 74 61 61 6c 08 53
> >> 70   Canaldigitaal.Sp
> >>>    00a0:  6f 72 74 31 2e 32 51
> >> c7  fc 80 16 48 14 16 0d
> >> 43   ort1.2QH...C
> >>>    00b0:  61 6e 61 6c 64 69 67
> >> 69  74 61 61 6c 04 74 73
> >> 74   analdigitaal.tst
> >>>    00c0:  32 51 d6 ff 80 19 48
> >> 17  19 0d 43 61 6e 61 6c
> >> 64   2QH...Canald
> >>>    00d0:  69 67 69 74 61 61 6c
> >> 07  4e 45 44 33 20 48 44
> >> 51   igitaal.NED3 HDQ
> >>>    00e0:  db ff 80 1b 48 19 19
> >> 0d  43 41 4e 41 4c 44 49
> >> 47   H...CANALDIG
> >>>    00f0:  49 54 41 41 4c 09 46
> >> 69  6c 6d 20 31 20 48 44
> 51   ITAAL.Film
> >> 1 HDQ
> >>>    0100:

[vdr] Insufficient hardware PID filters on tuner

[Richard F]

Hi list,

Having another go at a long-standing problem on Freecom USB tuners - a 
bit more testing:
Using VDR 1.6.0.2, and the problem seems to be that the tuners run out 
of hardware PID's.
The problem can be reliably repeated tuning to BBC1 & BBC2 on freeview, 
when 1 channel is already recording on that multiplex
What's appears unusual about these channels is that they need 4 PID's 
like so:


May 10 17:36:54 ha-server vdr: [7018] changing pids of channel 1 from 
600+600:601=eng,602=eng:0:0 to 600+600:601=eng,602=eng:605=eng:0

And tuning to another channel on that TS that uses 3 PID's (e.g BBC 
news) works OK:


May 10 17:36:53 ha-server vdr: [7018] changing pids of channel 5 from 
640+640:641=eng:0:0 to 640+640:641=eng:643=eng:0


The tuners report a capacity of 15 PID's from dmesg so:

[   42.437874] DVB: registering new adapter (WideView WT-220U PenType Receiver 
(Typhoon/Freecom))
[   42.449952] DVB: registering frontend 0 (WideView USB DVB-T)...
[   42.464022] input: IR-receiver inside an USB DVB receiver as 
/devices/pci:00/:00:1d.7/usb4/4-3/input/input4
[   42.475543] dvb-usb: schedule remote query interval to 300 msecs.
[   42.486250] dvb-usb: WideView WT-220U PenType Receiver (Typhoon/Freecom) 
successfully initialized and connected.
[   42.755308] usb 4-5: new high speed USB device using ehci_hcd and address 5
[   42.895930] usb 4-5: new device found, idVendor=14aa, idProduct=0221
[   42.907350] usb 4-5: new device strings: Mfr=1, Product=2, SerialNumber=0
[   42.918743] usb 4-5: Product: Digital TV Receiver
[   42.930060] usb 4-5: Manufacturer: Digital TV Receiver
[   42.941813] usb 4-5: configuration #1 chosen from 1 choice
[   42.953252] dvb-usb: found a 'WideView WT-220U PenType Receiver 
(Typhoon/Freecom)' in warm state.
[   42.967224] dvb-usb: will use the device's hardware PID filter (table count: 
15).

Some basic investigation...
Looking at the PID's being used during recording of a single channel, 
using lsof -n | grep adapter1.demux0 I see :


vdr7008vdr7u  CHR 212,68  
6038 /dev/dvb/adapter1/demux0
vdr7008vdr   15u  CHR 212,68  
6038 /dev/dvb/adapter1/demux0
vdr7008vdr   21u  CHR 212,68  
6038 /dev/dvb/adapter1/demux0
vdr7008vdr   22u  CHR 212,68  
6038 /dev/dvb/adapter1/demux0
vdr7008vdr   24u  CHR 212,68  
6038 /dev/dvb/adapter1/demux0
vdr7008vdr   26u  CHR 212,68  
6038 /dev/dvb/adapter1/demux0
vdr7008vdr   27u  CHR 212,68  
6038 /dev/dvb/adapter1/demux0
vdr7008vdr   34u  CHR 212,68  
6038 /dev/dvb/adapter1/demux0
vdr7008vdr   35u  CHR 212,68  
6038 /dev/dvb/adapter1/demux0
vdr7008vdr   36u  CHR 212,68  
6038 /dev/dvb/adapter1/demux0
vdr7008vdr   37u  CHR 212,68  
6038 /dev/dvb/adapter1/demux0
vdr7008vdr   39u  CHR 212,68  
6038 /dev/dvb/adapter1/demux0


So 12  filters in use, which is several more than needed by the channel 
being recorded (I assume these are other channels being monitored for 
epg etc, or is this other stuff in the TS being filtered...?).  When 
nothing is being recorded the following is typically output:


vdr7008vdr7u  CHR 212,68 
6038 /dev/dvb/adapter1/demux0
vdr7008vdr   15u  CHR 212,68 
6038 /dev/dvb/adapter1/demux0
vdr7008vdr   21u  CHR 212,68 
6038 /dev/dvb/adapter1/demux0
vdr7008vdr   22u  CHR 212,68 
6038 /dev/dvb/adapter1/demux0
vdr7008vdr   24u  CHR 212,68 
6038 /dev/dvb/adapter1/demux0
vdr7008vdr   26u  CHR 212,68 
6038 /dev/dvb/adapter1/demux0
vdr7008vdr   27u  CHR 212,68 
6038 /dev/dvb/adapter1/demux0
vdr7008vdr   28u  CHR 212,68 
6038 /dev/dvb/adapter1/demux0
vdr7008vdr   39u  CHR 212,68 
6038 /dev/dvb/adapter1/demux0


Sometimes this count is lower (e.g. 8, in which case 2 channels can be 
recorded).
When it fails, VDR still tries to allocate the PID's for the channel 
that requires 4:


May 16 19:47:51 ha-server vdr: [7022] ERROR: /dev/dvb/adapter1/demux0: Too many 
open files
May 16 19:47:51 ha-server vdr: [7022] ERROR (dvbdevice.c,658): Too many open 
files

Sometimes, after multiple retries, the 2 channels fit the total of 15 
(presumably some other PID's discarded) and it records 2 channels OK.
Then after stopping 2 simultaneous recordings (BBC1 + BBC2), and the 
residual PID count is now just 5.

Re: [vdr] vdr and aac support

[Newsy Paper]

Hi Klaus,

just tested your aac patch. I would say your patch is working fine. AAC pid is 
found + added automatically, femon plugin shows HE-AAC as codec. If I connect 
to xineliboutput with vlc I get correct audio, but with xine there's no audio, 
perhaps there are some more modifications necessary in xine but your part is 
complete. Thank you very much for that.

kind regards


Newspaperman

--- Klaus Schmidinger  schrieb am So, 16.5.2010:

> Von: Klaus Schmidinger 
> Betreff: Re: [vdr] vdr and aac support
> An: vdr@linuxtv.org
> Datum: Sonntag, 16. Mai, 2010 14:28 Uhr
> On 16.05.2010 12:55, Klaus
> Schmidinger wrote:
> > On 15.05.2010 20:00, Newsy Paper wrote:
> >> hi Luis,
> >>
> >> seems like an ugly hack. Channel I'm receiving
> here has:
> >> Stream_type: 15 (0x0f)  [= ISO/IEC 13818-7
> Audio with ADTS transport sytax]
> > 
> > If you do this instead:
> > 
> > --- pat.c       2010/03/27
> 15:17:46     2.9
> > +++ pat.c       2010/05/16
> 10:53:46
> > @@ -358,6 +358,8 @@
> >               
>         break;
> >               
> case 3: // STREAMTYPE_11172_AUDIO
> >               
> case 4: // STREAMTYPE_13818_AUDIO
> > +              case
> 0x0F: // ISO/IEC 13818-7 Audio with ADTS transport sytax
> > +              case
> 0x11: // ISO/IEC 14496-3 Audio with LATM transport syntax
> >               
>         {
> >               
>         if (NumApids < MAXAPIDS) {
> >               
>        
>    Apids[NumApids] = esPid;
> > 
> > 
> > does this put the proper PID into the APID section?
> > This may still not work with recordings, but I first
> want to know
> > whether a proper PID is detected that way.
> 
> Ok, here's a complete patch that attempts to handle audio
> types.
> It is untested, so please use it with care.
> Please let me know whether this works with your audio types
> in
> live mode and with replaying recordings.
> 
> Klaus
> 
> -Integrierter Anhang folgt-
> 
> 
> -Integrierter Anhang folgt-
> 
> ___
> 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] vdr and aac support

[Newsy Paper]

funny, today sound works with xine, yesterday it didn't although I had sound on 
all other channels with mpeg2 audio. Even recorings work fine, so aac support 
is perfect here :)


kind regards

Newspaperman

--- Newsy Paper  schrieb am So, 16.5.2010:

> Von: Newsy Paper 
> Betreff: Re: [vdr] vdr and aac support
> An: "VDR Mailing List" 
> Datum: Sonntag, 16. Mai, 2010 23:52 Uhr
> Hi Klaus,
> 
> just tested your aac patch. I would say your patch is
> working fine. AAC pid is found + added automatically, femon
> plugin shows HE-AAC as codec. If I connect to xineliboutput
> with vlc I get correct audio, but with xine there's no
> audio, perhaps there are some more modifications necessary
> in xine but your part is complete. Thank you very much for
> that.
> 
> kind regards
> 
> 
> Newspaperman
> 
> --- Klaus Schmidinger 
> schrieb am So, 16.5.2010:
> 
> > Von: Klaus Schmidinger 
> > Betreff: Re: [vdr] vdr and aac support
> > An: vdr@linuxtv.org
> > Datum: Sonntag, 16. Mai, 2010 14:28 Uhr
> > On 16.05.2010 12:55, Klaus
> > Schmidinger wrote:
> > > On 15.05.2010 20:00, Newsy Paper wrote:
> > >> hi Luis,
> > >>
> > >> seems like an ugly hack. Channel I'm
> receiving
> > here has:
> > >> Stream_type: 15 (0x0f)  [= ISO/IEC 13818-7
> > Audio with ADTS transport sytax]
> > > 
> > > If you do this instead:
> > > 
> > > --- pat.c       2010/03/27
> > 15:17:46     2.9
> > > +++ pat.c       2010/05/16
> > 10:53:46
> > > @@ -358,6 +358,8 @@
> > >               
> >         break;
> > >               
> > case 3: // STREAMTYPE_11172_AUDIO
> > >               
> > case 4: // STREAMTYPE_13818_AUDIO
> > > +              case
> > 0x0F: // ISO/IEC 13818-7 Audio with ADTS transport
> sytax
> > > +              case
> > 0x11: // ISO/IEC 14496-3 Audio with LATM transport
> syntax
> > >               
> >         {
> > >               
> >         if (NumApids < MAXAPIDS) {
> > >               
> >        
> >    Apids[NumApids] = esPid;
> > > 
> > > 
> > > does this put the proper PID into the APID
> section?
> > > This may still not work with recordings, but I
> first
> > want to know
> > > whether a proper PID is detected that way.
> > 
> > Ok, here's a complete patch that attempts to handle
> audio
> > types.
> > It is untested, so please use it with care.
> > Please let me know whether this works with your audio
> types
> > in
> > live mode and with replaying recordings.
> > 
> > Klaus
> > 
> > -Integrierter Anhang folgt-
> > 
> > 
> > -Integrierter Anhang folgt-
> > 
> > ___
> > 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
> 



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